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

[Val Packett <val@packett.cool>]

On 10/6/26 6:15 AM, Sudeep Holla wrote:
> On Mon, Oct 05, 2026 at 08:59:43PM +0530, Maulik Shah wrote:
>> Some domain idle states require system-wide coordination and should not be
>> selected during regular CPU idle. However those states remain valid for
>> system-wide suspend like s2idle.
>>
>> Add a per-state system_state boolean and populate it from the system-state
>> property. Make the genpd governor skip these states during CPU idle. Leave
>> the system wide suspend path unchanged so s2idle can select them.
> Instead of this I am thinking if we can QoS cpu latency setting and block
> system level states normally. Since s2idle is user driven, it should be
> controllable via user-space and we don't have to define bindings again
> if systems that use platform-coordinated needs this too. They may not
> use domain-idle-states.

Messing with latency sounds like a hack. It seems like some system-level 
states are just explicitly provided for runtime idle while others are 
only intended for system suspend. That intention should be 
captured/documented by the device tree explicitly as well.

I don't have access to HW docs but according to someone who did some 
digging on Windows, it seems to be this way, e.g. on Hamoa Windows 
enters system SS1 / "LPI" (0x02000154) at runtime all the time, but 
reserves system SS3 / "DRIPS" (0x0200c354) for system suspend:

"A Windows WPR trace (Kernel-Processor-Power |PlatformIdleVeto|) showed 
that Windows never enters DRIPS while the screen is on. The PEP vetoes 
it (reasons 4/5/8) and only allows platform.SS1. DRIPS is used only in 
Modern Standby."

~val