I just found out that this patch only takes effect *after* the SPI slaves
have been probed. That's because the HW CS signal selection takes place
after a call to spi_register_master/spi_register_controller which adds the
SPI clients on its own. I now also understand why MSIOF discovers the CS in
such a complicated manner. Sorry. I wrote this patch for spidev where it is
not a problem, so I haven't seen this before.
I see three options now:
1) Add an explicit DT property to let the user select an appropriate HW CS
signal. This has an advantage of being able to handle DT overlays in
future, as Trent pointed out.
2) Split the spi_register_controller into two functions and let
orion_spi_probe access the cs_gpios in between them. No other drivers need
to be modified, but perhaps the MSIOF might switch to using these two
halves afterwards.
3) Follow the code from MSIOF, consult the "cs" gpios property, manually
walk the CS GPIOs, and find out a free HW CS.
I've already sorted these in my order of preference :). Which one is
preferrable for you folks?
Looking further, it seems that the CS GPIO signals are first manipulated
when probing for the corresponding client device. Depending on a platform
and its choice of a default value for the corresponding GPIO pin, this
might mean that a GPIO CS only gets initialized to inactive ("high" in
default SPI settings) too late. Other devices might have been already
probed for, and the CS GPIO of the "next" device might have been held
active ("low") during that time. How should I fix that?
With kind regards,
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
