Should reg_force_sleep_moci have pinctrl instead og assigning it to gpio4?

I am wondering why the new pinctrl_ctrl_sleep_moci is assigned to &gpio4 in imx8mp-verdin-dev.dtsi when the regulator reg_force_sleep_moci that uses it is defined in imx8mp-verdin-dev.dtsi?

Would it not be better to add the pinctrl to the regulator so when it is disabled in a custom device-tree (that is initially based on the dev dtsi) it doesn’t register the pin mux to gpio4?
Especially as this is also a pin that can have a mux used for sound/audio driver (apparently).

Regulator definition is here:
imx8mp-verdin.dtsi - reg_force_sleep_moci

GPIO4 Mux Definition is here:
imx8mp-verdin-dev.dtsi - pinctrl-0

My understanding is that I could just provide an overlay and disable the reg_force_sleep_moci, but that will not free the pin mux from &gpio4?

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

Your inquiry touches on a nuanced aspect of device tree configuration, particularly regarding the management of pin multiplexing (muxing) and its implications for hardware resources like GPIOs and regulators. Assigning pinctrl settings directly to a regulator or any other peripheral in the device tree serves to define the default state of pins associated with that peripheral. This approach ensures that the pins are correctly configured for the peripheral’s operation as soon as the peripheral is initialized, without requiring additional configuration steps.

In the context of the reg_force_sleep_moci regulator and its association with &gpio4, the decision to assign the pinctrl_ctrl_sleep_moci to &gpio4 directly, rather than through the regulator, likely stems from a design choice aimed at ensuring that the GPIO pin is configured correctly for the regulator’s operation, regardless of the regulator’s state. This is particularly relevant in low-power or sleep modes, where the correct pin configuration is crucial for minimizing power consumption.

However, your concern about the flexibility of this configuration, especially when considering custom device trees and the need to repurpose pins for different functions (like audio in your example), is valid. In such cases, adding a pinctrl node to the regulator in the device tree could indeed offer more flexibility. This would allow for the pin configuration to be more easily overridden or disabled in a custom device tree overlay, thereby freeing the pin for other uses without being constrained by the default configuration tied to the regulator.

To address your specific question: if the goal is to repurpose the pin used by reg_force_sleep_moci for another function while ensuring it is not muxed to &gpio4 when the regulator is disabled, you would indeed benefit from defining a pinctrl node for the regulator in your custom device tree or overlay. This way, you can explicitly control the pin’s configuration and ensure it is not automatically configured for &gpio4 when the regulator is disabled. This approach requires careful management of the device tree to ensure that pin configurations do not conflict and that all peripherals are correctly configured for their intended purposes.

In summary, while the original device tree configuration was likely chosen for its simplicity and reliability in common use cases, your application’s specific requirements justify modifying the device tree to better manage pin configurations, especially when disabling certain peripherals like regulators.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

How to Customize Device Trees | Toradex Developer Center.

Having looked a bit deeper (and failing a few builds), I believe the solution for the current format would be to add the following to my custom device tree (or overlay):

&gpio4 {
    pinctrl-0 = <>;
};
&reg_force_sleep_moci {
    state = "disabled";
};
// ... other gpio remapping configurations ...

Is this the best approach or is thee a better way?

Hello @izzy_building,

The reg_force_sleep_moci is assigned this pin as a GPIO here. However, as this pin is used as a GPIO, it is also assigned to gpio4.

If you need to use this pin in some other way, you could configure it as you put here:

However, this signal is used as a power control signal for peripherals, it can be used for other purposes, but we do not recommend it.
Can you use another pin in its place for your application?

Best Regards,
Bruno

Hi @bruno.tx,

Unfortunately I cannot change the pin usage.
I will have to get the details, but from what I have been told, this is the only possible pin we can use for the specific audio device we are using.

Our current hardware is already set-in-stone and only changes we can make are in OS and software.

Is there something that will still use this GPIO when using the config I suggested above?
Surely there should be a way to disable everything except my device?

Regards,
Izzy

EDIT:
I have just asked and apparently this is because we need SAI3 in Slave mode, which requires that GPIO Pin (and there is no other alternative).
I hope that makes sense. Any advice would be greatly appreciated.

Hello @izzy_building,

Thanks for the clarification.

When using the configuration you have above, Linux should not use this GPIO pin and you should be able to configure it to be used with SAI3.

However, u-boot will still use this pin, as you can see here.
The most proper solution would be to also change the configuration of this pin from the u-boot device tree and rebuild u-boot.

That being said, depending on the peripheral you connect to this SAI port, it may be acceptable that the pin is driven when u-boot is starting.
It could be that if both the peripheral and SoM drive the pin with opposite polarities, the rated current is exceeded on the pin or the peripheral does not start properly.
Therefore, you would need to check if not making this change won’t cause problems to the peripheral or the SoM.

Best Regards,
Bruno