[PATCH] Revert "clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"

[PATCH] Revert "clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"

[Christopher Obbard]

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.baryshkov@linaro.org/
Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org>
---
Hi all,

This series contains a single revert for a regression affecting the
APQ8096/MSM8996 (DragonBoard 820c).

The commit being reverted, b3b274bc9d3d ("clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"),
introduces a significant performance issue where the CPUs downclock to
~50% of their expected frequency under sustained load. The problem is
reproducible both at boot and when running CPU-bound workloads such as
stress-ng.

Bisecting the issue pointed directly to this commit and reverting it
restores correct cpufreq behaviour.

The root cause appears to be related to the interaction between the
simplified notifier callback and ACD (Adaptive Clock Distribution).
Since we would prefer to keep ACD enabled for SoC reliability reasons,
a revert is the safest option until a proper fix is identified.

Full details are included in the commit message.

Feedback & suggestions welcome.

Cheers!

Christopher Obbard
---
 drivers/clk/qcom/clk-cpu-8996.c | 30 +++++++++++-------------------
 1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/drivers/clk/qcom/clk-cpu-8996.c b/drivers/clk/qcom/clk-cpu-8996.c
index 21d13c0841ed..028476931747 100644
--- a/drivers/clk/qcom/clk-cpu-8996.c
+++ b/drivers/clk/qcom/clk-cpu-8996.c
@@ -547,35 +547,27 @@ static int cpu_clk_notifier_cb(struct notifier_block *nb, unsigned long event,
 {
 	struct clk_cpu_8996_pmux *cpuclk = to_clk_cpu_8996_pmux_nb(nb);
 	struct clk_notifier_data *cnd = data;
+	int ret;
 
 	switch (event) {
 	case PRE_RATE_CHANGE:
+		ret = clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, ALT_INDEX);
 		qcom_cpu_clk_msm8996_acd_init(cpuclk->clkr.regmap);
-
-		/*
-		 * Avoid overvolting. clk_core_set_rate_nolock() walks from top
-		 * to bottom, so it will change the rate of the PLL before
-		 * chaging the parent of PMUX. This can result in pmux getting
-		 * clocked twice the expected rate.
-		 *
-		 * Manually switch to PLL/2 here.
-		 */
-		if (cnd->new_rate < DIV_2_THRESHOLD &&
-		    cnd->old_rate > DIV_2_THRESHOLD)
-			clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, SMUX_INDEX);
-
 		break;
-	case ABORT_RATE_CHANGE:
-		/* Revert manual change */
-		if (cnd->new_rate < DIV_2_THRESHOLD &&
-		    cnd->old_rate > DIV_2_THRESHOLD)
-			clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, ACD_INDEX);
+	case POST_RATE_CHANGE:
+		if (cnd->new_rate < DIV_2_THRESHOLD)
+			ret = clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw,
+							   SMUX_INDEX);
+		else
+			ret = clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw,
+							   ACD_INDEX);
 		break;
 	default:
+		ret = 0;
 		break;
 	}
 
-	return NOTIFY_OK;
+	return notifier_from_errno(ret);
 };
 
 static int qcom_cpu_clk_msm8996_driver_probe(struct platform_device *pdev)

---
base-commit: c17e270dfb342a782d69c4a7c4c32980455afd9c
change-id: 20251202-wip-obbardc-qcom-msm8096-clk-cpu-fix-downclock-b7561da4cb95

Best regards,
-- 
Christopher Obbard <christopher.obbard@linaro.org>

Re: [PATCH] Revert "clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"

[Konrad Dybcio]

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.baryshkov@linaro.org/
> 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@oss.qualcomm.com/

https://lore.kernel.org/linux-arm-msm/kXrAkKv7RZct22X0wivLWqOAiLKpFuDCAY1KY_KSx649kn7BNmJ2IFFMrsYPAyDlcxIjbQCQ1PHb5KaNFawm9IGIXUbch-DI9OI_l73BAaM=@protonmail.com/

Konrad

Re: [PATCH] Revert "clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"

[Christopher Obbard]

Hi Konrad,

On Wed, 3 Dec 2025 at 10:52, Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> 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.baryshkov@linaro.org/
> > Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org>
> > ---


Apologies for the late response, I was in the process of setting some
more msm8096 boards up again in my new workspace to test this
properly.


