What's the role of pinctrl_additionalgpio?

Technical Support
, ,
1

Hi,

I’m playing with dtb for several months now, but it is still not clear what is the role of pinctrl_additionalgpio group.

I’ve initially believed it is not used at all, but it seems the setting of a gpio in it have an impact on other groups.
Is it used by u-boot, by kernel as default setting or mask?

Regards

2

We use the pinctrl_additionalgpio group for defining pins as GPIO. pinctrl_additionalgpio is just a pinctrl node name chosen by us. It is not used by u-boot but by Linux kernel. If a pin has been pin multiplexed as GPIO, one would have to remove that pin multiplex setting, to mutiplex it to another alternate function.

3

Ok thanks.

Which “driver” is using this pinctrl node? I’m not able to find it in the kernel sources?
Is it automatically used at start-up or only if a gpio is used via /sys/class/gpio interface?

Regards

4

The Vybrid pinctrl driver will take care of muxing the pins defined under the iomuxc node.

5

Those muxes won’t be applied by default, they only get applied once somebody (e.g. user-space via sysfs GPIO) requests the particular GPIO. See imx_pmx_gpio_request_enable in pinctrl-imx.c.

6

Thanks for clarifications.

7

Is there a way to address the RTS modem line as a GPIO to set it low at u-boot start time in board_init()?

8

Am I correct in the assumption that you are trying to hijack an old question here? Please do ask a new question, thank you.

9

Hi @stephan.tx,

Sorry to bring up this old question again. We upgraded our VF50 products to use Scarthgap and the upstream Linux kernel 6.12. The system boots and most functionalities work correctly, but I still don’t understand how pinctrl_additionalgpio is applied, since this group is orphaned and not bound to any driver. This group definition was somehow applied correctly on kernel 4.4, but not on 6.12.

While trying to understand the mechanism, I saw your reply here. From what I can see, the method you mentioned (imx_pmx_gpio_request_enable) was removed in 2017 with the commit below.

SHA-1: a5c771e6cbdbe026d933c28a7705f6246bac7e64

  • pinctrl: imx: remove gpio_request_enable and gpio_disable_free

gpio_request_enable/disable_free actually are not quite necessary as
standard IMX pinctrl binding already sets GPIO mux from device tree,
e.g. VF610_PAD_PTB20__GPIO_42 or MX7D_PAD_SD2_CD_B__GPIO5_IO9
No need to do it again in gpio_request_enable.

And according to Stefan:
“For all GPIO I checked in upstream device trees we assign a pinctrl
to the same node, so in all cases gpio_request_enable/disable is really
unnecessary.”

So it should be safe to simply remove it.

Note that this changes semantics for Vybrid, e.g.
"The two functions have been introduced for Vybrid (through
SHARE_MUX_CONF_REG) and mux pins as GPIOs automatically when a GPIO
gets requested. The automatic mux is optional by the pinmux/gpio
subsystem semantics, and other NXP devices do not use it, instead an
explicit pinctrl node is added in the device tree to mux GPIOs where
required. Hence this change aligns Vybrid to other NXP (i.MX) devices.

Note that all upstream device tree assign proper pinctrl properties
where GPIOs are used so no change is necessary for device trees."

Cc: Alexandre Courbot gnurou@gmail.com
Cc: Shawn Guo shawnguo@kernel.org
Cc: Fugang Duan fugang.duan@nxp.com
Cc: Bai Ping ping.bai@nxp.com
Acked-by: Stefan Agner stefan@agner.ch
Signed-off-by: Dong Aisheng aisheng.dong@nxp.com
Signed-off-by: Linus Walleij linus.walleij@linaro.org

v4.4:

v6.12:

And v6.12 doesn’t have it anymore.

In the upstream kernel, there are other orphan groups as well for example:

So, can we say that the mechanism you mentioned is no longer available in the upstream code for handling orphaned nodes?

Thanks.

10

Hello @Fide,

Can you open another thread so we can address the specific issue you are facing on kernel 6.12?
There, you can link this thread as it is related.

Best Regards,
Bruno