is the SION bit require to read a GPIO

[cbrake]

Hi,

I'm working with a i.MX6UL+Linux and configuring GPIO via /sys/class/gpio... If I configure a GPIO as an output, the only way I can read back the value (cat /sys/class/gpio/gpioX/value) seems to be to set the SION bit, otherwise its always 0.  Is this correct, or am I missing something?

Additionally, how does one set the SION bit in Device Tree files?  (Thus far, I've just been setting it manually to test using devmem2).

Thanks,
Cliff

[cbrake]

What is the best way to set SION in Linux Device Tree files?  This far I've taken to hacking arch/arm/boot/dts/imx6ul-pinfunc.h to do things like this:

diff --git a/arch/arm/boot/dts/imx6ul-pinfunc.h b/arch/arm/boot/dts/imx6ul-pinfunc.h

index 1bb774b9..f67252e 100644

--- a/arch/arm/boot/dts/imx6ul-pinfunc.h

+++ b/arch/arm/boot/dts/imx6ul-pinfunc.h

@@ -26,14 +26,14 @@

#define        MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06                              0x0034 0x02C0 0x0000 5 0

#define        MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07                              0x0038 0x02C4 0x0000 5 0

#define        MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08                              0x003C 0x02C8 0x0000 5 0

-#define        MX6UL_PAD_SNVS_TAMPER9__GPIO5_IO09                              0x0040 0x02CC 0x0000 5 0

+#define        MX6UL_PAD_SNVS_TAMPER9__GPIO5_IO09                              0x0040 0x02CC 0x0000 0x15 0

#define        MX6UL_PAD_JTAG_MOD__SJC_MOD                                     0x0044 0x02D0 0x0000 0 0

#define        MX6UL_PAD_JTAG_MOD__GPT2_CLK                                    0x0044 0x02D0 0x05A0 1 0

#define        MX6UL_PAD_JTAG_MOD__SPDIF_OUT                                   0x0044 0x02D0 0x0000 2 0

#define        MX6UL_PAD_JTAG_MOD__ENET1_REF_CLK_25M                           0x0044 0x02D0 0x0000 3 0

#define        MX6UL_PAD_JTAG_MOD__CCM_PMIC_RDY                                0x0044 0x02D0 0x04C0 4 0

-#define        MX6UL_PAD_JTAG_MOD__GPIO1_IO10                                  0x0044 0x02D0 0x0000 5 0

+#define        MX6UL_PAD_JTAG_MOD__GPIO1_IO10                                  0x0044 0x02D0 0x0000 0x15 0

#define        MX6UL_PAD_JTAG_MOD__SDMA_EXT_EVENT00                            0x0044 0x02D0 0x0000 6 0

#define        MX6UL_PAD_JTAG_TMS__SJC_TMS                                     0x0048 0x02D4 0x0000 0 0

#define        MX6UL_PAD_JTAG_TMS__GPT2_CAPTURE1                               0x0048 0x02D4 0x0598 1 0

@@ -84,7 +84,7 @@

#define        MX6UL_PAD_GPIO1_IO01__USB_OTG1_OC                               0x0060 0x02EC 0x0664 2 0

#define        MX6UL_PAD_GPIO1_IO01__ENET2_REF_CLK2                            0x0060 0x02EC 0x057C 3 0

#define        MX6UL_PAD_GPIO1_IO01__MQS_LEFT                                  0x0060 0x02EC 0x0000 4 0

-#define        MX6UL_PAD_GPIO1_IO01__GPIO1_IO01                                0x0060 0x02EC 0x0000 5 0

+#define        MX6UL_PAD_GPIO1_IO01__GPIO1_IO01                                0x0060 0x02EC 0x0000 0x15 0

[jamesbone · Accepted solution]

Hello Cliff,

Check this link :iMX6 Pad Mux and Pad Control · FrankBau/meta-marsboard-bsp Wiki · GitHub

The number 8 after the pad muxing macro refers to the pad control. To understand this value, you may check the iMX6 Reference Manual for register IOMUXC_SW_PAD_CTL_PAD_CSI0_DATA08. The 8 is a bitwise composition of the following:

• (0<<0) : slow slew rate
• (1<<3) : output drive strength of 150 Ohm at 3.3 V
• (0<<6) : low speed (<50 MHz)
• Bit 30 set to 1 means: software input on (SION) whcih means that the logical value of an output can be read back (see this post for discussion: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/295260)

[candy]

I'm using imx6ull GPIO1_IO03 to drive a LED, I have config the pin in the device tree, it is ok to turn on and turn off LED, that's means gpio_set_value() works well. But when I use gpio_get_value() to read the pin to toggle the LED, it always return 0.Then I tried to set the bit 30 of config register, what's in your word, SION bit as 1, unfortunately, it still does not work.

Below is the LED part configuration in the device tree

&iomuxc {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_hog_1>;
	imx6ul-evk {
		pinctrl_alpha_led0: alpha-led0 {
			fsl,pins = <
			    MX6UL_PAD_GPIO1_IO03__GPIO1_IO03  0x400010b0	
			>;
		};

		pinctrl_alpha_led1: alpha-led1 {
			fsl,pins = <
			    MX6ULL_PAD_SNVS_TAMPER1__GPIO5_IO01  0x400010b0
			>;
		};

	    /* some other nodes */
	};

	/* some other nodes */
};


/ {
	/* some other nodes */

	alpha-leds {
		compatible = "alientek-alpha,leds";

		led-0 {
			pinctrl-names = "default";
			pinctrl-0 = <&pinctrl_alpha_led0>;
			gpio = <&gpio1 3 GPIO_ACTIVE_HIGH>;
			status = "okay";
		};

		led-1 {
			pinctrl-names = "default";
			pinctrl-0 = <&pinctrl_alpha_led1>;
			gpio = <&gpio5 1 GPIO_ACTIVE_HIGH>;
			status = "okay";
		};
	};

	/* some other nodes */
};

What's may be the problem of this , why gpio_get_value dose not return pin value correctly?

[cbrake]

Thanks -- that is very helpful -- it looks the the 0x40000000 is what I'm looking for to set SION.  Should this be documented in this file?

linux/fsl,imx6ul-pinctrl.txt at master · torvalds/linux · GitHub

Do you happen to know where the processing of this bit is implemented -- I'm guessing its a virtual bit that gets processed by software, vs hardware, but would like to understand.

Thanks,
Cliff

[harald_walter3]

Hi Freescale,

we also just stumbled upon this issue after some hours of debugging. I would also like to emphasize that this should be documented somewhere.

Furthermore we are using your "Pins for i.MX" tooling in version 1.0 to generate the pin muxing part of the Linux device tree. The tool generates it wrong. At least, this has to be adapted in your tools (bit 30 must be set to 1)

[jamesbone]

SW Loopback (SION) – the SION bit (SW Input On in IOMUXC_SW_MUX_CTL)

override the regular PAD functionality and forces the input path to

be active regardless of the value driven by the corresponding

module. It can be used for:

Loop Back - Module X drives the PAD and also receive PAD value as an

input. Required by I2C,SDHC modules.

GPIO Capture - Module X drives the PAD and the value is captured by GPIO.

Loop Back to module Y - Module X drives the PAD and module Y also receives

PAD value as an input. This can be used for driving module Y input without

connecting a real device on board.