spidev on wandboard dual lite

[catalinpetrescu]

Hi,

Has anyone managed to access the SPI bus via spidev on a wandboard dual lite?

I'm running linux 3.10.17-1.0.1. The SPI and SPIDEV are compiled in the kernel:

# zgrep SPI /proc/config.gz | grep -v SPIN | grep -v '^#'

CONFIG_IMX_HAVE_PLATFORM_SPI_IMX=y

CONFIG_REGMAP_SPI=y

CONFIG_SPI=y

CONFIG_SPI_MASTER=y

CONFIG_SPI_BITBANG=y

CONFIG_SPI_IMX=y

CONFIG_SPI_SPIDEV=y

CONFIG_MFD_MC13XXX_SPI=y

CONFIG_SND_SPI=y

CONFIG_SND_SOC_I2C_AND_SPI=y

I noticed that the ecspi nodes were disabled in device tree and I set the status of the first spi controller to "okay"

Now, the driver (spi_imx) finds controller:

# dmesg|grep spi

[    1.245159] spi_imx 2008000.ecspi: probed

But when I try to open /dev/spidev0.0 I get a ENXIO. Here's the output from strace:

open("/dev/spidev0.0", O_RDWR)          = -1 ENXIO (No such device or address)

The device is there:

ls -l /dev/spidev0.0

brw-rw-rw- 1 root root 153, 0 Nov 26 20:04 /dev/spidev0.0

Any ideas?

Thanks.

[qiang_li-mpu_se]

Hi Catalin, the spidev was used for SPI slave mode, and SPI slave was not supported in default BSP, you can reference to the followed link to add the SPI slave support into your BSP, then you can use the spdev device.

https://community.freescale.com/docs/DOC-97380

[catalinpetrescu]

Hi Qiang,

I should have mentioned that I'm trying to use the SPI  as a master. So, the wandboard is the master, some other device is the slave.

Thanks.

[qiang_li-mpu_se]

In device tree file, I think you also need add the SPIDEV to the related SPI port.

&ecspi1 {
fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 9 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1_2>;
status = "okay";

spidev@0x00 {
  compatible = "spidev";
  spi-max-frequency = <20000000>;
  reg = <0>;
};

};

The SPI test application can be found at "imx-test-3.10.17-1.0.0.tar.gz", test\mxc_spi_test\, you can try it.

[catalinpetrescu]

Hi Qiang,

You're right about the spidev node. I added two spidev nodes, and now I can open both /dev/spidev0.0 and /dev/spidev0.1.

I tried mxc_spi_test1 and it works.

Now I ran into a different problem (or possibly two different problems).

The first chip select signal ECSPI1_SS0) seems to work although it works in a strange way. It goes low for every byte sent on the SPI bus. If I send 4 bytes it goes low and back high 4 times. I think it should go low and stay low for the entire transfer (all 4 bytes).

In the imx6 Reference Manual I found 21.4.4.1, Typical Master Mode. The diagram in that chapter is what I thought the SS signal should look like. Do I have to do something to set the controller in that mode?

The second chip select signal doesn't work at all. It doesn't go low when I send data to /dev/spidev0.1. The clock and the mosi lines wiggle as they're supposed to.

Here are the changes that I've made to the device tree:

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts

index b476518..7929bad 100644

--- a/arch/arm/boot/dts/imx6dl-wandboard.dts

+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts

@@ -40,3 +40,40 @@

&epdc {

        status = "disabled";

};

+

+&ecspi1 {

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

+       /* cs-gpios = <&gpio3 12 0>, <&gpio3 27 0>; */

+       pinctrl-names = "default";

+       pinctrl-0 = <&pinctrl_ecspi1_1>;

+       status = "okay";

+

+       spidev@0 {

+               compatible = "spidev";

+               reg = <0>;

+               #address-cells = <1>;

+               #size-cells = <0>;

+               spi-max-frequency = <20000000>;

+       };

+       spidev@1 {

+               compatible = "spidev";

+               reg = <1>;

+               #address-cells = <1>;

+               #size-cells = <0>;

+               spi-max-frequency = <20000000>;

+       };

+};

+

+#if 0

+&ecspi2 {

+       status = "okay";

+};

+

+&ecspi3 {

+       status = "okay";

+};

+

+&ecspi4 {

+       status = "okay";

+};

