Effect: GPIO always output high

[kesaco]

Hi all,

I am using Linux Kernel 4.1 on an iMX27 with no trouble until now.

I want to use GPIO 27 on port D which is number 123 in Linux.

With a scope probe I see the signal is high at boot time. No error is displayed when exporting it from the sysfs, but the signal does not go low when I "echo 0 > value".

By searching sentences like "GPIO always on" within google I figured out that the problem could be due to a wrong pin muxing. The imx27-pinfunc.h file (arch/arm/boot/dts/) shows that PD27 may also be a Slave Select signal for SPI (MX27_PAD_CSPI1_SS1__GPIO4_27). But I also read that if SPI was not enabled in the device tree then the function used for the gpio would be "gpio" and not "primary function" (SPI SS) nor "alternate function". Am I right ?

The imx27.dtsi file (from kernel mainline) has the three SPI fields set to "disabled". My own device tree source includes this file and declares absolutely no node with SPI enabled (I do not use it).

So any guess on how I could get the mastery of that GPIO back ?

Is the SPI/muxing source of the problem a valid idea ?

Thanks in advance.

Regards,

Miquèl

NB 1: I am sure there is no problem with my syntax on how to export gpio, I use it really often.

NB 2: I know this pin works because with an older kernel (2.6) on the same hardware I may toggle the signal by the exactly same sequence of operations.

[fabio_estevam]

Can you post your dts file here?

[kesaco]

The problem I described above appears with both the full DTS file and also a lightweight one with only elementary fields.

Please find attached the light one because it is much easier to read and additional information in the full one is not relevant since the GPIO still be always high.

I also observe the following: the GPIO goes high during barebox operations (bootloader). On the old system (Linux 2.6) it goes down at boot time after a few seconds. On the new system (Linux 4.1) it never goes down.

[fabio_estevam]

I don't see GPIO4_27 present in your dts.

[kesaco]

Fabio Estevam a écrit:

I don't see GPIO4_27 present in your dts.

That is right. I thought there was no need to declare it in the pinmuxing area as long as SPI was not enabled by an "okay" in the DTS file.

So I tried to add it within the iomuxc node besides the UART1 subnode (see below) but I see no difference. Maybe this is not the right way to declare "general" pin muxing ?

For my (little) experience with device trees, anytime I wrote a subnode of the iomux controller I then called that subnode from another subnode corresponding to a device with a "compatible" field and a corresponding driver. But here there is no such node with a reference to "pinctrl_general" (example below).

&iomuxc {

        nvp {

                pinctrl_uart1: uart1grp {

                        fsl,pins = <

                                MX27_PAD_UART1_TXD__UART1_TXD 0x0

                                MX27_PAD_UART1_RXD__UART1_RXD 0x0

                                MX27_PAD_UART1_CTS__UART1_CTS 0x0

                                MX27_PAD_UART1_RTS__UART1_RTS 0x0

                        >;

                };

                pinctrl_general: generalgrp {

                        fsl,pins = <

                                MX27_PAD_CSPI1_SS1__GPIO4_27 0x0

                        >;

                };

       };

};

[fabio_estevam · Accepted solution]

If a pin does not belong to any node then you could put it to pinctrl_hog. See arch/arm/boot/dts/imx6qdl-sabreauto.dtsi for reference.

[kesaco]

How did I missed that !

Thank you very much. So it worked by editing the ioxmuxc node like that (the changes are in bold) :

&iomuxc {

        pinctrl-names = "default";

        pinctrl-0 = <&pinctrl_hog>;

        nvp {

                pinctrl_uart1: uart1grp {

                        fsl,pins = <

                                MX27_PAD_UART1_TXD__UART1_TXD 0x0

                                MX27_PAD_UART1_RXD__UART1_RXD 0x0

                                MX27_PAD_UART1_CTS__UART1_CTS 0x0

                                MX27_PAD_UART1_RTS__UART1_RTS 0x0

                        >;

                };

                pinctrl_hog: hoggrp {

                        fsl,pins = <

                                MX27_PAD_CSPI1_SS1__GPIO4_27 0x0

                        >;

                };

       };

};