Re: [PATCH] arm64: dts: qcom: hamoa/x1: Fix TODO in system power domain node

[Val Packett]

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@xxxxxxxxxxxxxxxx/

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