+#endif

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi

index 95bd7b1..5b5ded2 100644

--- a/arch/arm/boot/dts/imx6qdl.dtsi

+++ b/arch/arm/boot/dts/imx6qdl.dtsi

@@ -32,6 +32,10 @@

                serial4 = &uart5;

                usbphy0 = &usbphy1;

                usbphy1 = &usbphy2;

+               spi0 = &ecspi1;

+               spi1 = &ecspi2;

+               spi2 = &ecspi3;

+               spi3 = &ecspi4;

        };

        intc: interrupt-controller@00a01000 {

@@ -1083,6 +1087,8 @@

                                MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1

                                MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1

                                MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1

+                               MX6QDL_PAD_EIM_EB2__ECSPI1_SS0  0x100b1

+                               MX6QDL_PAD_EIM_D19__ECSPI1_SS1  0x100b1

                        >;

                };

Thanks.

[fabio_estevam]

You should use MX6QDL_PAD_EIM_EB2__ECSPI1_SS0 and MX6QDL_PAD_EIM_D19__ECSPI1_SS1 as GPIOs instead of native SS function.

[fabio_estevam]

Same issue has been fixed here:

Re: SPIDEV problem

[catalinpetrescu]

Hi Fabio, I think I finally got it.

Thanks again for your help.

Here's the the device tree patch, in case somebody runs into the same issue:

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts

index b476518..1ae5d91 100644

--- a/arch/arm/boot/dts/imx6dl-wandboard.dts

+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts

@@ -40,3 +40,27 @@

&epdc {

        status = "disabled";

};

+

+&ecspi1 {

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

+       cs-gpios = <&gpio2 30 0>, <&gpio4 10 0>;

+       pinctrl-names = "default";

+       pinctrl-0 = <&pinctrl_ecspi1_1>;

+       status = "okay";

+

+       spidev@0 {

+               compatible = "spidev";

+               reg = <0>;

+               #address-cells = <1>;

+               #size-cells = <0>;

+               spi-max-frequency = <20000000>;

+       };

+       spidev@1 {

+               compatible = "spidev";

+               reg = <1>;

+               #address-cells = <1>;

+               #size-cells = <0>;

+               spi-max-frequency = <20000000>;

+       };

+};

+

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi

index 95bd7b1..fa0c598 100644

--- a/arch/arm/boot/dts/imx6qdl.dtsi

+++ b/arch/arm/boot/dts/imx6qdl.dtsi

@@ -32,6 +32,10 @@

                serial4 = &uart5;

                usbphy0 = &usbphy1;

                usbphy1 = &usbphy2;

+               spi0 = &ecspi1;

+               spi1 = &ecspi2;

+               spi2 = &ecspi3;

+               spi3 = &ecspi4;

        };

        intc: interrupt-controller@00a01000 {

@@ -1083,6 +1087,8 @@

                                MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1

                                MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1

                                MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1

+                               MX6QDL_PAD_EIM_EB2__GPIO2_IO30  0x100b1

+                               MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x100b1

                        >;

                };

[varkabhadram]

I am using wandboard-qaud revb1. Where can we find the GPIO pins MX6QDL_PAD_EIM_EB2__GPIO2_IO30, MX6QDL_PAD_KEY_COL2__GPIO4_IO10 in the expansion header to connect to SS pin of slave..?

[catalinpetrescu]

JP4, pins 13 and 15, respectively.

See the page 7 of the Wandboard User Guide.

[catalinpetrescu]

Hi Fabio, thanks for the help.

/dev/spidev0.0 works perfectly now, the chip select stays low for the whole transfer.

The second chip select signal doesn't work at all though. (for /dev/spidev0.1)

I tried both

  cs-gpios = <&gpio2 30 0>, <&gpio3 19 0>;  in the ecspi1 node  with

  MX6QDL_PAD_EIM_EB2__GPIO2_IO30  0x100b1 in the iomux

and

  cs-gpios = <&gpio2 30 0>, <0>; in ecspi   with

  MX6QDL_PAD_EIM_D19__ECSPI1_SS1  0x100b1 in iomux

I even tried GPIO3_12 which is routed to a different pin in the same header

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

  MX6QDL_PAD_EIM_DA12__GPIO3_IO12

Do you have any idea about what's going on with my board?

Thanks.