This question is related to Spidev with multiple CS unable to read - Technical Support - Toradex Community.
My image is built with OpenEmbedded/Yocto and based upon Apalis-iMX6_LXDE-Image_2.8b4.129-20181005. I’ve verified the behavior described below with the official 2.8b5 and 2.7 image from BSP Layers and Reference Images for Yocto Project Software | Toradex Developer Center with minimal changes to the device-tree.
I’ve configured ECSPI2 with 4 GPIO chip-selects, and can successfully write to these devices. However, I can only read from these devices when the pins used for the chip-selects are also native chip-selects of the spi-controller.
It seems that the spi-controller (or driver?) ignores the MISO line if no native chip-select pin is active.
The relevant device tree section looks as follows:
&iomuxc {
pinctrl_ekt_mot_spi: mot_spi {
fsl,pins = <
MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1 // MOT_MISO
MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1 // MOT_MOSI
MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1 // MOT_SCK
MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1 // MOT_nCS
MX6QDL_PAD_NANDF_D4__GPIO2_IO04 0x000b1 // MOT1_nCS
MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x000b1 // MOT2_nCS
MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x000b1 // MOT3_nCS
>;
};
};
&ecspi2 {
status = "okay";
cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
<&gpio2 4 GPIO_ACTIVE_HIGH>,
<&gpio2 5 GPIO_ACTIVE_HIGH>,
<&gpio2 6 GPIO_ACTIVE_HIGH>;
fsl,spi-num-chipselects = <4>;
num-cs = <4>;
pinctrl-0 = <&pinctrl_ekt_mot_spi>;
ekt_spi_tmc429: spi_tmc429@0 {
compatible = "toradex,evalspi";
reg = <0>;
spi-max-frequency = <18000000>;
};
ekt_spi_tmc26x1: spi_tmc26x@1 {
compatible = "toradex,evalspi";
reg = <1>;
spi-max-frequency = <18000000>;
};
ekt_spi_tmc26x2: spi_tmc26x@2 {
compatible = "toradex,evalspi";
reg = <2>;
spi-max-frequency = <18000000>;
};
ekt_spi_tmc26x3: spi_tmc26x@3 {
compatible = "toradex,evalspi";
reg = <3>;
spi-max-frequency = <18000000>;
};
};
Here, MX6QDL_PAD_EIM_RW is also a native chip-select pin of ECPSI2, but NANDF_D4, NANDF_D5, NANDF_D6 are not.
I can successfully read from the device associated with pin EIM_RW, but not from the other devices.
I can “trick” the controller into reading from a device with a non-native chip-select by configuring the spi-device with only EIM_RW as its chip-select, disconnecting the pin in the layout from its slaves, and manually toggling the GPIO pin NANDF_D4, for example. This leads me to assume that the spi-controller only latches in data read from MISO when it sees one of its native chip-selects being active, even if the controller doesn’t drive the chip-select itself (since the chip-selects are driven by the driver as gpio pins).
Is this a bug in the design of the spi-controller or the imx spi kernel driver? Is there even a way to use non-native gpio pins as chip-selects?