[PATCH 0/3] pmdomain: Support system-suspend-only domain idle states

[PATCH 0/3] pmdomain: Support system-suspend-only domain idle states

[Maulik Shah]

To achieve the deepest CPUSS low power state, which can lead to chip
rail power collapse (CxPC) on SoCs such as Lemans, Monaco and Nord, the CPU
subsystem (CPUSS) and the Safety Island (SAIL) subsystem must be powered
down together in a coordinated sequence. The Safety Island (SAIL) is a
dedicated subsystem responsible for safety-critical monitoring and control
functions, and can operate independently from the main CPU subsystem.

This transition is divided into two stages. First, firmware requests SAIL
power-down through IPC, after which SAIL waits for hardware low power
handshakes from CPUSS. If an interrupt or another condition aborts CPUSS
entry into the deepest low power mode after the IPC request, firmware must
bring SAIL back out of its low power sequence before any CPU can resume
execution in the OS. This recovery can take a second or more.

Selecting this state during opportunistic CPU idle can therefore cause
substantial wakeup delays and repeatedly interrupt SAIL operation whenever
the CPUs become idle. SAIL must remain operational during normal system
activity, so this coordinated power-down state should be reserved for
system-wide suspend such as suspend-to-idle. Shallower domain states
remain available for regular CPU and cluster idle power management.

This restriction concerns when SAIL may stop its work, in addition to the
transition latency. Idle-state latency and residency values alone do not
express that requirement. System suspend does not eliminate interrupts or
aborted entry, but provides the context in which coordinated SAIL
power-down is appropriate.

All domain idle states described in devicetree are currently considered
during the regular idle path. This limits which states can be described in
devicetree. Due to hardware constraints, some domain idle states are only
applicable to system-wide suspend, including suspend-to-idle (s2idle).

To allow these states to be described in DT and used only during system
suspend, this series adds a boolean system-state property to domain idle
state bindings and a corresponding system_state boolean in genpd. The
genpd governors skip these states during normal operation. The system
suspend selection path remains unchanged, allowing these states during
suspend while retaining the existing wakeup latency checks for s2idle.

This series applies to cluster idle states with the "domain-idle-state"
compatible string managed by genpd and its governors, but can be extended
to CPU idle states with the "arm,idle-state" compatible string if the same
restriction is needed for CPUidle states too.

Assisted-by: Codex:GPT-6
Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
Maulik Shah (3):
      dt-bindings: power: domain-idle-state: Add system-state
      pmdomain: Add support for system-suspend-only states
      arm64: dts: qcom: monaco-evk: Add suspend-only power collapse state

 .../devicetree/bindings/power/domain-idle-state.yaml    | 14 ++++++++++++++
 arch/arm64/boot/dts/qcom/monaco-evk.dts                 | 17 +++++++++++++++++
 drivers/pmdomain/core.c                                 |  2 ++
 drivers/pmdomain/governor.c                             |  6 ++++++
 include/linux/pm_domain.h                               |  1 +
 5 files changed, 40 insertions(+)
---
base-commit: 6c2cb8b8b843d216ab549b678a0d8831c43153e0
change-id: 20261001-s2idle_state-6484bbbf48fb

Best regards,
--  
Maulik Shah <maulik.shah@oss.qualcomm.com>

[PATCH 1/3] dt-bindings: power: domain-idle-state: Add system-state

[Maulik Shah]

Some domain idle states require system-wide coordination and are not
applicable while the platform is up and running.

Add a boolean system-state property to describe these states.

Assisted-by: Codex:GPT-6
Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
 .../devicetree/bindings/power/domain-idle-state.yaml       | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.yaml b/Documentation/devicetree/bindings/power/domain-idle-state.yaml
index 4dd4f59bbbec..35dab3cd6aed 100644
--- a/Documentation/devicetree/bindings/power/domain-idle-state.yaml
+++ b/Documentation/devicetree/bindings/power/domain-idle-state.yaml
@@ -45,6 +45,12 @@ patternProperties:
           state will yield power benefits, after overcoming the overhead while
           entering the idle state.
 
+      system-state:
+        description:
+          When present, this state requires system-wide coordination and is
+          not applicable while the platform is up and running.
+        type: boolean
+
       arm,psci-suspend-param:
         $ref: /schemas/types.yaml#/definitions/uint32
         description: |
