TI AM335x GPIO as chip select for SPI

[Oskar Holmlund]

Hi,

I'm currently writing drivers for different clickboards (Mikroelektronika).The cape for Beaglebone black https://www.mikroe.com/beaglebone-mikrobus-cape use an ordinary GPIO(P8_10) as chipselect  for one of the mikrobus slots.
I follow the gpio pin assignment code from arm/freescale/imx/imx_spi.c  with minor modification.
(patch-src_sys_arm_ti_ti__spi.c and patch-src_sys_arm_ti_ti__spivar.h)
 The cs-gpios are described here:
https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-controller.yaml
To implement the "native cs" is it acceptable to change ofw_bus_parse_xref_list_internal() in sys/dev/ofw/ofw_bus_subr.c to be aware that pnode can be zero (and if its on the requested index report it to calling function)?
(patch-src_sys_dev_gpio_ofw__gpiobus.c andpatch-src_sys_dev_ofw_ofw_bus_subr.c)


 Before the introduction of ti_sysc: all GPIO modules was probed & attached at once and after a while the SPI was handled, example boot log:

---<<boot>>---
...
gpio0: mem 0x44e07000-0x44e07fff irq 7 on simplebus0
gpio1: mem 0x4804c000-0x4804cfff irq 8 on simplebus0
gpio2: mem 0x481ac000-0x481acfff irq 9 on simplebus0
gpio3: mem 0x481ae000-0x481aefff irq 10 on simplebus0 
...
spi0: mem 0x48030000-0x480303ff irq 36 on simplebus0 

After the introduction of ti_sysc (dts 5.x) it seems that the devices are attached by the location in memory (the order follow more or less whats described in TRM page 179 Table2-2. L4_WKUP Peripheral Memory Map.) ---<<boot>>---
...
gpio0: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 12 on ti_sysc1...spi0: <TI McSPI controller> mem 0-0x3ff irq 24 on ti_sysc12...gpio1: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 35 on ti_sysc21
...
spi1: <TI McSPI controller> mem 0-0x3ff irq 40 on ti_sysc27...
gpio2: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 44 on ti_sysc31gpio3: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 45 on ti_sysc32
 I'm fine with the initialization order but have an little problem. If the SPI0 uses one of the pins from GPIO1 its not initialized when the SPI0 is acquiring the pin and it fails. 
My solution is to use the config_intrhook_oneshot to delay the setup of GPIO Pin as CS - is there another way?


If a IO expander are attached to the SPI bus (of course with gpio as CS) and on the IO expander it is a LED and for some reasons it seems logic to use the gpioled driver. In this case the gpioled driver is not a child of the IO expander in the device tree but it uses the IO expander resource instead. For example:
fragment at 0 {
          target-path="/leds";
          __overlay__ {
               mcp23_led at 0 {
                         label = "d1";
                         gpios = <&mcp23s17ioexp1 15 0>;
                         default-state = "off";
               };        };};
Of course this will fail because the gpioled driver are probed&attached before the IO expander is available. It doesnt feel right to change the gpioled driver to use config_intrhook_oneshot().(patch-src_sys_dev_gpio_gpioled_fdt.c)
 Do you have any ideas how to address this situation?
-- 
Bästa Hälsningar
Oskar Holmlund
Tel 070-3220292