Arnd,

quoted

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

quoted

quoted

quoted

&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.

quoted

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.

Understood. As this special CS manipulation is unique to wspi (wilink spi)  I think the 
best option is to move this gpio allocation into wlcore_spi as a new device tree entry
used only by this driver.
If you agree I will submit a v3.

Best Regards,
Eyal
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html