Re: [PATCH v3 8/8] arm64: dts: qcom: x1e80100: Add deepest idle state

["Maulik Shah (mkshah)" <maulik.shah@oss.qualcomm.com>]

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@oss.qualcomm.com>
>> ---
>>  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