@@ -77,5 +83,13 @@ examples:
         exit-latency-us = <40>;
         min-residency-us = <80>;
       };
+
+      domain_power_off: domain-power-off {
+        compatible = "domain-idle-state";
+        entry-latency-us = <100>;
+        exit-latency-us = <200>;
+        min-residency-us = <1000>;
+        system-state;
+      };
     };
 ...

-- 
2.43.0

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

[Maulik Shah]

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.

Assisted-by: Codex:GPT-6
Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
 drivers/pmdomain/core.c     | 2 ++
 drivers/pmdomain/governor.c | 6 ++++++
 include/linux/pm_domain.h   | 1 +
 3 files changed, 9 insertions(+)

diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 964e44c2f78f..288c0deb2340 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -3701,6 +3701,8 @@ static int genpd_parse_state(struct genpd_power_state *genpd_state,
 	if (!err)
 		genpd_state->residency_ns = 1000LL * residency;
 
+	genpd_state->system_state = of_property_read_bool(state_node, "system-state");
+
 	err = of_property_read_string(state_node, "idle-state-name",
 				      &genpd_state->name);
 	if (err)
diff --git a/drivers/pmdomain/governor.c b/drivers/pmdomain/governor.c
index 38bba24ec26e..7684f9eecf85 100644
--- a/drivers/pmdomain/governor.c
+++ b/drivers/pmdomain/governor.c
@@ -185,6 +185,9 @@ static bool __default_power_down_ok(struct dev_pm_domain *pd,
 	s64 min_off_time_ns;
 	s64 off_on_time_ns;
 
+	if (genpd->states[state].system_state)
+		return false;
+
 	off_on_time_ns = genpd->states[state].power_off_latency_ns +
 		genpd->states[state].power_on_latency_ns;
 
@@ -407,6 +410,9 @@ static bool cpu_power_down_ok(struct dev_pm_domain *pd)
 	 */
 	i = genpd->state_idx;
 	do {
+		if (genpd->states[i].system_state)
+			continue;
+
 		if ((idle_duration_ns >= (genpd->states[i].residency_ns +
 		    genpd->states[i].power_off_latency_ns)) &&
 		    (global_constraint >= (genpd->states[i].power_on_latency_ns +
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 14e0e346c610..d9b3e67042e5 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -188,6 +188,7 @@ struct genpd_power_state {
 	s64 power_off_latency_ns;
 	s64 power_on_latency_ns;
 	s64 residency_ns;
+	bool system_state;
 	u64 usage;
 	u64 rejected;
 	u64 above;

-- 
2.43.0

[PATCH 3/3] arm64: dts: qcom: monaco-evk: Add suspend-only power collapse state

[Maulik Shah]

To achieve SoC low power mode like chip rail power collapse (CxPC),
the Monaco EVK board with four PMICs requires coordinated power-down of
CPUSS and the Safety Island (SAIL) subsystem. This deepest system power
collapse state is reserved for system-wide suspend (s2idle).

Add the system_suspend domain idle state, mark it with system-state,
and reference it from the system power domain.

Assisted-by: Codex:GPT-6
Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/monaco-evk.dts | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
index 539c9c80a808..b2978be6823d 100644
--- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
+++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts
@@ -80,6 +80,19 @@ m2_e_uart_ep: endpoint@0 {
 		};
 	};
 
+	cpus {
+		domain-idle-states {
+			system_suspend: domain-suspend {
+				compatible = "domain-idle-state";
+				arm,psci-suspend-param = <0x4200C344>;
+				entry-latency-us = <706562>;
+				exit-latency-us = <706562>;
+				min-residency-us = <709987>;
+				system-state;
+			};
+		};
+	};
+
 	dmic: audio-codec-0 {
 		compatible = "dmic-codec";
 		#sound-dai-cells = <0>;
@@ -772,6 +785,10 @@ tpm@0 {
 	};
 };
 
+&system_pd {
+	domain-idle-states = <&system_sleep>, <&system_suspend>;
+};
+
 &tlmm {
 	pcie0_default_state: pcie0-default-state {
 		wake-pins {

-- 
2.43.0

Re: [PATCH 1/3] dt-bindings: power: domain-idle-state: Add system-state

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] dt-bindings: backwards compatibility broken by reusing domain-idle-state
--

commit 7783b35f06985a4e4112599684740ef1b9b25325
Author: Maulik Shah <maulik.shah@oss.qualcomm.com>

dt-bindings: power: domain-idle-state: Add system-state

Some domain idle states require system-wide coordination and are not
applicable while the platform is up and running. Add a boolean system-state
property to describe these states.

> diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.yaml b/Documentation/devicetree/bindings/power/domain-idle-state.yaml
> index 4dd4f59bbbec3..35dab3cd6aedc 100644
> --- a/Documentation/devicetree/bindings/power/domain-idle-state.yaml
> +++ b/Documentation/devicetree/bindings/power/domain-idle-state.yaml
> @@ -45,6 +45,12 @@ patternProperties:
>            state will yield power benefits, after overcoming the overhead while
>            entering the idle state.
>  
> +      system-state:
> +        description:
> +          When present, this state requires system-wide coordination and is
> +          not applicable while the platform is up and running.
> +        type: boolean
> +

[Severity: Critical]
Does adding this property to nodes that still use the "domain-idle-state"
compatible string break backwards compatibility?

When an older kernel parses a Device Tree containing a system-only power
state, it traverses the domain-idle-states phandles and matches the
compatible = "domain-idle-state" string. Because older kernels do not
recognize the newly introduced system-state boolean property, they will
silently ignore it and incorrectly register the system-only state as a
regular runtime cpuidle state.

If the runtime governor selects this system-suspend state during normal
operation, the lack of system-wide coordination can cause the hardware to
hang or crash. Device Tree bindings form an ABI between firmware/bootloader
and the OS, meaning newer Device Trees must safely degrade on older kernels.

Could a new compatible string (e.g., compatible = "domain-system-state") or
a distinct linking property (e.g., domain-system-states) be introduced
instead, so older kernels naturally skip parsing it?

[ ... ]

> @@ -77,5 +83,13 @@ examples:
>          exit-latency-us = <40>;
>          min-residency-us = <80>;
>        };
> +
> +      domain_power_off: domain-power-off {
> +        compatible = "domain-idle-state";
> +        entry-latency-us = <100>;
> +        exit-latency-us = <200>;
> +        min-residency-us = <1000>;
> +        system-state;
> +      };
>      };
>  ...

[Severity: Critical]
Does this example demonstrate the compatibility issue? A state explicitly
restricted to system-wide coordination still uses the "domain-idle-state"
compatible string, which would render it structurally unsafe for older OS
releases to process.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005-s2idle_state-v1-0-3c402c66f388@oss.qualcomm.com?part=1

Re: [PATCH 3/3] arm64: dts: qcom: monaco-evk: Add suspend-only power collapse state

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dts: qcom: invalid AI hallucinated latencies in system_suspend
--

commit 31318bb17563026be6b93cecd9358caf654ab7fb
Author: Maulik Shah <maulik.shah@oss.qualcomm.com>

arm64: dts: qcom: monaco-evk: Add suspend-only power collapse state

This patch adds a deepest system power collapse state reserved for system-wide
suspend (s2idle) on the Monaco EVK board, requiring coordinated power-down of
CPUSS and the Safety Island (SAIL) subsystem.

> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
> index 539c9c80a808d..b2978be6823dc 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts

[ ... ]

> @@ -80,6 +80,19 @@ m2_e_uart_ep: endpoint@0 {
>  		};
>  	};
>  
> +	cpus {
> +		domain-idle-states {
> +			system_suspend: domain-suspend {
> +				compatible = "domain-idle-state";
> +				arm,psci-suspend-param = <0x4200C344>;
> +				entry-latency-us = <706562>;
> +				exit-latency-us = <706562>;
> +				min-residency-us = <709987>;

[Severity: Medium]
Are these latency values physically accurate for the hardware?

The min-residency-us value of 709,987 us is strictly less than the combined
entry and exit latencies of 1,413,124 us (706,562 + 706,562). This appears
invalid, as a state cannot typically yield power benefits before the hardware
has finished transitioning into and out of it. 

Additionally, 706 milliseconds seems unusually high for a transition time on
an EVK board. Since the commit message mentions this was AI-assisted, could 
these numbers be hallucinated placeholders that need to be replaced with 
actual measured hardware values?

> +				system-state;
> +			};
> +		};
> +	};
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005-s2idle_state-v1-0-3c402c66f388@oss.qualcomm.com?part=3

Re: [PATCH 1/3] dt-bindings: power: domain-idle-state: Add system-state

[Sudeep Holla]

On Mon, Oct 05, 2026 at 08:59:42PM +0530, Maulik Shah wrote:
> Some domain idle states require system-wide coordination and are not
> applicable while the platform is up and running.
> 
> Add a boolean system-state property to describe these states.
> 
> Assisted-by: Codex:GPT-6
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/power/domain-idle-state.yaml       | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.yaml b/Documentation/devicetree/bindings/power/domain-idle-state.yaml
> index 4dd4f59bbbec..35dab3cd6aed 100644
> --- a/Documentation/devicetree/bindings/power/domain-idle-state.yaml
> +++ b/Documentation/devicetree/bindings/power/domain-idle-state.yaml
> @@ -45,6 +45,12 @@ patternProperties:
>            state will yield power benefits, after overcoming the overhead while
>            entering the idle state.
>  
> +      system-state:
> +        description:
> +          When present, this state requires system-wide coordination and is
> +          not applicable while the platform is up and running.
> +        type: boolean
> +

I would rather have a system wide QoS latency setting either h/w specific
or it can be purely software policy that tells all these states to be off
for normal CPU idle path.

>        arm,psci-suspend-param:
>          $ref: /schemas/types.yaml#/definitions/uint32
>          description: |
> @@ -77,5 +83,13 @@ examples:
>          exit-latency-us = <40>;
>          min-residency-us = <80>;
>        };
> +
> +      domain_power_off: domain-power-off {
> +        compatible = "domain-idle-state";
> +        entry-latency-us = <100>;
> +        exit-latency-us = <200>;
> +        min-residency-us = <1000>;

Please provide some realistic values. I understand this is just example
but way-off for a system level state. See your own platform values for
reference.

-- 
Regards,
Sudeep

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

[Sudeep Holla]

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.

-- 
Regards,
Sudeep

Re: [PATCH 0/3] pmdomain: Support system-suspend-only domain idle states

[Kevin Hilman]

Maulik Shah <maulik.shah@oss.qualcomm.com> writes:

[...]

> All domain idle states described in devicetree are currently considered
> during the regular idle path. This limits which states can be described in
> devicetree. Due to hardware constraints, some domain idle states are only
> applicable to system-wide suspend, including suspend-to-idle (s2idle).
>
> To allow these states to be described in DT and used only during system
> suspend, this series adds a boolean system-state property to domain idle
> state bindings and a corresponding system_state boolean in genpd. The
> genpd governors skip these states during normal operation. The system
> suspend selection path remains unchanged, allowing these states during
> suspend while retaining the existing wakeup latency checks for s2idle.
>
> This series applies to cluster idle states with the "domain-idle-state"
> compatible string managed by genpd and its governors, but can be extended
> to CPU idle states with the "arm,idle-state" compatible string if the same
> restriction is needed for CPUidle states too.
>
> Assisted-by: Codex:GPT-6
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>

Acked-by: Kevin Hilman <khilman@baylibre.com>

Thank you for submitting this.  I have been considering how to add
exactly this feature, so I add an enthusaistic +1 to the need for
this feature.

On TI SoCs where we use s2idle, we have similar reasons to have
domain-idle-states that should only be available during system-wide
suspend-to-idle.

The current hack to supporting this is to just use absurdly high
residency numbers for these system states such that the runtime CPUidle
never picks the states.  But this is a hack, and is not describing the
hardware, so I would much rather see a way to describe this in DT.

Thanks,

Kevin

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

[Val Packett]

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

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

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

[Ulf Hansson]

On Tue, Oct 6, 2026 at 11:15 AM Sudeep Holla <sudeep.holla@kernel.org> 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.

Even if we likely could make that work, it's seems not correct to rely
on userspace to make the kernel to pick the correct idle state, while
the decision should be based on the characteristics of the HW.

In regards to PSCI PC mode, I believe we should consider adding the
similar DT property for the arm,idle-state binding and make a
corresponding change for the regular CPUIdle path/governors. Although,
it doesn't necessarily need to be part of the $subject series. I would
 be fine if that is handled later on too.

Kind regards
Uffe