i.MX25 SPI problem

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX25 SPI problem

Jump to solution
749 Views
csotoalonso
Contributor III

Hi,

I'm trying to enable SPI in the TX25 module from KaRo. I'm using kernel 3.17.2, and in order to enable SPI i've modified imx25-karo-tx25.dts. The changes are two: first of all, enable SPI

/* SPI support */

&spi1 {

    pinctrl-names = "default";

    pinctrl-0 = <&pinctrl_cspi>;

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

    status = "okay";

    cs-gpios = <

        &gpio1 16 0

        &gpio1 17 0

    >;

    spidev0: spi@0 {

        compatible = "spidev";

        reg = <0>;

        spi-max-frequency = <24000000>;

    };

    spidev1: spi@1 {

        compatible = "spidev";

        reg = <1>;

        spi-max-frequency = <24000000>;

    };   

};

And

    pinctrl_cspi: cspigrp {
   fsl,pins = <
   MX25_PAD_CSPI1_RDY__CSPI1_RDY   0x80000000
   MX25_PAD_CSPI1_SS0__CSPI1_SS0   0x80000000
   MX25_PAD_CSPI1_SCLK__CSPI1_SCLK   0x80000000
   MX25_PAD_CSPI1_MISO__CSPI1_MISO   0x80000000
   MX25_PAD_CSPI1_MOSI__CSPI1_MOSI   0x80000000
   MX25_PAD_CSPI1_SS1__CSPI1_SS1   0x80000000
   >;
   };  

to iomuxc.

I've created a rootfs with buildroot, and added spidev_test to it. When I try this command, the process hangs and I'm unable to end it, even with a kill -9.

Further debugging using strace has shown that the process hangs when tries to execute this ioctl:

ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);

but that's as far as I can get.

Any clues? Thanks in advance

Labels (2)
Tags (4)
0 Kudos
1 Solution
146 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Carlos,

I think I found the bug, in imx25.dtsi, please change the clocks line as below:

   spi1: cspi@43fa4000 {
   #address-cells = <1>;
   #size-cells = <0>;
   compatible = "fsl,imx25-cspi", "fsl,imx35-cspi";
   reg = <0x43fa4000 0x4000>;
   clocks = <&clks 78>, <&clks 78>;
   clock-names = "ipg", "per";
   interrupts = <14>;
   status = "disabled";
   };

View solution in original post

0 Kudos
14 Replies
146 Views
fabio_estevam
NXP Employee
NXP Employee

Carlos,

Please configure the chip select IOMUX as GPIO functionality instead of native SPI chip select functionality.

0 Kudos
146 Views
csotoalonso
Contributor III

Fabio,

do you mean, instead of MX25_PAD_CSPI1_MISO__CSPI1_MISO, using MX25_PAD_CSPI1_MISO__GPIO_1_15?

I've tried that, and no luck. spidev_test keeps hanging inmediately after the call to ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);


Thanks for your answer.

0 Kudos
146 Views
fabio_estevam
NXP Employee
NXP Employee

No, not MISO as GPIO. I meant MX25_PAD_CSPI1_SS0__ and MX25_PAD_CSPI1_SS1__ as GPIOs.

0 Kudos
146 Views
csotoalonso
Contributor III

OK, sorry.

My new IOMUX looks like this:

pinctrl_cspi: cspigrp {

            fsl,pins = <

                MX25_PAD_CSPI1_RDY__CSPI1_RDY        0x80000000

                MX25_PAD_CSPI1_SS0__GPIO_1_16        0x80000000

                MX25_PAD_CSPI1_SCLK__CSPI1_SCLK        0x80000000

                MX25_PAD_CSPI1_MISO__CSPI1_MISO        0x80000000

                MX25_PAD_CSPI1_MOSI__CSPI1_MOSI        0x80000000

                MX25_PAD_CSPI1_SS1__GPIO_1_17        0x80000000                

            >;

        };               

But it doesn't work either. It hangs in the same exact place.  Is there anything special I should put in the CONFIG pad settings?

