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

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?