arch/arm64/boot/dts/qcom/hamoa.dtsi | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
At present, designs based on the Qualcomm X1 Hamoa reference platform have an always-on system power domain since the OF node values aren't implement.
Fix this by using the CPU C4, cluster CL5 and system DRIPS parameters from the ACPI DSDT Windows uses, together with the Low Power Idle _LPI minimum residency of 9000us and wake latency of 5000us as exit latency. Finally, assume the entry latency is the difference of these two values.
Tested on a Lenovo Yoga Slim 7x with Qualcomm X1E-80-100.
Fixes: f33767e3cfa5 ("arm64: dts: qcom: x1e80100: Add missing system-wide PSCI power domain")
Signed-off-by: Daniel J Blueman <daniel@quora.org>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index a17900eacb20..64338769bc85 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -290,6 +290,14 @@ cluster_cl5: cluster-sleep-1 {
exit-latency-us = <4000>;
min-residency-us = <7000>;
};
+
+ domain_ss3: domain-sleep-0 {
+ compatible = "domain-idle-state";
+ arm,psci-suspend-param = <0x0200c354>;
+ entry-latency-us = <4000>;
+ exit-latency-us = <5000>;
+ min-residency-us = <9000>;
+ };
};
};
@@ -448,7 +456,7 @@ cluster_pd2: power-domain-cpu-cluster2 {
system_pd: power-domain-system {
#power-domain-cells = <0>;
- /* TODO: system-wide idle states */
+ domain-idle-states = <&domain_ss3>;
};
};
--
2.51.0On Sat, Feb 21, 2026 at 06:51:56PM +0800, Daniel J Blueman wrote:
> At present, designs based on the Qualcomm X1 Hamoa reference platform have an always-on system power domain since the OF node values aren't implement.
>
> Fix this by using the CPU C4, cluster CL5 and system DRIPS parameters from the ACPI DSDT Windows uses, together with the Low Power Idle _LPI minimum residency of 9000us and wake latency of 5000us as exit latency. Finally, assume the entry latency is the difference of these two values.
Please wrap your lines to 72 characters.
Regards,
Bjorn
>
> Tested on a Lenovo Yoga Slim 7x with Qualcomm X1E-80-100.
>
> Fixes: f33767e3cfa5 ("arm64: dts: qcom: x1e80100: Add missing system-wide PSCI power domain")
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> ---
> arch/arm64/boot/dts/qcom/hamoa.dtsi | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index a17900eacb20..64338769bc85 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -290,6 +290,14 @@ cluster_cl5: cluster-sleep-1 {
> exit-latency-us = <4000>;
> min-residency-us = <7000>;
> };
> +
> + domain_ss3: domain-sleep-0 {
> + compatible = "domain-idle-state";
> + arm,psci-suspend-param = <0x0200c354>;
> + entry-latency-us = <4000>;
> + exit-latency-us = <5000>;
> + min-residency-us = <9000>;
> + };
> };
> };
>
> @@ -448,7 +456,7 @@ cluster_pd2: power-domain-cpu-cluster2 {
>
> system_pd: power-domain-system {
> #power-domain-cells = <0>;
> - /* TODO: system-wide idle states */
> + domain-idle-states = <&domain_ss3>;
> };
> };
>
> --
> 2.51.0
>
On 2/21/2026 4:21 PM, Daniel J Blueman wrote:
> At present, designs based on the Qualcomm X1 Hamoa reference platform have an always-on system power domain since the OF node values aren't implement.
Implemented.
>
> Fix this by using the CPU C4, cluster CL5 and system DRIPS parameters from the ACPI DSDT Windows uses, together with the Low Power Idle _LPI minimum residency of 9000us and wake latency of 5000us as exit latency. Finally, assume the entry latency is the difference of these two values.
ACPI used 5000usec as total exit latency, with this change total exit latency will be 9000usec (sum of entry + exit).
>
> Tested on a Lenovo Yoga Slim 7x with Qualcomm X1E-80-100.
>
> Fixes: f33767e3cfa5 ("arm64: dts: qcom: x1e80100: Add missing system-wide PSCI power domain")
Using this fixes tag, can make the change back ported to stable kernels without dependencies and may break the GPIO IRQs.
Background:
PDC monitors the wakeup capable IRQs during system wide low power state, hitting the system low power mode can break to wake via GPIO IRQs.
The system-wide idle state was not added since the wakeup capable GPIO IRQs were not configured at PDC with 602cb14e310a
("pinctrl: qcom: x1e80100: Bypass PDC wakeup parent for now").
So IMO this fixes tag should be used instead of above with the changes to configure PDC to monitor GPIO wake ups.
I have these changes to configure GPIO IRQs at PDC and enable back domain_ss3 idle state in my local tree, which i plan to
post this week or next.
Thanks,
Maulik
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> ---
> arch/arm64/boot/dts/qcom/hamoa.dtsi | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index a17900eacb20..64338769bc85 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -290,6 +290,14 @@ cluster_cl5: cluster-sleep-1 {
> exit-latency-us = <4000>;
> min-residency-us = <7000>;
> };
> +
> + domain_ss3: domain-sleep-0 {
> + compatible = "domain-idle-state";
> + arm,psci-suspend-param = <0x0200c354>;
> + entry-latency-us = <4000>;
> + exit-latency-us = <5000>;
> + min-residency-us = <9000>;
> + };
> };
> };
>
> @@ -448,7 +456,7 @@ cluster_pd2: power-domain-cpu-cluster2 {
>
> system_pd: power-domain-system {
> #power-domain-cells = <0>;
> - /* TODO: system-wide idle states */
> + domain-idle-states = <&domain_ss3>;
> };
> };
>
On Mon, Feb 23, 2026 at 09:41:04AM +0530, Maulik Shah (mkshah) wrote:
>
> On 2/21/2026 4:21 PM, Daniel J Blueman wrote:
> > At present, designs based on the Qualcomm X1 Hamoa reference platform have an always-on system power domain since the OF node values aren't implement.
>
> Implemented.
>
> >
> > Fix this by using the CPU C4, cluster CL5 and system DRIPS parameters from the ACPI DSDT Windows uses, together with the Low Power Idle _LPI minimum residency of 9000us and wake latency of 5000us as exit latency. Finally, assume the entry latency is the difference of these two values.
>
> ACPI used 5000usec as total exit latency, with this change total exit latency will be 9000usec (sum of entry + exit).
>
> >
> > Tested on a Lenovo Yoga Slim 7x with Qualcomm X1E-80-100.
> >
> > Fixes: f33767e3cfa5 ("arm64: dts: qcom: x1e80100: Add missing system-wide PSCI power domain")
>
> Using this fixes tag, can make the change back ported to stable kernels without dependencies and may break the GPIO IRQs.
>
> Background:
>
> PDC monitors the wakeup capable IRQs during system wide low power state, hitting the system low power mode can break to wake via GPIO IRQs.
> The system-wide idle state was not added since the wakeup capable GPIO IRQs were not configured at PDC with 602cb14e310a
> ("pinctrl: qcom: x1e80100: Bypass PDC wakeup parent for now").
>
> So IMO this fixes tag should be used instead of above with the changes to configure PDC to monitor GPIO wake ups.
> I have these changes to configure GPIO IRQs at PDC and enable back domain_ss3 idle state in my local tree, which i plan to
> post this week or next.
>
No, this patch does not fix 602cb14e310a ("pinctrl: qcom: x1e80100:
Bypass PDC wakeup parent for now"), please see
Documentation/process/stable-kernel-rules.rst on how to document
dependencies for fixes.
It could however be argued that this doesn't fix a bug with f33767e3cfa5
("arm64: dts: qcom: x1e80100: Add missing system-wide PSCI power
domain"), but instead just implements the missing domain-idle-state
(i.e. drop the Fixes).
PS. What I do expect is that 602cb14e310a ("pinctrl: qcom: x1e80100:
Bypass PDC wakeup parent for now") should have been reverted once the
PDC driver gained the necessary workarounds!
Regards,
Bjorn
> Thanks,
> Maulik
>
> > Signed-off-by: Daniel J Blueman <daniel@quora.org>
> > ---
> > arch/arm64/boot/dts/qcom/hamoa.dtsi | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > index a17900eacb20..64338769bc85 100644
> > --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > @@ -290,6 +290,14 @@ cluster_cl5: cluster-sleep-1 {
> > exit-latency-us = <4000>;
> > min-residency-us = <7000>;
> > };
> > +
> > + domain_ss3: domain-sleep-0 {
> > + compatible = "domain-idle-state";
> > + arm,psci-suspend-param = <0x0200c354>;
> > + entry-latency-us = <4000>;
> > + exit-latency-us = <5000>;
> > + min-residency-us = <9000>;
> > + };
> > };
> > };
> >
> > @@ -448,7 +456,7 @@ cluster_pd2: power-domain-cpu-cluster2 {
> >
> > system_pd: power-domain-system {
> > #power-domain-cells = <0>;
> > - /* TODO: system-wide idle states */
> > + domain-idle-states = <&domain_ss3>;
> > };
> > };
> >
>
On 2/23/26 1:11 AM, Maulik Shah (mkshah) wrote:
> On 2/21/2026 4:21 PM, Daniel J Blueman wrote:
[..]
>> Fix this by using the CPU C4, cluster CL5 and system DRIPS parameters from the ACPI DSDT Windows uses, together with the Low Power Idle _LPI minimum residency of 9000us and wake latency of 5000us as exit latency. Finally, assume the entry latency is the difference of these two values.
[..]
>> Fixes: f33767e3cfa5 ("arm64: dts: qcom: x1e80100: Add missing system-wide PSCI power domain")
> Using this fixes tag, can make the change back ported to stable kernels without dependencies and may break the GPIO IRQs.
>
> Background:
>
> PDC monitors the wakeup capable IRQs during system wide low power state, hitting the system low power mode can break to wake via GPIO IRQs.
> The system-wide idle state was not added since the wakeup capable GPIO IRQs were not configured at PDC with 602cb14e310a
> ("pinctrl: qcom: x1e80100: Bypass PDC wakeup parent for now").
>
> So IMO this fixes tag should be used instead of above with the changes to configure PDC to monitor GPIO wake ups.
> I have these changes to configure GPIO IRQs at PDC and enable back domain_ss3 idle state in my local tree, which i plan to
> post this week or next.
On a previous episode of L-K-M-L… :)
https://lore.kernel.org/all/0c8735f9-eac0-449c-aa95-b82cec0e6cb2@oss.qualcomm.com/
FWIW I have just tested Konrad's patch from there that adds all three
states (0x02000154, 0x02000254, and 0x0200c354):
❯ doas cat /sys/kernel/debug/pm_genpd/power-domain-system/idle_states
State Time(ms) Usage Rejected Above Below S2idle
S0 367 330 9 315 9 0
S1 2719 2057 553 2520 71 0
S2 0 0 1 1 0 0
As of right now I don't see any improvement in idle power consumption
from just this S1 thing, compared to not adding anything and having the
implicitly-added-by-code S0 state only.
It still only goes as low as 2.5W in screen-off idle, and that's with
runtime PM enabled for 3 USB controllers out of 4 (enabling it on all 4
makes the system shut down), without doing that it's more like 2.75W.
---
Maulik, since you seem to be the oss.qualcomm person familiar with power
management — could you please shine some light onto the mystery of how
Windows achieves ~0.5W battery consumption in screen-off idle (and only
slightly higher in screen-on idle) i.e. what exactly could be wasting
those extra 2W under Linux? Ever since people started daily driving X
series based laptops this has been an eternal topic/question in
aarch64-laptops…
Is it just Windows doing something "extraordinary" like opportunistic
full-system sleep (as deep as CX collapse), even with display on and in PSR?
Or are we still missing something big in Linux?
That issue with runtime-suspending all four USB controllers shutting the
system down, does that mean there's some rail where USB ends up being
the last load-bearing thing holding it up and we'd like to let it go
down properly?
Thanks
~val
On Mon, Feb 23, 2026 at 02:51:44AM -0300, Val Packett wrote: > On 2/23/26 1:11 AM, Maulik Shah (mkshah) wrote: > > On 2/21/2026 4:21 PM, Daniel J Blueman wrote: [..] > That issue with runtime-suspending all four USB controllers shutting the > system down, does that mean there's some rail where USB ends up being the > last load-bearing thing holding it up and we'd like to let it go down > properly? > The three USB nodes have power-domains = <&gcc GCC_USB30_*_GDSC> and required-opps = <&opp_nom>. &gcc has power-domains = < &rpmhpd CX>. This means that as long as the USB controllers are active, CX is kept at at least nominal corner. The reason why the USB node has &opp_nom is because it's required by the 200MHz MASTER_CLK, which iirc relates to the possibility that you might have something SuperSpeed connected. (But as we flatten dwc3, we should be able to scale this based on what is actually connected) I don't know why there's multiple pm_runtime_forbid() in the USB stack, this needs to be revisited. Then to your actual question, yes, if you suspend the USB controllers and the result is that the system dies, then we have other resources piggybacking on the USB controllers' votes for CX. I did some experiments on SC8280XP earlier and was able to drop the pm_runtime_forbid() - and see CX drop below NOM. Iirc more work was needed to get reasonable behavior in terms of plug-detect, so the patches got stuck in their topic branch... Regards, Bjorn > > Thanks > ~val >
© 2016 - 2026 Red Hat, Inc.