AnsweredAssumed Answered

How to use Sysfs GPIO on pad EIM_D29 of the IMX6dl

Question asked by Thijs Boerman on Jun 3, 2020
Latest reply on Jun 3, 2020 by igorpadykov

I cannot get the GPIO working on one of the pins on the efusA9 SOC. It concerns the EIM_D29 pin. I did get the EIM_D28 to be controllable through the sysfs interface. In the default configuration provides by F&S these pins are used for UART2_RTS_B AND UART2_CTS_B respectively.

 

In the device-tree file, I found the following code:

#ifdef CONFIG_EFUSA9_UART_B
    /* UART2 on pins 104, 102, 106, 108 (port B)*/
    pinctrl_uart2_1: uart2grp-1{
        fsl,pins = <
            MX6QDL_PAD_EIM_D26__UART2_TX_DATA 0x1b0b1
            MX6QDL_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
#ifdef CONFIG_EFUSA9_UART_B_RTSCTS
            MX6QDL_PAD_EIM_D28__UART2_CTS_B 0x1b0b1
            MX6QDL_PAD_EIM_D29__UART2_RTS_B 0x1b0b1
#endif /* CONFIG_EFUSA9_UART_B_RTSCTS */
        >;
    };
#endif /* CONFIG_EFUSA9_UART_B */

and:

#ifdef CONFIG_EFUSA9_UART_B
/* UART2 on pins 104, 102, 106, 108 (port B)*/
&uart2 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_uart2_1>;
#ifdef CONFIG_EFUSA9_UART_B_RTSCTS
    uart-has-rtscts;
#endif
    status = "okay";
};
#endif /* CONFIG_EFUSA9_UART_B */

Because I want to control these lines myself from the Linux userspace and not be controlled by the UART driver, I commented out the declaration of the CONFIG_EFUSA9_UART_B_RTSCTS macro. After this change, the CTS line did not change state anymore when sending data over this UART port.

 

To make these lines controllable through the sysfs interface I added the following lines iomuxc hog group:

#ifndef CONFIG_EFUSA9_UART_B_RTSCTS
    /* IO-board software update lines */
    MX6QDL_PAD_EIM_D28__GPIO3_IO28 0x13059
    MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x13059
#endif

Making the iomux hog group look like:

&iomuxc {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_hog_1>;

    imx6qdl-efusa9 {
        /* Pin configs that don't belong anywhere else */
        fsl,pins = <

        ..... /* Other pin declations */

#ifndef CONFIG_EFUSA9_UART_B_RTSCTS
         /* IO-board software update lines */
         MX6QDL_PAD_EIM_D28__GPIO3_IO28 0x13059
         MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x13059
#endif
         >;
    };

..... /* Other pin control groups */

I checked that in all other device-tree files the EIM_D28 and  EIM_D29 pads are not mentioned.

 

Because I could not get the GPIO working on pin EIM_D29 I thought maybe it was not connected to the GPIO module. I found the following thread: DTS files- syntax for gpio-ranges with iomuxc?. This led me to believe that the GPIO module was in fact configured to control the pins I want as seen in the following lines:

 

&gpio3 {
    gpio-ranges = <&iomuxc 0 97 2>, <&iomuxc 2 105 8>, <&iomuxc 10 99 6>,
              <&iomuxc 16 81 16>;
};

By the logic of Charlie Schultz and line 3 of the last code section, GPIO3_16 to GPIO3_25 are connected to pad IOMUXC_SW_MUX_CTL_PAD_EIM_DATA16 to IOMUXC_SW_MUX_CTL_PAD_EIM_DATA31.

 

After a lot of searching and trial and error, I still have not figured out why I cannot control the EIM_D29 line.

I would be glad if someone could help me out!

Outcomes