Re: [PATCH 2/3] pmdomain: Add support for system-suspend-only states

[Ulf Hansson]

On Wed, Oct 14, 2026 at 9:12 PM Sudeep Holla <sudeep.holla@xxxxxxxxxx> wrote:
>
> On Tue, Oct 13, 2026 at 12:11:36PM +0200, Ulf Hansson wrote:
> > On Fri, Oct 9, 2026 at 5:27 PM Sudeep Holla <sudeep.holla@xxxxxxxxxx> wrote:
> > >
> > > On Fri, Oct 09, 2026 at 04:26:38PM +0200, Ulf Hansson wrote:
>
> [...]
>
> > > > If that's the case, besides that the cluster PM domain topology must
> > > > be modelled accordingly, the display device should be hooked up to the
> > > > cluster PM domain it belongs to.
> > > >
> > >
> > > Ah, I thought that's the way the whole domain-idle was modelled as we
> > > started this OSI discussion a decade ago with an example of CPU clusters
> > > sharing power domains with some other devices. I am surprised if that is
> > > not the case already 🙁.
> >
> > It works fine today, I was just trying to explain how it works,
> > considering the use case that you brought up.
> >
>
> Ah OK, good to hear. For once, it sounded like that's not the case. My bad.
>
> > >
> > > > Beyond that, it's the corresponding display driver that becomes
> > > > responsible for what should happen during system suspend. If the
> > > > screen needs to stay on it may need to call device_set_awake_path()
> > > > for the display device - unless it's a decision for user space that
> > > > can control the behaviour for the display device via its sysfs node.
> > > > If things are managed accordingly, genpd_finish_suspend() may decide
> > > > to keep the corresponding PM domain powered on during system suspend.
> > > >
> > >
> > > But the s2idle and s2ram anyways suspends all the devices, so they need
> > > to vote in for the power domains to be turned off. If they are supposed
> > > to stay on, the system enters the state it can based on the other votes.
> > >
> > > > The above said, $subject patch doesn't change any of this. It only
> > > > allows us to use more states (deeper), which are limited to system
> > > > suspend (s2idle).
> > > >
> > >
> > > Still not convinced, if all devices are plugged in to the power domain
> > > hierarchy correctly and the domain-idle states represent or carries
> > > the entire system power domain topology, we shouldn't need this extra
> > > information. Having it make cause issues when it conflicts with the
> > > topology information IMO.
> >
> > No, it's still not sufficient to model the power domain hierarchy correctly.
> >
> > These "system states" are special since they require additional
> > coordination in FW/HW, to take into account votes not directly
> > controlled by Linux.
> >
>
> But if Linux doesn't control, some other entity would vote and until then
> the system shouldn't enter that state. Without knowing that it is system
> state, will the kernel be unable to choose that state as it hidden vote
> is invisible/not tracked ? I trying to understand why if Linux chooses
> that system level state as part of idle loop, the platform can't downgrade
> if all the voting requirements are not met. I am struggling with that
> and want to make sure we are not working around a broken firmware.

For OSI, all the FW would be able to do is to return an error. But
that doesn't prevent Linux from trying the same idle state again and
again.

For PC mode, the FW should be able to downgrade the vote. Although,
from the cpuidle governor point of view that would be suboptimal as it
means that we will try to use an idle state that isn't really possible
to enter.

>
> Sorry for being pedantic, but some real example would help to understand
> it IMO.

I will coordinate with Maulik to try to share some examples.

>
> > I realize that the description in patch1 should be extended a bit to
> > explain this better. In principle, we can compare this with the PSCI
> > SYSTEM_SUSPEND support. The difference would be that PSCI
> > SYSTEM_SUSPEND is limited to support only one state, while the
> > $subject series would allow us to support multiple.
> >
>
> I understand that part. SYSTEM_SUSPEND is sort of platform co-ordinated
> once the requirement for entering is met.

Right! And I think that kind of explains the problem we are looking at
quite well.

These "system-states" are similar to how PSCI SYSTEM_SUSPEND works.
There is additional coordination needed in the FW to be able to enter
these states.

>
> > In regards to ACPI. I think this is as simple as comparing it with the
> > list of ACPI S-states.
> >
>
> I need to check if we use ACPI S-states via S2Idle which is the case with
> this patch set I assume.

Yes, this series enables the "system-states" to be used for S2Idle -
and prevents them from being used for the regular CPUIdle path.

Kind regards
Uffe