0 Kudos
146 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Carlos,

The '0x80000000' means that the kernel will not configure the PAD settings and then it just uses whatever value that comes from the bootloader.

So it would be better to check the configuration you are getting and pass it in the dts.

0 Kudos
146 Views
csotoalonso
Contributor III

Hi Fabio,

I think I tried configuring the PAD setting for GPIO1_16 and GPIO1_17 in the DTS following the document fsl,imx25-pinctrl.txt, I don't have in front of me the values I used, but I can check it later. That didn't work either. Should I also configure the PAD settings for the SPI pins also (MISO, MOSI & SCLK)? If that's the case, would you mind helping me with this configuration?

Thanks

0 Kudos
146 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Carlos,

For GPIO pins you can let them in thde default reset values.

For the pins with SPI funcionality you need to adjust them.

I recommend you looking at the SPI_PAD_CTL1 and SPI_PAD_CTL2 configurations defined at:

linux-2.6-imx.git - Freescale i.MX Linux Tree

This is from kernel 2.6.31, but they can be easily adapted in your dts.

0 Kudos
146 Views
csotoalonso
Contributor III

OK, Fabio, thanks for pointing me in the right direction.

I've changed the PAD settings for the IOMUX based on SPI_PAD_CTL1, and now my DTS looks like this:

pinctrl_cspi: cspigrp {

            fsl,pins = <          

                MX25_PAD_CSPI1_RDY__CSPI1_RDY        0x1A0

                MX25_PAD_CSPI1_SS0__GPIO_1_16        0x80000000

                MX25_PAD_CSPI1_SCLK__CSPI1_SCLK        0x1A0

                MX25_PAD_CSPI1_MISO__CSPI1_MISO        0x1A0

                MX25_PAD_CSPI1_MOSI__CSPI1_MOSI        0x1A0

                MX25_PAD_CSPI1_SS1__GPIO_1_17        0x80000000                

            >;

        };

But the problem is the same: when I launch spidev_test, it hangs in ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);


I've also tried in another module to check for hardware problems, but with the same result.


Any hint would be very much appreciated at this point, I'm getting a bit desperate here :smileysad:

0 Kudos
146 Views
fabio_estevam
NXP Employee
NXP Employee

What spi device are you connecting to the mx25?

As you are getting a hang? I suspect that the SPI clocks are not being turned on, so I would recommend you probing the spi clocks with a scope.

0 Kudos
147 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Carlos,

I think I found the bug, in imx25.dtsi, please change the clocks line as below:

   spi1: cspi@43fa4000 {
   #address-cells = <1>;
   #size-cells = <0>;
   compatible = "fsl,imx25-cspi", "fsl,imx35-cspi";
   reg = <0x43fa4000 0x4000>;
   clocks = <&clks 78>, <&clks 78>;
   clock-names = "ipg", "per";
   interrupts = <14>;
   status = "disabled";
   };

View solution in original post

0 Kudos
146 Views
csotoalonso
Contributor III

Wow!

I didn't see your answer yesterday, and today I was checking your last answer regarding the clocks, so I checked imx25-clock.txt against the DTSI, and yeah! The clock assignment was wrong... I changed che clocks property into my dts and it works perfectly now.

So when I was coming here to post the answer I see you have already posted it. Should have looked before:smileyshocked:

Anyway, it is working now, and in the process I've gained a greater insight into the Device Tree business so thank you very much, Fabio! :smileyhappy:

0 Kudos
146 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Carlos,

Glad to know it is working now :-)

Yesterday I sent the fix to the linux-arm-kernel mailing list:

[PATCH] ARM: dts: imx25: Fix the SPI1 clocks — ARM, OMAP, Xscale Linux Kernel

0 Kudos
146 Views
jimmychan
NXP TechSupport
NXP TechSupport

Could you show your test program?

0 Kudos
146 Views
csotoalonso
Contributor III

I'm using the standard spidev_test from the kernel:

https://www.kernel.org/doc/Documentation/spi/spidev_test.c

0 Kudos