On 12/2/25 10:24 PM, Christopher Obbard wrote:
This reverts commit b3b274bc9d3d7307308aeaf75f70731765ac999a.
On the DragonBoard 820c (which uses APQ8096/MSM8996) this change causes the CPUs to downclock to roughly half speed under sustained load. The regression is visible both during boot and when running CPU stress workloads such as stress-ng: the CPUs initially ramp up to the expected frequency, then drop to a lower OPP even though the system is clearly CPU-bound.
Bisecting points to this commit and reverting it restores the expected behaviour on the DragonBoard 820c - the CPUs track the cpufreq policy and run at full performance under load.
The exact interaction with the ACD is not yet fully understood and we would like to keep ACD in use to avoid possible SoC reliability issues. Until we have a better fix that preserves ACD while avoiding this performance regression, revert the bisected patch to restore the previous behaviour.
Fixes: b3b274bc9d3d ("clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb") Cc: stable@vger.kernel.org # v6.3+ Link: https://lore.kernel.org/linux-arm-msm/20230113120544.59320-8-dmitry.baryshko... Cc: Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com Signed-off-by: Christopher Obbard christopher.obbard@linaro.org
It may be that your board really has a MSM/APQ8x96*SG* which is another name for the PRO SKU, which happens to have a 2 times wider divider, try
`cat /sys/bus/soc/devices/soc0/soc_id`
see:
https://lore.kernel.org/linux-arm-msm/20251111-db820c-pro-v1-0-6eece16c5c23@...
https://lore.kernel.org/linux-arm-msm/kXrAkKv7RZct22X0wivLWqOAiLKpFuDCAY1KY_...
Konrad