We are trying to use two mcp23s17 on a viola board with a vf50. Using the DT, we modified the file “vf-colibri-eval-v3.dtsi” to remove the can driver and add the mcp23s17:
Diving on the documentation, the spi connected to the X9 connector is SPI1 with CS0
X9 PIN 20 → SPI1_SOUT
X9 PIN 21 → SPI1_SIN
X9 PIN 22 → SPI1_SCK
X9 PIN 23 → SPI1_PCS0
whe have connected a board with two mcp23s17 with address 0x00 and 0x01, but we can’t access nor configure the chips (they are connected propertly). On /sys/kernel/debug/gpio we have the eight chips available and we can export the gpios (gpio 384 to 511).
Is the modification on the DT correct? Is another SPI connected to X9 rather than 1?
After quickly going through the device tree binding documentation for gpio-mcp23s08, the ‘microchip,spi-present-mask’ value set in your device tree seems invalid for two chips, AFAIU one can interface 4 MCP23S08 instances with one 4-wire SPI interface. The chip address will be selected according to the 4bit value(since mcp23s08 chip variant only supports bits 0-3) which we are supposed to set by ‘microchip,spi-present-mask’ property. I think the value of 0011b will be valid value your case. Small nit in your DT changes, instead of commenting the complete dspi1 node, one can just add the ‘status’ property and set to ‘disabled’ in mcp251x node and append the gpiom1 node.
We have no logs, driver is silent.
dmesg | grep spi
dmesg | grep mcp
Same results with spi-present-mask=0x3, we have now two chips available on gpios but they don’t work.
Also tryed with @dspi0 but no luck. Perhaps a problem with the spi bus number? can be 2 or 3?
If you use the standard Colibri SPI bus and chip select, dspi1 along with reg 0 should be fine. However, when using reg 0, you should also use the same address in the node name (gpio@0 instead of gpio@1). Not sure if that helps.
If you use a different SPI capable pins, check the Colibri VFxx data sheet which instance you are using and adopt accordingly.
Just tested with &dspi0 and gpiom0: gpio@0… there is no mcp23s17 on /sys/kernel/debug/gpio…
still testing with other parameters… On the documentation appears that the spi bus attached to the X9 connector on the viola board is spi1 with cs0 so it must work with @dspi1 and gpiom0:gpio@1, but no luck
@zausan, did you enable the relevant kernel configuration (CONFIG_GPIO_MCP23S08)? The driver is not enabled by default. You can check by having a look into /proc/config.gz. Otherwise I would add debug prints in the drivers probe function to make sure the probe is being executed (in drivers/gpio/gpio-mcp23s08.c). A third thing you can do is measure if the chip select or clock signals are actually changing during probe (boot)…
“Just tested with &dspi0 and gpiom0: gpio@0…” Does this mean you are connecting the device to DSPI0_CS0 ? I think DSPI0 pins are not available on Viola Board X9 connector.
As @Stefan.agner already mentioned, the address in the node name for spi child nodes should be wrt to the chip select instance selected. If we are connecting the device to CS0 of DSP1
the node name in dspi1 will looks like: gpiom1: gpio@0
Just for test, we see on the documentation tthat the X9 connector has PTD7 (SPI1_SOUT), PTD6 (SPI1_SIN), PTD8 (SPI1_SCK) and PTD5 (SPI1_PCS0). We are trying now with;
Hm, this changes seem to leave both devices enabled, the MCP2515 and the Microchip MCP23S17, with the same reg value (and hence same chipselect). Is this really working? Or are you disabling the mcp2515can in a higher different device tree file (e.g. vf500-colibri-eval-v3.dts?) or in the kernel configuration?
