| Message ID | 1347016499-29354-10-git-send-email-lee.jones@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Sep 7, 2012 at 1:14 PM, Lee Jones <lee.jones@linaro.org> 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@linaro.org> We have to look closer at this. There are merged PL022 DT bindings (by Roland Stigge) nowadays, see commit 6d3952a7dfa80919842bbe01ac7f693d40a1eb84 in linux-next: Optional properties: +- 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 time. 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. Yours, Linus Walleij
On Mon, Sep 10, 2012 at 04:11:10AM -0700, Linus Walleij wrote: > On Fri, Sep 7, 2012 at 1:14 PM, Lee Jones <lee.jones@linaro.org> 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@linaro.org> > > We have to look closer at this. > > There are merged PL022 DT bindings (by Roland Stigge) > nowadays, see commit 6d3952a7dfa80919842bbe01ac7f693d40a1eb84 > in linux-next: > > Optional properties: > +- 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 > time. > > 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. Sounds fine. I'll pull this for now.
Hi! On 09/10/2012 01:11 PM, Linus Walleij wrote: > +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 > time. Sorry for the incompleteness of the devicetree conversion. I'm sending a patch (separately) that makes it possible to specify everything via devicetree, so you can choose between dt and platform data. Except in case of callback specification (dma_filter()), you need to provide platform data. Interestingly, when I removed the actual platform data from the board file, I noticed that I still needed to specify a device name (like dev:ssp0) to make it work. But this seems to be expected according to the documentation of OF_DEV_AUXDATA(). Are there any plans or ideas how to fix this? When we have sorted out this driver change (please check the new pl022 specific dt property names!), I will provide patches for arm-soc to actually use this new interface via dts files. Thanks in advance, Roland
On Mon, Sep 17, 2012 at 7:03 PM, Roland Stigge <stigge@antcom.de> wrote: > On 09/10/2012 01:11 PM, Linus Walleij wrote: >> >> 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 >> time. > > Sorry for the incompleteness of the devicetree conversion. I'm sending a > patch (separately) that makes it possible to specify everything via > devicetree, so you can choose between dt and platform data. OK it was not such a big deal, but many many thanks for fixing this up! :-) > Except in case of callback specification (dma_filter()), you need to > provide platform data. OK. > Interestingly, when I removed the actual platform data from the board > file, I noticed that I still needed to specify a device name (like > dev:ssp0) to make it work. But this seems to be expected according to > the documentation of OF_DEV_AUXDATA(). Are there any plans or ideas how > to fix this? This is very likely because the clock tree has a name like "dev:ssp0" encoded for this device, and if you don't nail it down like that the device name will be the same as the node in your device tree and then clock lookup will fail. The "real fix" is to convert the clock drivers to use device tree so the drivers can just refer to the phandles to figure out what clock node they need. Along with the DMA channel mapping this is one of the major roadblocks to finalizing the device tree adoptions. > When we have sorted out this driver change (please check the new pl022 > specific dt property names!), I will provide patches for arm-soc to > actually use this new interface via dts files. OK cool I guess you will do this for the LPC32xx? Or are you testing this on some other platforms? Yours, Linus Walleij
Hi, On 09/18/2012 02:08 PM, Linus Walleij wrote: >> When we have sorted out this driver change (please check the new pl022 >> specific dt property names!), I will provide patches for arm-soc to >> actually use this new interface via dts files. > > OK cool I guess you will do this for the LPC32xx? Or are you testing > this on some other platforms? LPC32xx for now. The new code is backwards compatible, so I'd prefer for others to adopt and test it on their platforms individually before patching everything at once without testing. Roland
diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts index d8ed29e..49bdabd 100644 --- a/arch/arm/boot/dts/hrefv60plus.dts +++ b/arch/arm/boot/dts/hrefv60plus.dts @@ -92,5 +92,9 @@ msp3: msp@80125000 { status = "okay"; }; + + ssp@80002000 { + status = "okay"; + }; }; };
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@linaro.org> --- arch/arm/boot/dts/hrefv60plus.dts | 4 ++++ 1 file changed, 4 insertions(+)