AM67A: Pinctrl of GPIO (PU/PD) seems overwritten when requesting the line via gpiod

Martin Höhn

Part Number: AM67A

Tool/software:

I discovered an interesting behavior with the pinctrl of GPIOs in conjunction with internal PU/PD on an AM67A based board (BeaglY-AI).

It started that I wanted to use a GPIO as input via the gpio-keys driver.

To keep it easy I configured the pin as GPIO with internal Pull-Up resistor.

gpio-keys {
	compatible = "gpio-keys";
	pinctrl-names = "default";
	pinctrl-0 = <&hat_36_gpio_pu>;
	
	key {
		label = "S1-BTN";
		/* HAT 36 (GPIO 16) */
		gpios = <&main_gpio1 7 GPIO_ACTIVE_LOW>;
		linux,code = <30>;
	};
};

The pinctrl definition looks like the following:

hat_36_gpio_pu: hat-36-gpio-pu-pins {
	pinctrl-single,pins = <
		J722S_IOPAD(0x194, PIN_INPUT_PULLUP, 7) /* (A25) MCASP0_AXR3.GPIO1_7 */
	>;
};

But with that I discovered that the pull-up gets lost when the gpio-key driver is probed, so the pin is floating.

I then tried to investigate a bit and it seems that whenever I request the line (kernel- or userspace) via gpiod the pull-up definition is lost and the pin is floating.

That can also be seen, when watching the pinctrl register.

Before requesting line with gpiod:

Pin state	Pinctrl register	Output gpioinfo
Pulled up	0x00060007	line 7: “GPIO16” unused input active-high

When line is requested:

Please note that I tested to request the line with and without a defined bias, but this didn't have any effect on the result.

Pin state	Pinctrl register	Output gpioinfo
Floating	0x00050007	line 7: “GPIO16” “btn-python-example” input active-high [used pull-up]

When line is released:

Pin state	Pinctrl register	Output gpioinfo
Floating	0x00050007	line 7: “GPIO16” unused input active-high

Because I don't have a reference board with the AM67A, I wasn't able to check, if that behavior is there present too.

However I checked it on an AM64x EVM (same Kernel tree and version) and there it doesn't occur.

Here the definition of a internal pull-up / pull-down via pinctrl remains after line request.

The definition of the bias when requesting the line via gpiod doesn't have any effect too.

For the tests I used ti-linux-6.12.y (tag 11.00.12).

Can somebody reproduce that on a reference design board, or does somebody know why that happens?

28 days ago

0 Anshu Madwesh 24 days ago

TI__Mastermind 18460 points

Hello,

Let me look into this and get back to you on Monday.

Thanks,

Anshu

0 Anshu Madwesh 23 days ago in reply to Anshu Madwesh

TI__Mastermind 18460 points

Hello,

I don't have a AM67A board to test this on.

Lets try to directly write to the GPIO register instead of using the gpiod API. I'm thinking that would indicate if the behavior is caused by the API itself or the act of changing a GPIO.

Can you run these commands then check the PADCONFIG register:

devmem2 0x00601018 w 0x80
devmem2 0x00601010 w 0x0
devmem2 0x00601014 w 0x80

Thanks,

Anshu

0 Martin Höhn 19 days ago in reply to Anshu Madwesh

Prodigy 20 points

Hello, and thank you for your reply.

I'm not sure about the GPIO register because I couldn't find its description.

However, I just ran the commands and checked the PADCONFIG register after each write.

I can say that the PADCONFIG register doesn't change when writing to the GPIO register.

However, the physical level of the pin does change.

After the first write command, the physical level doesn't change.

So the pin is still floating, when the line has been already requested, and is still pulled-up, when the line has not yet been requested.

After the second write command, the level changes, and the pin is pulled down.

The third write command doesn't affect the physical level.

Please let me know if you need more information or if you would like me to perform additional checks.

0 Anshu Madwesh 18 days ago in reply to Martin Höhn

TI__Mastermind 18460 points

Hello,

Thanks for the updates.

I did some more digging into this. There is a pin control driver that manages the PADCONFIG registers: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/pinctrl/pinctrl-single.c?h=ti-linux-6.12.y.

There's a function that handles the GPIO interactions within that driver: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/pinctrl/pinctrl-single.c?h=ti-linux-6.12.y#n404

It looks like the code sequence executes this 'else' block which changes the bits: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/pinctrl/pinctrl-single.c?h=ti-linux-6.12.y#n433

From my understanding, this might be a possible cause of why the bits change. This same 'else' block doesn't seem to execute on AM62x from my testing.

I've filed a bug with the software development team since this is unexpected behavior. I don't have a reason on why its doing these bitwise operations at the moment so I'll need to have some discussions.

Thanks,

Anshu

Processors

Processors forum

AM67A: Pinctrl of GPIO (PU/PD) seems overwritten when requesting the line via gpiod