Why are CS for SPI defined as GPIOs in Device Tree i.MX6

[nexy_sm]

I am reading at the moment the device tree documentation about SPI bindings while dealing with a custom board based on i.MX6DL (and Sabe Auto board). I have the following question, ECSPI controllers already have dedicated pins which can be configured as SS pins. Why do we define them in cs-gpios field and why are they configured as GPIOS. Here is an example from sabre auto board device tree:

&ecspi1 {
    fsl,spi-num-chipselects = <1>;
    cs-gpios = <&gpio3 19 0>;
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_cs>;
    status = "disabled"; /* pin conflict with WEIM NOR */

    flash: m25p80@0 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "st,m25p32";
        spi-max-frequency = <20000000>;
        reg = <0>;
    };
};

And down is pinctrl entry:

        pinctrl_ecspi1: ecspi1grp {
            fsl,pins = <
                MX6QDL_PAD_EIM_D17__ECSPI1_MISO        0x100b1
                MX6QDL_PAD_EIM_D18__ECSPI1_MOSI        0x100b1
                MX6QDL_PAD_EIM_D16__ECSPI1_SCLK        0x100b1
            >;
        };

        pinctrl_ecspi1_cs: ecspi1cs {
            fsl,pins = <
                MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x80000000
            >;
        };

Shouldn't ECSPI controller automatically control SS its dedicated pin whenever an action on some device is initiated? So, why we don't choose SS option for that pin inside pinctrl but the GPIO?

[gusarambula]

Hello Nemanja Savic,

The 4.1.43 Kernel is available on the Community BSP, so this would explain why it’s different from the configuration of the BSP Releases.

The SSX configuration is used on the Pins Tool and BSP Releases that I checked, and it’s preferred. Although apparently the GPIO works too.

Regards,

[gusarambula]

Hello Nemanja Savic,

The device tree describes the hardware available to the kernel and drivers and allows the drivers to get access to the driver trough nodes.

Even if the pins are dedicated to a specific module these need to be described on the device tree for the driver to access them. This would be the case of the ECSPI3 port which has dedicated pins. The ECSPI1 port is muxed but the fact remains that it needs to be described on the device tree.

The SS is listed as cs-gpio es part of the Device Tree convention for SPI. There is some information on the SPI-BUS documentation in Kernel.org
https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-bus.txt

I hope this helps!
Regards,

[nexy_sm]

Maybe my question was not clear enough. You see that pinctrl is configuring SS pin to be in GPIO mode, although another alternative for that pad can also be SPI SS mode.

Intuitively, for me, the way it is now, it sounds like any GPIO can be used as SS, because the driver will emulate it and that's why we configure it in GPIO mode. On the other side, if SPI controller uses genuine SS pin dedicated for that purpose, it should be configured in SS mode, so instead

MX6QDL_PAD_EIM_D19__GPIO3_IO19

The option

MX6QDL_PAD_EIM_D19__ECSPI1_SS1

should be used. But it isn't.

[gusarambula]

Hello Nemanja Savic,

My apologies for not grasping the question correctly the first time. I agree that the pin should be configured with MX6QDL_PAD_EIM_D19__ECSPI1_SS1. If you use the Pins Tool for i.MX to setup the muxing options this would be the option used even on the SABRE AI .mex files.

Would you please let me know on which BSP you encountered this? I’ll investigate if this was an error or if there’s a reason behind it.

Regards,

[nexy_sm]

Hi gusarambula,

thank you for your answer. We are using Linux 4.1.43.

In principle, I am preparing uboot, device tree and kernel for our new custom board based on i.MX6 DL, for which I used SABRE Auto as a starting point. While preparing entries for SPI I was reading docs and realized that even name construction cs-gpios is not quite logical, because, at least in my mind, it means that the driver can also use a random GPIO as a chipselect signal. In the case when SS is driven by SPI module, it should be enough to map "official" SS pin to a peripheral and the rest should be done by the module by writing CHANNEL_SELECT field inside SPI register ECSPIx_CONREG. I don't know if the driver itself is able to use an arbitrary GPIO pin as chip select or not, and that was in fact my original question. The documentation was not reach in this case.

What I know is that in one of our device trees for another board we use SSx configuration instead of GPIO configuration as you can see below:

  pinctrl_ecspi1: ecspi1grp { // HSM

fsl,pins = <
MX6QDL_PAD_CSI0_DAT6__ECSPI1_MISO 0x100b1 // N4
MX6QDL_PAD_CSI0_DAT5__ECSPI1_MOSI 0x100b1 // P2
MX6QDL_PAD_CSI0_DAT4__ECSPI1_SCLK 0x100b1 // N1
MX6QDL_PAD_CSI0_DAT7__ECSPI1_SS0 0x80000000 // N3
>;
};

And it works.

Best regards!