[PATCH v3] clk: spacemit: k3: add 1.8 GHz PLL5 and PLL8 rates

[PATCH v3] clk: spacemit: k3: add 1.8 GHz PLL5 and PLL8 rates

[Troy Mitchell]

K3 boot firmware configures the C2 and C3 CPU clock domains at
1.8 GHz. PLL5 feeds C2 and PLL8 feeds C3, but their rate tables
currently contain only the 2 GHz overclocking operating point.

Add the nominal 1.8 GHz configuration as the first entry in both
tables. This lets determine_rate() and set_rate() select the firmware
operating point while retaining 2 GHz as a supported overclocking rate.

Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Cc: stable@vger.kernel.org # 7.0+
Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
---
The related U-Boot change is available at:
https://github.com/spacemit-com/uboot-2022.10/commit/fb95cf3d848b771c61b5a1b3e5cbbee223faf352
---
Changes in v3:
- Mark the change for stable kernels starting with v7.0.
- Add Aurelien Jarno's Reviewed-by and Tested-by trailers.
- Rebase onto v7.3-rc1.
- Link to v2: https://patch.msgid.link/20260810-k3-pll5-pll8-1800mhz-v2-1-aabff510a797@linux.spacemit.com

Changes in v2:
- Drop "clk: spacemit: re-enable PLLs after init"; the PLL init issue
  will be handled in a separate series.
- Send the K3 PLL5 and PLL8 1.8 GHz rate-table update as a standalone
  patch.
- Clarify that 1.8 GHz is nominal and 2 GHz is an overclocking rate.
- Link to v1: https://patch.msgid.link/20260804-k3-pll5-pll8-1800mhz-v1-0-a3a75866ce32@linux.spacemit.com

To: Stephen Boyd <sboyd@kernel.org>
To: Brian Masney <bmasney+clk@redhat.com>
To: Jerome Brunet <jbrunet+clk@baylibre.com>
To: Yixun Lan <dlan@kernel.org>
Cc: linux-clk@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Cc: spacemit@lists.linux.dev
Cc: linux-kernel@vger.kernel.org
---
 drivers/clk/spacemit/ccu-k3.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/spacemit/ccu-k3.c b/drivers/clk/spacemit/ccu-k3.c
index 92b930d5ff30..1796236d8dc5 100644
--- a/drivers/clk/spacemit/ccu-k3.c
+++ b/drivers/clk/spacemit/ccu-k3.c
@@ -38,6 +38,7 @@ static const struct ccu_pll_rate_tbl pll4_rate_tbl[] = {
 };
 
 static const struct ccu_pll_rate_tbl pll5_rate_tbl[] = {
+	CCU_PLLA_RATE(1800000000UL, 0x0b4b0000, 0x00000000, 0xa0458585),
 	CCU_PLLA_RATE(2000000000UL, 0x0b292aaa, 0x0000ab00, 0xa0558686),
 };
 
@@ -50,6 +51,7 @@ static const struct ccu_pll_rate_tbl pll7_rate_tbl[] = {
 };
 
 static const struct ccu_pll_rate_tbl pll8_rate_tbl[] = {
+	CCU_PLLA_RATE(1800000000UL, 0x0b4b0000, 0x00000000, 0xa0458585),
 	CCU_PLLA_RATE(2000000000UL, 0x0b292aaa, 0x0000ab00, 0xa0558686),
 };
 

---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260802-k3-pll5-pll8-1800mhz-c81875a0a944

Best regards,
--  
Troy Mitchell <troy.mitchell@linux.spacemit.com>

Re: [PATCH v3] clk: spacemit: k3: add 1.8 GHz PLL5 and PLL8 rates

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but `ccu_plla_init()` and `ccu_pll_init()` unconditionally disable the PLL without re-enabling it if the bootloader-configured hardware state is not found in the rate table. If this PLL feeds a critical component (e.g., CPU C2/C3 cores via PLL5/PLL8), disabling it during clock registration will instantly lock up the system.
--

commit 6e193fb72f81d59157c0ebe259d1101a840915f0
Author: Troy Mitchell <troy.mitchell@linux.spacemit.com>

clk: spacemit: k3: add 1.8 GHz PLL5 and PLL8 rates

K3 boot firmware configures the C2 and C3 CPU clock domains at
1.8 GHz. PLL5 feeds C2 and PLL8 feeds C3, but their rate tables
currently contain only the 2 GHz overclocking operating point.

> diff --git a/drivers/clk/spacemit/ccu-k3.c b/drivers/clk/spacemit/ccu-k3.c
> index 92b930d5ff305..1796236d8dc55 100644
> --- a/drivers/clk/spacemit/ccu-k3.c
> +++ b/drivers/clk/spacemit/ccu-k3.c
> @@ -38,6 +38,7 @@ static const struct ccu_pll_rate_tbl pll4_rate_tbl[] = {
>  };
>  
>  static const struct ccu_pll_rate_tbl pll5_rate_tbl[] = {
> +	CCU_PLLA_RATE(1800000000UL, 0x0b4b0000, 0x00000000, 0xa0458585),

[Severity: High]
This isn't a bug introduced by this patch, but ccu_plla_init() and
ccu_pll_init() unconditionally disable the PLL without re-enabling it if the
bootloader-configured hardware state is not found in the rate table.

If the bootloader configures a clock rate that is not present in the driver's
rate table, the clock initialization callback will disable it abruptly:

drivers/clk/spacemit/ccu_pll.c:ccu_plla_init() {
    ...
	if (ccu_plla_lookup_matched_entry(pll))
		return 0;

	ccu_plla_disable(hw);
	ccu_plla_update_param(pll, &pll->config.rate_tbl[0]);

	return 0;
}

The same pattern occurs in ccu_pll_init():

drivers/clk/spacemit/ccu_pll.c:ccu_pll_init() {
    ...
	if (ccu_pll_lookup_matched_entry(pll))
		return 0;

	ccu_pll_disable(hw);
	ccu_pll_update_param(pll, &pll->config.rate_tbl[0]);

	return 0;
}

Since these PLLs (such as PLL5 and PLL8) feed vital components like the CPU
C2/C3 cores, disabling them during clock registration instantly locks up the
system.

Can this be addressed to prevent a system hang if a custom firmware sets an
unlisted clock rate?

While the patch notes mention leaving the PLL init regression for a separate
series, does it make sense to fix the structural problem before adding new
rates?

>  	CCU_PLLA_RATE(2000000000UL, 0x0b292aaa, 0x0000ab00, 0xa0558686),
>  };
>  

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831-k3-pll5-pll8-1800mhz-v3-1-530ed0978615@linux.spacemit.com?part=1