On Monday 18 April 2016 05:55:51 Reizer, Eyal wrote:
quoted
quoted
- all wilink family needs special init command for entering wspi mode.
extra clock cycles should be sent after the spi init command while the
cs pin is high.
- switch to controling the cs pin from the spi driver for achieveing the
above.
- the selected cs gpio is read from the spi device-tree node using the
cs-gpios field and setup as a gpio.
- See the example below for specifying the cs gpio using the cs-gpios entry
&spi0 {
...
cs-gpios = <&gpio0 5 0>;
...
wlcore: wlcore@0 {
compatible = "ti,wl1835";
...
...
};
};
Signed-off-by: Eyal Reizer <redacted>
I don't think this can work in general: not all SPI hosts uses GPIOs for
controlling CS, so the logic can't work, and it's also a layering violation for the
driver to look at the parent.
I would suggest fixing this using a new API function from the SPI core, if we
don't already have a generic way to do it.
Originally this is what I have done until I was pointed to the generic cs-gpio mechanism
in the SPI core.
It is a generic mechanism already in the SPI core driver.
See: Documentation/devicetree/bindings/spi/spi-bus.txt
The cs-gpios property is documented as optional, it defines how you should
list the gpios if CS is implemented using gpio, but not all hardware does
it like this.
It is also part of the generic spi.h (include/Linux/spi/spi.h), already part of
" struct spi_device" So it seemed redundant adding another mechanism for
implementing the same.
Platform that interact with a wilink need to use it, and platforms that don't
have this capability will probably not interact with a wilink device using SPI.
The cs_gpio field in spi_device belongs to the spi host controller, no other
slave driver uses it.
I wasn't asking for a duplication of this mechanism, but an interface to
use it properly. Internally, the spi core uses the spi_set_cs() function to
pick a CS. Find a way to use that rather than reimplementing it incorrectly.
Arnd