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

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

On Wed, Oct 28, 2026 at 11:59:58AM +0100, Ulf Hansson wrote:
> On Wed, Oct 14, 2026 at 9:12 PM Sudeep Holla <sudeep.holla@kernel.org> 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@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.
> 
> 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.
> 

Now I understood the requirement much better. The core issue with OSI is
that it fails unless the platform downgrades special system states to
non-system states during routine CPUIdle paths.

This leaves us with two directions for OSI:
1. Firmware Resolution: Handle state transitions entirely in firmware.
2. OS Intervention: Enforce the handling via the OS.

Though I personally prefer (1), I don't have strong arguments against (2)
now that you made me understand the requirement. Sorry for taking time,
but mentally I was assuming (1) even for OSI until your above response.

Since PC mode relies on the firmware to manage these states natively, this
binding isn't required for it. Therefore, Could we restrict this specific
binding exclusively to OSI implementations ?

-- 
Regards,
Sudeep