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
Solved! Go to Solution.
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"; | |||
}; |
Carlos,
Please configure the chip select IOMUX as GPIO functionality instead of native SPI chip select functionality.
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.
No, not MISO as GPIO. I meant MX25_PAD_CSPI1_SS0__ and MX25_PAD_CSPI1_SS1__ as GPIOs.
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?
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.
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
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.
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:
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.
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"; | |||
}; |
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:
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
Could you show your test program?
I'm using the standard spidev_test from the kernel: