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

[Ulf Hansson]

On Wed, Oct 28, 2026 at 12:48 PM Sudeep Holla <sudeep.holla@xxxxxxxxxx> wrote:
>
> 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@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.
> >
>
> 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 ?

I guess we could, but that seems rather messy. According to earlier
discussions, if I recall correctly, we deliberately avoided OSI
specific DT bindings/properties, since support for OSI mode should be
detected through the FW.

Also note that the domain-idle-state DT bindings
(Documentation/devicetree/bindings/power/domain-idle-state.yaml) are
generic and used by RISC-V SBI as well.

Kind regards
Uffe