* [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 [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
all inboxes | Powered by JetHome®