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

[Sudeep Holla]

On Wed, Oct 07, 2026 at 03:55:22PM -0300, Val Packett wrote:
> 
> 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."
> 

I wonder how it is done in ACPI then as no changes were introduced for this
in _LPI tables. More reasons not to add any info to H/W table unless I am
missing something and _LPI was indeed updated or modified.

-- 
Regards,
Sudeep