Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] arm64: dts: st: mark main supplies always-on on stm32mp257f-dk
@ 2026-10-04 11:24 Mateusz Nowicki
  2026-10-07  9:22 ` Patrick DELAUNAY
  0 siblings, 1 reply; 5+ messages in thread
From: Mateusz Nowicki @ 2026-10-04 11:24 UTC (permalink / raw)
  To: Alexandre Torgue, Maxime Coquelin
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
	linux-stm32, linux-arm-kernel, linux-kernel, Mateusz Nowicki

The vddcore, v1v8 and v3v3 regulators have no consumer in Linux, so
the regulator core disables them 30 seconds after boot. They supply
the SoC digital logic, the SoC 1.8 V analog domain and the 3.3 V board
peripherals, and must stay on while Linux runs.

Mark them always-on.

Signed-off-by: Mateusz Nowicki <mateusz.nowicki@posteo.net>
---
 arch/arm64/boot/dts/st/stm32mp257f-dk.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-dk.dts b/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
index a8f18508db3e..7a837e6fd578 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
@@ -310,14 +310,17 @@ scmi_vddio1: regulator@0 {
 	scmi_vddcore: regulator@11 {
 		reg = <VOLTD_SCMI_STPMIC2_BUCK2>;
 		regulator-name = "vddcore";
+		regulator-always-on;
 	};
 	scmi_v1v8: regulator@14 {
 		reg = <VOLTD_SCMI_STPMIC2_BUCK5>;
 		regulator-name = "v1v8";
+		regulator-always-on;
 	};
 	scmi_v3v3: regulator@16 {
 		reg = <VOLTD_SCMI_STPMIC2_BUCK7>;
 		regulator-name = "v3v3";
+		regulator-always-on;
 	};
 	scmi_vdd_emmc: regulator@18 {
 		reg = <VOLTD_SCMI_STPMIC2_LDO2>;

base-commit: f831584128ac2a36fb4fa62fe106793d08c2dbf1
-- 
2.56.0



^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] arm64: dts: st: mark main supplies always-on on stm32mp257f-dk
  2026-10-04 11:24 [PATCH] arm64: dts: st: mark main supplies always-on on stm32mp257f-dk Mateusz Nowicki
@ 2026-10-07  9:22 ` Patrick DELAUNAY
  2026-10-08 11:43   ` mateusz.nowicki
  0 siblings, 1 reply; 5+ messages in thread
From: Patrick DELAUNAY @ 2026-10-07  9:22 UTC (permalink / raw)
  To: Mateusz Nowicki, Alexandre Torgue, Maxime Coquelin
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
	linux-stm32, linux-arm-kernel, linux-kernel

Hi,

On 10/4/26 13:24, Mateusz Nowicki wrote:
> The vddcore, v1v8 and v3v3 regulators have no consumer in Linux, so
> the regulator core disables them 30 seconds after boot. They supply
> the SoC digital logic, the SoC 1.8 V analog domain and the 3.3 V board
> peripherals, and must stay on while Linux runs.
>
> Mark them always-on.
>
> Signed-off-by: Mateusz Nowicki <mateusz.nowicki@posteo.net>
> ---
>   arch/arm64/boot/dts/st/stm32mp257f-dk.dts | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/st/stm32mp257f-dk.dts b/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
> index a8f18508db3e..7a837e6fd578 100644
> --- a/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
> +++ b/arch/arm64/boot/dts/st/stm32mp257f-dk.dts
> @@ -310,14 +310,17 @@ scmi_vddio1: regulator@0 {
>   	scmi_vddcore: regulator@11 {
>   		reg = <VOLTD_SCMI_STPMIC2_BUCK2>;
>   		regulator-name = "vddcore";
> +		regulator-always-on;
>   	};
>   	scmi_v1v8: regulator@14 {
>   		reg = <VOLTD_SCMI_STPMIC2_BUCK5>;
>   		regulator-name = "v1v8";
> +		regulator-always-on;
>   	};
>   	scmi_v3v3: regulator@16 {
>   		reg = <VOLTD_SCMI_STPMIC2_BUCK7>;
>   		regulator-name = "v3v3";
> +		regulator-always-on;
>   	};
>   	scmi_vdd_emmc: regulator@18 {
>   		reg = <VOLTD_SCMI_STPMIC2_LDO2>;
>
> base-commit: f831584128ac2a36fb4fa62fe106793d08c2dbf1


For STMicroelectronics boards, the STPMIC always-on regulator are 
managed on SCMI server side in OP-TEE.

So no need to manage this constraint in Linux device tree.

This always-on  regulator are exposed only for information or to be used 
are supply for some IP.


Regards

Patrick



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] arm64: dts: st: mark main supplies always-on on stm32mp257f-dk
  2026-10-07  9:22 ` Patrick DELAUNAY
@ 2026-10-08 11:43   ` mateusz.nowicki
  2026-10-09  8:17     ` Patrick DELAUNAY
  0 siblings, 1 reply; 5+ messages in thread
From: mateusz.nowicki @ 2026-10-08 11:43 UTC (permalink / raw)
  To: Patrick DELAUNAY
  Cc: Alexandre Torgue, Maxime Coquelin, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, devicetree, linux-stm32,
	linux-arm-kernel, linux-kernel

Hi Patrick,

On 07.10.2026 11:22, Patrick DELAUNAY wrote:
> For STMicroelectronics boards, the STPMIC always-on regulator are
> managed on SCMI server side in OP-TEE.
> 
> So no need to manage this constraint in Linux device tree.
> 
> This always-on  regulator are exposed only for information or to be
> used are supply for some IP.

