Re: [PATCH 2/3] pmdomain: Add support for system-suspend-only states
From: Val Packett
Date: Wed Oct 07 2026 - 14:59:10 EST
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 beInstead of this I am thinking if we can QoS cpu latency setting and block
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.
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