Re: [PATCH 1/2] arm64: dts: qcom: sdm630: Drop the cluster idle states
From: Fabricio Akio
Date: Tue Oct 20 2026 - 12:20:51 EST
On 10/15/26 3:51 PM, Konrad Dybcio wrote:
> I threw an LLM at the downstream tree and it decoded the states to:
>
> C2D, no cluster state 2 0x00000002
> C3, no cluster state 3 0x40000003
> pwr/perf L2 D2D + C2D L2 2 0x01000022
> pwr/perf L2 D2D + C3 L2 2 0x41000023
> pwr/perf L2 D2E + C3 L2 3 0x41000033
> pwr/perf L2 D4 + C3 L2 4 0x41000043
> System PC + L2 D4 + C3 sys3, L2 4 0x42000343
>
> sorry for getting it wrong years ago!
Thanks! I had decoded the same values, but I didn't just put them in
place of the old ones. This firmware supports OS-initiated mode and
refuses platform-coordinated mode ("psci: [Firmware Bug]: failed to
set PC mode: -3", PSCI DENIED). In OS-initiated mode a cluster state
may only be requested by the last running CPU of the cluster, which a
flat cpu-idle-states list cannot express. I tried it: with 0x41000043
in the flat list the firmware returns DENIED to nearly every request,
accepting only the few that come from a cluster's last running CPU,
and the idle CPUs spin on it again, at about twice the battery current.
Linux runs OSI only with the CPUs described as PSCI power domains,
with 0x41000043 as each cluster's domain-idle-state and 0x42000343 for
system power collapse above them. I'm working on that, but I'm not
sure yet when it will be ready, so this is not a placeholder for a
replacement coming right behind it.
Dropping the states is not the complete fix, but it helps now, because
as they are they do harm: cpuidle records no successful entry into any
of them, and since the deepest of them is what an idle CPU picks, each
failed request is retried instead of sleeping. On the Moto X4
that is about 133,000 failed entries per second with the screen off,
and the battery current goes from 277 mA to about 115 mA without them.
Is dropping them first OK with you?