> 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`

I read the soc_id from both of the msm8096 boards I have:

Open-Q™ 820 µSOM Development Kit (APQ8096)
```
$ cat /sys/bus/soc/devices/soc0/soc_id
291
```
(FWIW this board is not in mainline yet; but boots with a DT similar
enough to the db820c. I have a patch in my upstream backlog enabling
that board; watch this space)

DragonBoard™ 820c (APQ8096)
```
$ cat /sys/bus/soc/devices/soc0/soc_id
291
```


> see:
>
> https://lore.kernel.org/linux-arm-msm/20251111-db820c-pro-v1-0-6eece16c5c23@oss.qualcomm.com/
>
> https://lore.kernel.org/linux-arm-msm/kXrAkKv7RZct22X0wivLWqOAiLKpFuDCAY1KY_KSx649kn7BNmJ2IFFMrsYPAyDlcxIjbQCQ1PHb5KaNFawm9IGIXUbch-DI9OI_l73BAaM=@protonmail.com/

Thanks for the pointers. Interesting, but it does look like my boards
are msm8096 (and not the pro SKU). Can you confirm that at all from
the soc_id above?

Another bit of (hopefully useful) information is that the db820c boot
firmware log sthe following, which is different to the logs I saw from
the pro SKU (BUT the firmware could also be outdated?):
```
S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.0-00301
S - IMAGE_VARIANT_STRING=M8996LAB
S - OEM_IMAGE_VERSION_STRING=crm-ubuntu68
S - Boot Interface: UFS
S - Secure Boot: Off
S - Boot Config @ 0x00076044 = 0x000001c9
S - JTAG ID @ 0x000760f4 = 0x4003e0e1
S - OEM ID @ 0x000760f8 = 0x00000000
S - Serial Number @ 0x00074138 = 0x14d6d024
S - OEM Config Row 0 @ 0x00074188 = 0x0000000000000000
S - OEM Config Row 1 @ 0x00074190 = 0x0000000000000000
S - Feature Config Row 0 @ 0x000741a0 = 0x0050000010000100
S - Feature Config Row 1 @ 0x000741a8 = 0x00fff00001ffffff
S - Core 0 Frequency, 1228 MHz
B -         0 - PBL, Start
B -     10414 - bootable_media_detect_entry, Start
B -     50197 - bootable_media_detect_success, Start
B -     50197 - elf_loader_entry, Start
B -     51760 - auth_hash_seg_entry, Start
B -     51863 - auth_hash_seg_exit, Start
B -     85147 - elf_segs_hash_verify_entry, Start
B -     87651 - PBL, End
B -     89700 - SBL1, Start
B -    185684 - usb: hs_phy_nondrive_start
B -    186050 - usb: PLL lock success - 0x3
B -    189039 - usb: hs_phy_nondrive_finish
B -    193156 - boot_flash_init, Start
D -        30 - boot_flash_init, Delta
B -    200263 - sbl1_ddr_set_default_params, Start
D -        30 - sbl1_ddr_set_default_params, Delta
B -    208254 - boot_config_data_table_init, Start
D -    317169 - boot_config_data_table_init, Delta - (60 Bytes)
B -    529968 - CDT Version:3,Platform ID:24,Major ID:1,Minor ID:0,Subtype:0
B -    534665 - Image Load, Start
D -     22448 - PMIC Image Loaded, Delta - (37272 Bytes)
B -    557143 - pm_device_init, Start
B -    562908 - PON REASON:PM0:0x60 PM1:0x20
B -    599294 - PM_SET_VAL:Skip
D -     40016 - pm_device_init, Delta
B -    601216 - pm_driver_init, Start
D -      2897 - pm_driver_init, Delta
B -    607834 - pm_sbl_chg_init, Start
D -        91 - pm_sbl_chg_init, Delta
B -    614575 - vsense_init, Start
D -         0 - vsense_init, Delta
B -    624670 - Pre_DDR_clock_init, Start
D -       396 - Pre_DDR_clock_init, Delta
B -    628208 - ddr_initialize_device, Start
B -    631899 - 8996 v3.x detected, Max frequency = 1.8 GHz
B -    641537 - ddr_initialize_device, Delta
B -    641567 - DDR ID, Rank 0, Rank 1, 0x6, 0x300, 0x300
B -    645410 - Basic DDR tests done
B -    714157 - clock_init, Start
D -       274 - clock_init, Delta
B -    717543 - Image Load, Start
D -      4331 - QSEE Dev Config Image Loaded, Delta - (46008 Bytes)
B -    723002 - Image Load, Start
D -      5307 - APDP Image Loaded, Delta - (0 Bytes)
B -    731603 - usb: UFS Serial - a28415ce
B -    735965 - usb: fedl, vbus_low
B -    739594 - Image Load, Start
D -     55449 - QSEE Image Loaded, Delta - (1640572 Bytes)
B -    795043 - Image Load, Start
D -      2043 - SEC Image Loaded, Delta - (4096 Bytes)
B -    802607 - sbl1_efs_handle_cookies, Start
D -       488 - sbl1_efs_handle_cookies, Delta
B -    811117 - Image Load, Start
D -     14365 - QHEE Image Loaded, Delta - (254184 Bytes)
B -    825482 - Image Load, Start
D -     14091 - RPM Image Loaded, Delta - (223900 Bytes)
B -    840397 - Image Load, Start
D -      3172 - STI Image Loaded, Delta - (0 Bytes)
B -    847107 - Image Load, Start
D -     34800 - APPSBL Image Loaded, Delta - (748620 Bytes)
B -    881999 - SBL1, End
D -    796569 - SBL1, Delta
S - Flash Throughput, 94000 KB/s  (2958928 Bytes,  31192 us)
S - DDR Frequency, 1017 MHz
Android Bootloader - UART_DM Initialized!!!
[0] BUILD_VERSION=
[0] BUILD_DATE=00:29:31 - Dec  4 2023
[0] welcome to lk
...
```


Cheers!

Chris

Re: [PATCH] Revert "clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"

[Christopher Obbard]

Hi Konrad,

On Mon, 8 Dec 2025 at 22:36, Christopher Obbard
<christopher.obbard@linaro.org> wrote:
> Apologies for the late response, I was in the process of setting some
> more msm8096 boards up again in my new workspace to test this
> properly.
>
>
> > 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`
>
> I read the soc_id from both of the msm8096 boards I have:
>
> Open-Q™ 820 µSOM Development Kit (APQ8096)
> ```
> $ cat /sys/bus/soc/devices/soc0/soc_id
> 291
> ```
> (FWIW this board is not in mainline yet; but boots with a DT similar
> enough to the db820c. I have a patch in my upstream backlog enabling
> that board; watch this space)
>
> DragonBoard™ 820c (APQ8096)
> ```
> $ cat /sys/bus/soc/devices/soc0/soc_id
> 291
> ```

