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

[Sudeep Holla <sudeep.holla@kernel.org>]

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@kernel.org> 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.

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

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

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

-- 
Regards,
Sudeep