spidev driver worked in old i.MX6 BSP 4.1, crashes in the new BSP 4.9

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

spidev driver worked in old i.MX6 BSP 4.1, crashes in the new BSP 4.9

Jump to solution
2,461 Views
shkolnyykonstan
Contributor III

spidev driver worked in the old i.MX6 BSP, crashes in the new BSP.

Details:

On our custom i.MX6Q board, I've just switched from the previous Linux 4.1 BSP to the new 4.9 BSP.

I have a user-mode application sending data to SPI using the spidev driver.

It always worked perfectly on the old 4.1 BSP.

On the new one, it crashes instantly.

In the Linux boot log, there is a suspicious message about the ecspi3 I'm using, that wasn't there in 4.1:

spi_imx 2010000.ecspi: No CS GPIOs available
spi_imx: probe of 2010000.ecspi failed with error -22

(A funny thing is that, despite the apparent failure, I still then see /dev/spidev.2.0)

My Device Tree is the same as in BSP 4.1 (see below the relevant parts).

My intention is to use the ECSPI3_SS0 i.MX6Q output as Chip Select.

I'm not sure what GPIO the spi_imx driver now requires...

#include "imx6q.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>

...........

&ecspi3 { /* Diplay */
    fsl,spi-num-chipselects = <1>;
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_ecspi3>;
    status = "okay";
    spidev@0x00 {
        reg = <0>;
        compatible = "spidev";
        spi-max-frequency = <20000000>;
    };
};

............

------------------------

Unable to handle kernel paging request at virtual address c0906800
pgd = a8868000
[c0906800] *pgd=38006811, *pte=02184653, *ppte=02184453
Internal error: Oops: 8000000f [#1] PREEMPT SMP ARM
Modules linked in: mxc_v4l2_capture ipu_bg_overlay_sdc ipu_still ipu_prp_enc ipu_csi_enc imx241_camera_mipi_int ipu_fg_)
CPU: 1 PID: 235 Comm: spitest Tainted: G           O    4.9.11-1.0.0+gc27010d99a3d #2
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: a81ad800 task.stack: a875a000
PC is at 0xc0906800
LR is at clk_core_enable+0x60/0xa0
pc : [<c0906800>]    lr : [<8043b2b0>]    psr: a0070093
sp : a875bdb8  ip : 00000000  fp : a84299a0
r10: a8429a80  r9 : a8429db8  r8 : 8056caec
r7 : 00000000  r6 : a84c5700  r5 : 00000000  r4 : a84c5f40
r3 : c0906800  r2 : 00000001  r1 : 07280727  r0 : 80462bc8
Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c53c7d  Table: 3886804a  DAC: 00000051
Process spitest (pid: 235, stack limit = 0xa875a210)
Stack: (0xa875bdb8 to 0xa875c000)
bda0:                                                       a84c5f40 a0070013
bdc0: a84c5700 8043c328 00000000 a8429b18 a84c5700 805728e8 a8429a24 a8429800
bde0: a875beb8 8056e8c4 a8429a24 00000000 a84299b8 80900c28 a8429db8 a8429c00
be00: a875beb8 00000000 a8429800 8056caec a8429db8 a8429a80 a84299b8 8056ed50
be20: 00000000 60070013 00000000 00000000 a875be30 a875be30 a875bed0 a8429c00
be40: a875beb8 a875beb8 a8429c00 a84c5994 00000001 00000001 a875a000 8056ed78
be60: a84c5984 a8429c00 a875beb8 8056f4a4 00000000 00000000 a875be78 a875be78
be80: a87e5ce0 a87e55f4 a84c5980 8056feb8 a8b33a0c a80e2001 00000001 a87e5ce0
bea0: 00000051 a84c5980 a87e5cc0 a87e55c0 a8429c00 a84c5994 a87e55f4 a87e55f4
bec0: a8429c00 00000000 8056ca4c a875be28 00000001 00000000 ffffff8d a875bedc
bee0: a875bedc 00000000 a875bee8 a875bee8 a6396c18 7e964040 a840dd48 a864d480
bf00: 40206b00 7e964040 a875a000 00000000 00000000 802107a8 80225c10 a80e5000
bf20: a8896500 00000005 00000000 00000000 00000000 a80dc998 a80dc998 00000002
bf40: 00000000 80201864 a864dcc0 00000000 a6396c18 801ff71c 00000000 00000000
bf60: 7e96458c a864dcc3 a864d480 a864d481 00000004 a864d480 40206b00 7e964040
bf80: a875a000 00000000 00000000 80211068 01647b00 00000001 7e964570 00000036
bfa0: 80107804 80107640 01647b00 00000001 00000004 40206b00 7e964040 00000000
bfc0: 01647b00 00000001 7e964570 00000036 7e964560 0003c340 7e964148 00000000
bfe0: 0005479c 7e963fdc 0001cdc0 76bb825c 00070010 00000004 00000000 00000000
[<8043b2b0>] (clk_core_enable) from [<8043c328>] (clk_core_enable_lock+0x18/0x2c)
[<8043c328>] (clk_core_enable_lock) from [<805728e8>] (spi_imx_prepare_message+0x2c/0x8c)
[<805728e8>] (spi_imx_prepare_message) from [<8056e8c4>] (__spi_pump_messages+0x1e4/0x4e4)
[<8056e8c4>] (__spi_pump_messages) from [<8056ed50>] (__spi_sync+0x180/0x184)
[<8056ed50>] (__spi_sync) from [<8056ed78>] (spi_sync+0x24/0x3c)
[<8056ed78>] (spi_sync) from [<8056f4a4>] (spidev_sync+0x58/0x68)
[<8056f4a4>] (spidev_sync) from [<8056feb8>] (spidev_ioctl+0x7b4/0x860)
[<8056feb8>] (spidev_ioctl) from [<802107a8>] (do_vfs_ioctl+0x9c/0x928)
[<802107a8>] (do_vfs_ioctl) from [<80211068>] (SyS_ioctl+0x34/0x5c)
[<80211068>] (SyS_ioctl) from [<80107640>] (ret_fast_syscall+0x0/0x3c)
Code: 00000000 00000000 00000000 00000000 (00001082)
---[ end trace e3fb43646077eeae ]---
note: spitest[235] exited with preempt_count 1

