Re: [PATCH v3 8/8] arm64: dts: qcom: x1e80100: Add deepest idle state
From: Maulik Shah (mkshah)
Date: Tue Jul 07 2026 - 02:57:27 EST
On 6/18/2026 1:55 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
>> Add deepest idle state as GPIO IRQs can work as wakeup capable interrupts
>> in deepest idle state.
>>
>> Signed-off-by: Maulik Shah <maulik.shah@xxxxxxxxxxxxxxxx>
>> ---
>> 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 4ba751a65142..47e425003028 100644
>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> @@ -302,6 +302,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 = <2800>;
>> + exit-latency-us = <4400>;
>
> The DSDT has "wake_latency" (presumably the same as exit latency) set
> to 5000 us, should we follow?
DSDT wake_latency seems to be entry+exit latency. Will follow DSDT in v4.
This requires update in CL5 latency too, for now will follow 2500+2500 split,
which is closing matching with actual entry/exit latency too.
>
> FWIW, the 2800/4400 numbers here are the exact same as for sm8650..
> which doesn't sound very reassuring>
>
>> + min-residency-us = <9000>;
>
> This number matches the DSDT
> > Should the entry latency then be 9000 - 5000 = 4000?
CPU idle states with arm,idle-states compatible allows "wakeup-latency-us", which should match DSDT given "wake_latency".
Using this will avoid such confusion in future and will plan to use this but in a separate series.
This needs some more changes for Cluster idle states with domain-idle-state compatible.
(cluster states do not support the "wakeup-latency-us" and still needs entry/exit-latency-us)
Sneh is already working on this and will soon send out a series.
Thanks,
Maulik
>
>
> On a separate note, the DSDT also defines:
>
> SS1 (0x02000154, total=7500, exit=500)
> SS2 (0x02000254, total=8000, exit=3000)
>
> These are obviously shallower states, but perhaps they could still
> be useful?
>
So far SS1/SS2 not proven to be helping much on power/performance for Linux.
Thanks,
Maulik