Re: [PATCH] arm64: dts: st: mark main supplies always-on on stm32mp257f-dk

[Patrick DELAUNAY <patrick.delaunay@foss.st.com>]

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