Sorry to nag, but are you able to look into this soc_id and see if
it's the PRO SKU ?


Cheers!

Chris

Re: [PATCH] Revert "clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"

[Konrad Dybcio]

On 12/14/25 8:26 PM, Christopher Obbard wrote:
> Hi Konrad,
> 
> On Mon, 8 Dec 2025 at 22:36, Christopher Obbard
> <christopher.obbard@linaro.org> wrote:
>> Apologies for the late response, I was in the process of setting some
>> more msm8096 boards up again in my new workspace to test this
>> properly.
>>
>>
>>> 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`
>>
>> I read the soc_id from both of the msm8096 boards I have:
>>
>> Open-Q™ 820 µSOM Development Kit (APQ8096)
>> ```
>> $ cat /sys/bus/soc/devices/soc0/soc_id
>> 291
>> ```
>> (FWIW this board is not in mainline yet; but boots with a DT similar
>> enough to the db820c. I have a patch in my upstream backlog enabling
>> that board; watch this space)
>>
>> DragonBoard™ 820c (APQ8096)
>> ```
>> $ cat /sys/bus/soc/devices/soc0/soc_id
>> 291
>> ```
> 
> Sorry to nag, but are you able to look into this soc_id and see if
> it's the PRO SKU ?

No, it's the "normal" one

Maybe Dmitry would know a little more what's going on

Konrad

Re: [PATCH] Revert "clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"

[Dmitry Baryshkov]

On Wed, Dec 17, 2025 at 01:22:59PM +0100, Konrad Dybcio wrote:
> On 12/14/25 8:26 PM, Christopher Obbard wrote:
> > Hi Konrad,
> > 
> > On Mon, 8 Dec 2025 at 22:36, Christopher Obbard
> > <christopher.obbard@linaro.org> wrote:
> >> Apologies for the late response, I was in the process of setting some
> >> more msm8096 boards up again in my new workspace to test this
> >> properly.
> >>
> >>
> >>> 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`
> >>
> >> I read the soc_id from both of the msm8096 boards I have:
> >>
> >> Open-Q™ 820 µSOM Development Kit (APQ8096)
> >> ```
> >> $ cat /sys/bus/soc/devices/soc0/soc_id
> >> 291
> >> ```
> >> (FWIW this board is not in mainline yet; but boots with a DT similar
> >> enough to the db820c. I have a patch in my upstream backlog enabling
> >> that board; watch this space)
> >>
> >> DragonBoard™ 820c (APQ8096)
> >> ```
> >> $ cat /sys/bus/soc/devices/soc0/soc_id
> >> 291
> >> ```
> > 
> > Sorry to nag, but are you able to look into this soc_id and see if
> > it's the PRO SKU ?
> 
> No, it's the "normal" one
> 
> Maybe Dmitry would know a little more what's going on

Unfortunately, no.

Maybe, the best option would be to really land the revert.


Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>



-- 
With best wishes
Dmitry