Re: [PATCH 09/19] ARM: ux500: Enable SSP (SPI) for HREF when bootingDevice Tree
From: Linus Walleij
Date: Mon Sep 10 2012 - 07:11:06 EST
On Fri, Sep 7, 2012 at 1:14 PM, Lee Jones <lee.jones@xxxxxxxxxx> wrote:
> Here we add a new SSP node to the HREF's Device Tree file which
> activates the generic one found in the .dtsi file. This will
> allow probing of the SSP driver when Device Tree is enabled.
> Signed-off-by: Lee Jones <lee.jones@xxxxxxxxxx>
We have to look closer at this.
There are merged PL022 DT bindings (by Roland Stigge)
nowadays, see commit 6d3952a7dfa80919842bbe01ac7f693d40a1eb84
+- num-cs : total number of chipselects
- cs-gpios : should specify GPIOs used for chipselects.
The gpios will be referred to as reg = <index> in the SPI child nodes.
If unspecified, a single SPI device without a chip select can be used.
+SPI slave nodes must be children of the SPI master node and can
+contain the following properties.
+- pl022,interface : interface type:
+ 0: SPI
+ 1: Texas Instruments Synchronous Serial Frame Format
+ 2: Microwire (Half Duplex)
+- pl022,com-mode : polling, interrupt or dma
+- pl022,rx-level-trig : Rx FIFO watermark level
+- pl022,tx-level-trig : Tx FIFO watermark level
+- pl022,ctrl-len : Microwire interface: Control length
+- pl022,wait-state : Microwire interface: Wait state
+- pl022,duplex : Microwire interface: Full/Half duplex
Currently this is defined as auxdata in board-mop500.c
but notanly cs-gpios (num chipselects) should come from
device tree instead.
It appears Roland has written his bindings such that DT
data augments platform data (yes, I am also getting crazy
about this prioritization, mea culpa for ACKing this without
proper discussion) so it appears that you could actually
use AUXDATA and some stuff in the DT at the same
Or you could keep it like this and only have AUXDATA
as it stands, I just want a discussion about what is the right
thing to do before we commit to anything.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/