Thanks, that makes sense. OP-TEE keeps these rails on no matter what
Linux asks for, and the board keeps running fine.

The part I found confusing is what Linux reports. Since nothing in
Linux uses these regulators, the regulator core turns them off about
30 seconds after boot:

    [   31.713597] v1v8: disabling
    [   31.716454] v3v3: disabling

The SCMI call succeeds, so from then on regulator_summary shows
vddcore, v1v8 and v3v3 with a use count of 0, as if they were off.
In reality they are still powered.

With regulator-always-on, what Linux shows matches the hardware.
Would you still prefer to keep it out of the board DT? If so, I'm
happy to drop the patch.

Thanks,
Mateusz


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] arm64: dts: st: mark main supplies always-on on stm32mp257f-dk
  2026-10-08 11:43   ` mateusz.nowicki
@ 2026-10-09  8:17     ` Patrick DELAUNAY
  2026-10-09  9:29       ` mateusz.nowicki
  0 siblings, 1 reply; 5+ messages in thread
From: Patrick DELAUNAY @ 2026-10-09  8:17 UTC (permalink / raw)
  To: mateusz.nowicki
  Cc: Alexandre Torgue, Maxime Coquelin, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, devicetree, linux-stm32,
	linux-arm-kernel, linux-kernel

Hi,

On 10/8/26 13:43, mateusz.nowicki@posteo.net wrote:
> Hi Patrick,
>
> On 07.10.2026 11:22, Patrick DELAUNAY wrote:
>> For STMicroelectronics boards, the STPMIC always-on regulator are
>> managed on SCMI server side in OP-TEE.
>>
>> So no need to manage this constraint in Linux device tree.
>>
>> This always-on  regulator are exposed only for information or to be
>> used are supply for some IP.
>
> Thanks, that makes sense. OP-TEE keeps these rails on no matter what
> Linux asks for, and the board keeps running fine.
>
> The part I found confusing is what Linux reports. Since nothing in
> Linux uses these regulators, the regulator core turns them off about
> 30 seconds after boot:
>
>    [   31.713597] v1v8: disabling
>    [   31.716454] v3v3: disabling
>
> The SCMI call succeeds, so from then on regulator_summary shows
> vddcore, v1v8 and v3v3 with a use count of 0, as if they were off.
> In reality they are still powered.


I understood the issue, and it was a dilemma for us as well.

For information, these two traces are only temporary on DK boards: v1v8 
and v3v3 will soon

be used by nodes/drivers that are not yet upstreamed, which is why I 
would prefer to drop

the patch.

      Initially, I don't expose these SCMI always-on regulators to Linux 
on DK boards in order

       to avoid these traces.
      However, these power supplies are mandatory for some upcoming 
devices such as

      Bluetooth, Wi-Fi, HDMI, and DSI, so I add them only to prepare 
these patches


To explain the dilemma further: on STMicroelectronics boards, SCMI 
voltage domains are shared by default between Linux and cortex M33 
firmware and the voltage domain state reported to each agent reflects 
the last request, not the actual hardware value.

As a result, a shared regulator is switched off when all users, 
including the agent and OP-TEE itself, no longer use it.

Moreover, in the current SCMI specification, regulators cannot 
dynamically report supported operations in the same way clocks do with 
CLOCK_GET_PERMISSIONS.

The VOLTAGE_CONFIG_SET operation can only indicate a forbidden operation 
by returning SCMI_DENIED, and SCMI regulator drivers then return -EACCES.

However, this is not the current behavior of the SCMI server in OP-TEE 
for always-on regulators, although this may be an improvement to consider.

So, Linux SCMI regulator status does not always reflect the hardware 
state, and this is not only the case for always-on regulators.


>
> With regulator-always-on, what Linux shows matches the hardware.
> Would you still prefer to keep it out of the board DT? If so, I'm
> happy to drop the patch.


At this stage, we can probably live with that, no need to specific 
treatment for v1v8 and v3v3 and you can drop the patch.


>
> Thanks,
> Mateusz


Thanks

Patrick



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] arm64: dts: st: mark main supplies always-on on stm32mp257f-dk
  2026-10-09  8:17     ` Patrick DELAUNAY
@ 2026-10-09  9:29       ` mateusz.nowicki
  0 siblings, 0 replies; 5+ messages in thread
From: mateusz.nowicki @ 2026-10-09  9:29 UTC (permalink / raw)
  To: Patrick DELAUNAY
  Cc: Alexandre Torgue, Maxime Coquelin, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, devicetree, linux-stm32,
	linux-arm-kernel, linux-kernel

Hi Patrick,

On 09.10.2026 10:17, Patrick DELAUNAY wrote:
> At this stage, we can probably live with that, no need to specific
> treatment for v1v8 and v3v3 and you can drop the patch.

Thanks for the detailed explanation, that clears it up. I'll drop
the patch.

Thanks,
Mateusz


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-10-09  9:29 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-04 11:24 [PATCH] arm64: dts: st: mark main supplies always-on on stm32mp257f-dk Mateusz Nowicki
2026-10-07  9:22 ` Patrick DELAUNAY
2026-10-08 11:43   ` mateusz.nowicki
2026-10-09  8:17     ` Patrick DELAUNAY
2026-10-09  9:29       ` mateusz.nowicki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox