On Wed, May 21, 2008 at 1:11 PM, Segher Boessenkool
<[EMAIL PROTECTED]> wrote:
>> Ok, elegance apart:-) You can use the SPI-bridge construct to also
>> describe simple SPI-chipselect configurations. But is it really a good
>> idea? Wouldn't it be better to handle these two cases separately?
>
> It would be best to handle all these things that are specific to
> a certain SPI controller (like how CSs work) in the binding for
> that SPI controller, and not try to shoehorn all of this into some
> artificial generic framework.
>
> If you can have identical addresses on the SPI bus going to different
> devices based on which CS is asserted, you'll have to make the CS part
> of the "reg". Example:
>
> spi-controller {
> #address-cells = 2;
> #size-cells = 0;
> [EMAIL PROTECTED],f000 { reg = < 0 f000 >; } // CS 0, SPI address f000
> [EMAIL PROTECTED],f000 { reg = < 1 f000 >; } // CS 1, SPI address f000
> [EMAIL PROTECTED],ff00 { reg = < 1 ff00 >; } // CS 1, SPI address ff00
> }
For SPI the CS # *is* the address. :-)
Unlike I2C, SPI doesn't impose any protocol on the data. It is all
anonymous data out, anonymous data in, a clock and a chip select.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