Labels (2)
Tags (3)
0 Kudos
1 Solution
1,521 Views
shkolnyykonstan
Contributor III

I read /Documentation and found that the DTS property with a confusing name
"cs-gpios", in addition to GPIOs, can contain values like <0> that designate
"native chip selects." The problem is that my old DTS didn't have this
property at all and BSP 4.1.15 SPI drivers worked anyway, but now it's required.

So, in my case of using i.MX6 SS0, I've added:
cs-gpios = <0>;
to my original DTS and it now works as before.

Why the SPI driver stack crashes miserably when this property is missing
is a separate issue. It's not the first time that I see drivers crashing
due to unexpected DTB contents.

View solution in original post

0 Kudos
6 Replies
1,521 Views
jimmychan
NXP TechSupport
NXP TechSupport

You may take the i.mx6q sabresd dtsi for reference.

https://community.nxp.com/external-link.jspa?url=http%3A%2F%2Fgit.freescale.com%2Fgit%2Fcgit.cgi%2Fi...

 

the ecspi1 is setup like this :

&ecspi1 {

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

               cs-gpios = <&gpio4 9 0>;

               pinctrl-names = "default";

               pinctrl-0 = <&pinctrl_ecspi1>;

               status = "okay";

 

               flash: m25p80@0 {

                              #address-cells = <1>;

                              #size-cells = <1>;

                              compatible = "st,m25p32";

                              spi-max-frequency = <20000000>;

                              reg = <0>;

               };

};

 

 

 

And the pinctrl is like this:

 

               pinctrl_ecspi1: ecspi1grp {

                                             fsl,pins = <

                                                            MX6QDL_PAD_KEY_COL1__ECSPI1_MISO              0x100b1

                                                            MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI            0x100b1

                                                            MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK               0x100b1

                                                            MX6QDL_PAD_KEY_ROW1__GPIO4_IO09                             0x1b0b0

                                             >;

                              };

 

For your case, you are using ecspi3. The ECSPI3_SS0 is mux from the pin DISP0_DAT3. The GPIO of DISP0_DAT3 is GPIO4_IO24 (ALT 5).

 

So, in the &ecspi3, the cs-gpios = <&gpio4 24 0>;

in your pinctrl_ecspi3, change the mux pin name from ECSPI3_SS0 to GPIO4_IO24, and pad setting to 0x1b0b0.

1,522 Views
shkolnyykonstan
Contributor III

I read /Documentation and found that the DTS property with a confusing name
"cs-gpios", in addition to GPIOs, can contain values like <0> that designate
"native chip selects." The problem is that my old DTS didn't have this
property at all and BSP 4.1.15 SPI drivers worked anyway, but now it's required.

So, in my case of using i.MX6 SS0, I've added:
cs-gpios = <0>;
to my original DTS and it now works as before.

Why the SPI driver stack crashes miserably when this property is missing
is a separate issue. It's not the first time that I see drivers crashing
due to unexpected DTB contents.

0 Kudos
1,521 Views
jimmychan
NXP TechSupport
NXP TechSupport

The example i.MX6Q sabresd dtsi I shown you is in the 4.1.15 BSP. This 'cs-gpios' is not the new thing in new BSP.

0 Kudos
1,521 Views
shkolnyykonstan
Contributor III

Thanks a lot Jimmy, this solved the problem! You seem to know a lot about this subject - could you provide some insight why this was changed? Instead of using the specialized i.MX6 chip select outputs, SSx, NXP has switched to use GPIOs. Is this intentional and will be kept in the future?

0 Kudos
1,521 Views
Carlos_Musich
NXP Employee
NXP Employee

Hi Shkolnny,

The latest BSP provided by NXP is 4.1.15_2, you can find it at www.nxp.com/imx6q > DOCUMENTATION tab

pastedImage_2.png

Unfortunately we do not provide support of BSPs that are not developed by NXP. Please contact the developer of the BSP you are using for support.


Regards,
Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,521 Views
shkolnyykonstan
Contributor III

Well, I found it on this page of the NXP website:

i.MX 6 / i.MX 7 Series Software and Development Tool|NXP

scroll half a page down and find:

i.MX 6 BSP Updates and Releases

Linux 4.9.11_1.0.0 [Current Release]

It looks like an NXP-released BSP to me...

0 Kudos