On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote: [...] > > Ah. I understand what you're doing now. Hmmm. This approach > > concerns me because it relies on firmware or platform code to get CS > > gpios set up properly before the driver is probed. > > Yes, that was said at the very beginning of this thread. > > > Firmware doesn't > > always get it right, and I prefer to avoid platform specific setups as > > much as possible. Why can't the CS polarity be encoded into the > > device tree so the driver *does* have the polarity data at probe time? > > We have the spi-cs-high property, but it duplicates compatible > property. 'compatible' is enough to tell whether some device has > cs-high or cs-low (device's driver knows that already). > > The problem is that SPI bus master doesn't know all the devices, > so it can't extract that information from the compatible string. > To workaround that we can use 'spi-cs-high', but that's ugly > workaround. > > SPI modes (0,1,2,3) is another matter, some devices can work in > several modes, so 'spi-cpol' and 'spi-cpha' are actually useful. > To get a sane initial state the needed GPIOs can be set to be inputs during the driver's initialization. This requires pull-up/pull-down resistors connected to the chip select lines. I think we can assume that they exist, because the GPIOs are all inputs after the controller's hardware reset and the resistors are needed to have a well-defined voltage level on the chip select lines. Normally the level is set so that the devices are disabled.
Therefore, it doesn't matter if the firmware sets the GPIOs wrong. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
