SPIDEV writes to wrong SPI

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SPIDEV writes to wrong SPI

2,068 Views
clx
Contributor I

Hello everyone,

Recently I’ve stumbled upon a weird situation when SPIDEV writes to a wrong SPI device and I would really appreciate if someone could point me why that happens.

I have a custom I.MX6Q board with SPI1 and SPI2 on a header. I use kernel 3.10 and have these SPIs enabled in the device tree with two chip selects each.

So I have 4 /dev/spidev records:

/dev/spidev32765.0  /dev/spidev32765.1  /dev/spidev32766.0  /dev/spidev32766.1

echo "hello" >> /dev/spidev32766.0

spidev32766.0.png

echo "hello" >> /dev/spidev32766.1

spidev32766.1.png

echo "hello" >> /dev/spidev32765.0

spidev32765.0.png

echo "hello" >> /dev/spidev32765.1

spidev32765.1.png

/dev/spidev32766.0 and /dev/spidev32766.1 seem to work correctly with SPI1.

The weird thing - why does write to /dev/spidev32765.0 results in transaction on SPI1 and write to /dev/spidev32765.1 results in transaction on SPI2?

They both should be on SPI2…

Here’s the SPI configuration in device tree:

&ecspi1 {

  fsl,spi-num-chipselects = <2>;

  cs-gpios = <&gpio2 30 0>, <&gpio3 19 0>;

  pinctrl-names = "default";

  pinctrl-0 = <&pinctrl_ecspi1_1 &pinctrl_ecspi1_cs_1>;

  status = "okay";

  spidev@0x00 {

        compatible = "spidev";

        spi-max-frequency = <5000000>;

        reg = <0>;

    };

    spidev@0x01 {

        compatible = "spidev";

        spi-max-frequency = <5000000>;

        reg = <1>;

    };

};

&ecspi2 {

    fsl,spi-num-chipselects = <2>;

    cs-gpios = <&gpio2 26 0>, <&gpio2 27 0>;

    pinctrl-names = "default";

    pinctrl-0 = <&pinctrl_ecspi2_1 &pinctrl_ecspi2_cs_1>;

    status = "okay";

    spidev@0x00 {

        compatible = "spidev";

        spi-max-frequency = <5000000>;

        reg = <0>;

    };

    spidev@0x01 {

        compatible = "spidev";

        spi-max-frequency = <5000000>;

        reg = <1>;

    };

};

And pin configuration:

ecspi1 {

  pinctrl_ecspi1_cs_1: ecspi1_cs_grp-1 {

  fsl,pins = <

  MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x80000000

  MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x80000000

  >;

  };

  pinctrl_ecspi1_1: ecspi1grp-1 {

  fsl,pins = <

  MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1

  MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1

  MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1

  >;

  };

};

ecspi2 {

    pinctrl_ecspi2_cs_1: ecspi2_cs_grp-1 {

        fsl,pins = <

            MX6QDL_PAD_EIM_RW__GPIO2_IO26  0x80000000 /* SS0 */

            MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x80000000 /* SS1 */

        >;

    };

    pinctrl_ecspi2_1: ecspi2grp-1 {

        fsl,pins = <

            MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1

            MX6QDL_PAD_EIM_OE__ECSPI2_MISO  0x100b1

            MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1

        >;

    };

};

Labels (3)
Tags (2)
0 Kudos
3 Replies

1,042 Views
jamesbone
NXP TechSupport
NXP TechSupport

Hello Clx,

It is very interesting your case is there any other SPI devices that maybe affecting the  SPI bus? or  any other load that maybe affecting,  I do not see any problem with the definition made by the Device Tree, analizing the case since you are mention that at least it works one of the two SPI dev that it is assign to the SPI2 then it is not configuration, it is like something it is taking control.

0 Kudos

1,042 Views
clx
Contributor I

There's only m25p80 connected to CSPI1_SS1, but it should not affect the SPI2 bus anyway.

I guess that's a bug somewhere in SPIDEV. Should probably try another kernel version.

0 Kudos

1,042 Views
jamesbone
NXP TechSupport
NXP TechSupport

What version of Kernel are you using? or what linux Bsp are you trying?

0 Kudos