Re: POWER_DOMAIN_ATTRIBUTES in SCMI

[Peng Fan <peng.fan@oss.nxp.com>]

On Tue, Feb 18, 2025 at 02:57:10PM +0100, Vincent Guittot wrote:
>On Tue, 18 Feb 2025 at 13:03, Peng Fan <peng.fan@oss.nxp.com> wrote:
>>
>> On Tue, Feb 18, 2025 at 10:41:15AM +0000, Sudeep Holla wrote:
>> >On Fri, Feb 14, 2025 at 09:20:27AM +0000, Peng Fan wrote:
>> >> All,
>> >>
>> >> Previously I posted a patch to linux to set all power domains
>> >> with "GENPD_FLAG_ACTIVE_WAKEUP" set in
>> >> drivers/pmdomain/arm/scmi_pm_domain.c
>> >
>> >Yes, I remember ACK-ing that and now I am thinking why 😄.
>> >The description of the flag GENPD_FLAG_ACTIVE_WAKEUP says:
>> >"Instructs genpd to keep the PM domain powered on, in case any of its
>> >attached devices is used in the wakeup path to serve system wakeups."
>> >
>> >Does that mean all the SCMI power domains remain powered on with this
>> >flag ? If so, that sounds wrong to me. I hope it is not the case and it
>> >is effective only if the device attached is wakeup source.
>>
>> Only when the device is setup wakeup source, the genpd framework
>> will take this flag as keeping power domain on.
>>
>> Without this flag, even if the device setup as wakeup source, the
>> device's power domain will still be powered off.
>>
>> >
>> >> But in the end we find that some power domains
>> >> could be in off state while it still could wakeup
>> >> the system. And we have a downstream patch
>> >> +               if (!strcmp(scmi_pd->name, "hsio_top"))
>> >> +                       scmi_pd->genpd.flags = 0;
>> >>
>> >
>> >There you go, so you simply rushed some solution upstream to carry less
>> >patches downstream but this time you got bitten again. Sorry, but I am
>> >seeing a pattern from you here and I don't really like that.
>>
>> I not wanna to argue here.
>> I DO care reputation. If I do something wrong, I will improve.
>>
>> >
>> >> So I am wondering to extend the attributes of SCMI spec,
>> >> Saying In SCMI spec(DEN0056E)
>> >> 4.3.2.5 POWER_DOMAIN_ATTRIBUTES
>> >> Page 44 of 210:
>> >>
>> >> Bit[26]: If set to 1, the power domain could
>> >> wakeup the system with power state
>> >> set as off.
>> >>
>> >
>> >This is not what the above flag is all about. It just instructs genpd
>> >to keep the power domain ON as the device attached to it could be a wakeup
>> >source. They are not one and the same. If the device is marked wakeup in
>> >the DT and it is both wakeup capable and is enabled, it shouldn't request
>> >the power domain to be powered off when suspending. Why is that not
>> >sufficient here ? What am I missing ? I am interested in knowing it as
>> >it is important to fix the issue you are trying to address here.
>>
>> The flag must be set if the power domain needs to keep power on to have
>> the wakeup capability.
>>
>> But in some case, a power domain no need to keep power on and it still
>> have wakeup capability from hardware perspective.
>>
>> For example usb phy in i.MX95, its power domain is off, but it could still
>> wakeup the SoC. But with the GENPD_FLAG_ACTIVE_WAKEUP set, the power domain
>> will not be powered off, so more power consumption in suspended state.
>
>This probably means that the wakeup mechanism is not in the same power
>domain but in another one that is kept on while the device is
>suspended and the main power domain is off. Do you have more details
>about this wakeup source that works with powerdomain being off ?

When power domain is off, some internal registers are retained and
not lost. And there is external always on power rail for always
on hardware logic.

Regards,
Peng

>I vaguely remember some old discussions about inband/outband wakeup
>source settings for devices which enable drivers to specify if the
>wakeup source is in or out of the power domain and if we should keep
>it on or not. But I can't remember the details; Ulf should have more
>details
>
>>
>> So I am requesting extending spec to give agents the information whether
>> the power domain could wakeup HW system in powered off state.
>
>I tend to agree with Sudeep that it doesn't make sense to say that a
>power domain can be off but the powered devices can still wakeup the
>system. It usually means that the wakeup is not powered by the main
>power domain
>
>>
>> >
>> >> This is just an idea in my mind, I not
>> >> write code to verify, just wanna to see
>> >> any comments from your side.
>> >>
>> >
>> >I wonder if we need to revert GENPD_FLAG_ACTIVE_WAKEUP flag enabling on
>> >all SCMI power domains if that is not solving the problem you thought it
>> >would.
>>
>> Revert the flag will cause a power domain not able to wakeup SoC if the
>> power domain needs power state on to have wakeup capability.
>>
>> I am not sure other vendor's SoC design. To i.MX95, without this flag set,
>> the NETC will lose wakeup on LAN capability.
>>
>> Regards,
>> Peng.
>>
>> >
>> >--
>> >Regards,
>> >Sudeep
>> >
>>