Re: POWER_DOMAIN_ATTRIBUTES in SCMI

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

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.

So I am requesting extending spec to give agents the information whether
the power domain could wakeup HW system in powered off state.

>
>> 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
>