Should reg_force_sleep_moci have pinctrl instead og assigning it to gpio4?

[izzy_building]

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?

[ToradexAI]

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?

---

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:

Pinmuxing i.MX 8M Mini/Plus Based Modules | Toradex Developer Center

How to Customize Device Trees | Toradex Developer Center.

[izzy_building]

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?

[bruno.tx]

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:

@izzy_building

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

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

[izzy_building]

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.

[bruno.tx]

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

[izzycoding]

Hi,

As far as I can tell the device tree in u-boot still has the previous format. Is this due to be updated to using the regulator format?
Not sure how I can modify this properly to ensure it doesn’t cause any issues.
Can you advise what change you would suggest?

Regards,

[bruno.tx]

Hello @izzycoding,

@izzycoding

As far as I can tell the device tree in u-boot still has the previous format. Is this due to be updated to using the regulator format?

What do you mean by “the device tree in u-boot still has the previous format”?

---

@izzycoding

Not sure how I can modify this properly to ensure it doesn’t cause any issues.
Can you advise what change you would suggest?

This can be done similarly to how it is done in the Linux device tree.
If you are using Yocto, you can create a patch to u-boot and add it in a .bbappend file.
The process is very similar to the one for the Linux kernel.
If you are using Torizon OS, you will need to build Torizon OS from source and create a patch, the same as above.

Best Regards,
Bruno

[izzy_building]

Hi @bruno.tx,

What I mean by u-boot device tree having the previous format is that it is not defined using the regulator as it is in the linux-kernel device tree (Can see this section in patch details below).

I believe I have a patch for this now, but would like to put it here for a sanity check (and in case it may be useful for anyone in the future)…

From 6f3d57d5a0105f5531d2ecf42cb777d32753d712 Mon Sep 17 00:00:00 2001
From: John Doe <johndoe@example.com>
Date: Wed, 17 Jul 2024 11:03:39 +0100
Subject: [PATCH] moci sleep modification

---
 arch/arm/dts/imx8mp-verdin.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/imx8mp-verdin.dts b/arch/arm/dts/imx8mp-verdin.dts
index 19ce3ee193..0d50d8c220 100644
--- a/arch/arm/dts/imx8mp-verdin.dts
+++ b/arch/arm/dts/imx8mp-verdin.dts
@@ -94,11 +94,11 @@
 	ctrl_sleep_moci {
 		gpio-hog;
 		/* Verdin CTRL_SLEEP_MOCI# (SODIMM 256) */
-		gpios = <29 GPIO_ACTIVE_HIGH>;
+		//gpios = <29 GPIO_ACTIVE_HIGH>;
 		line-name = "CTRL_SLEEP_MOCI#";
 		output-high;
 		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_ctrl_sleep_moci>;
+		pinctrl-0 = <>;
 	};
 };
 
-- 
2.34.1

Adding this patch via the u-boot-toradex_%.bbappend in my layer, this would appear to disable the use of the pin that could potentially conflict with my custom linux kernel device tree and board device that is using the SAI3 interface in slave mode.

Please let me know if there is a better alternative solution to this.

[izzy_building]

Following on from this…
I have applied the above patch and this builds, but fails to boot.
From the error message there is something that is specifically trying to use pinctrl_ctrl_sleep_moci.
Have had to jump on another priority issue, but will come back to this later with the full boot error logs to help identify what I have done wrong.

[bruno.tx]

Hello @izzy_building,

Noted, thanks for the update.

The approach above should have the intended effect.
The full boot logs will be useful to see what may be causing the problem.

Best Regards,
Bruno