Re: POWER_DOMAIN_ATTRIBUTES in SCMI

[Sudeep Holla <sudeep.holla@arm.com>]

On Tue, Feb 18, 2025 at 04:02:58PM +0100, Ulf Hansson wrote:
> On Tue, 18 Feb 2025 at 14:57, Vincent Guittot
> <vincent.guittot@linaro.org> 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 ?
> > 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

Thanks Vincent for starting this discussion, much appreciated!

>
> Vincent, you have a great memory! :-)
>
> Indeed I tried to post a series (I can dig it up, if you want?) that
> allowed the driver to instruct upper layers, such as buses and PM
> domains whether the wakeup is managed in-band or out-band.
>

Right, this distinction must be clarified in i.MX case as I don't follow
their use case yet. Peng ?

> An example could be an SDIO irq, being re-routed from a regular DATA
> line that is managed by the SDIO/MMC controller to a GPIO pin during
> system suspend. Another similar use-case with a potential similar
> wake-up configuration, is waking up from a UART console.
>
> My point is, the SDIO/MMC controller could be configured as a wakeup
> source, while it's actually the GPIO pin that is managing the wakeup.
> In this case, typically the GPIO irq can be managed from an always-on
> logic/PMIC, which means there is no reason to keep the PM domain
> powered-on for the SDIO/MMC controller during system suspend.
>

Good explanation and example. Thanks again.

> At the moment we don't have any way to express this kind of
> configuration, I think.
>

Understood.

> >
> > >
> > > 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
>
> I tend to agree. In general, I think we should always use
> GENPD_FLAG_ACTIVE_WAKEUP, but we are lacking a way to inform genpd
> (and other upper layers) that the wakeup-irq is managed out-band,
> which means genpd can still be powered-off.

Thanks Ulf, that's reassuring that SCMI is misusing or using incorrectly
some core genpd feature.

--
Regards,
Sudeep