Starting with version k3-br-v1.0.7, the vendor U-Boot configures the C0
and C1 CPU clock domains (X100 cores) to 2.0 GHz instead of 2.2 GHz.
PLL3 feeds C0 and PLL4 feeds C1, but their rate tables currently contain
only the 2.2 GHz overclocking operating point. This causes the linux
kernel to hang at boot.

Add the 2.0 GHz configuration in both tables to fix the issue. Tested
with both k3-br-v1.0.5 (X100 running at 2.2 GHz) and k3-br-v1.0.7 (X100
cores running at 2.0 GHz).

Cc: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Cc: stable@kernel.org
Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree")
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
---
 drivers/clk/spacemit/ccu-k3.c | 2 ++
 1 file changed, 2 insertions(+)

The related U-Boot change is available at:
https://github.com/spacemit-com/uboot-2022.10/commit/274f664150dade144df265baf7dc8e15dd9cce52

diff --git a/drivers/clk/spacemit/ccu-k3.c b/drivers/clk/spacemit/ccu-k3.c
index d676a692bccb4..40a2dab1a2a71 100644
--- a/drivers/clk/spacemit/ccu-k3.c
+++ b/drivers/clk/spacemit/ccu-k3.c
@@ -30,10 +30,12 @@ static const struct ccu_pll_rate_tbl pll2_rate_tbl[] = {
 };
 
 static const struct ccu_pll_rate_tbl pll3_rate_tbl[] = {
+	CCU_PLLA_RATE(2000000000UL, 0x0b292aaa, 0x0000ab00, 0xa0558686),
 	CCU_PLLA_RATE(2200000000UL, 0x0b2d3555, 0x00005500, 0xa0558787),
 };
 
 static const struct ccu_pll_rate_tbl pll4_rate_tbl[] = {
+	CCU_PLLA_RATE(2000000000UL, 0x0b292aaa, 0x0000ab00, 0xa0558686),
 	CCU_PLLA_RATE(2200000000UL, 0x0b2d3555, 0x00005500, 0xa0558787),
 };
 
-- 
2.53.0

On 2026-08-30 19:28, Aurelien Jarno wrote:
> Starting with version k3-br-v1.0.7, the vendor U-Boot configures the C0
> and C1 CPU clock domains (X100 cores) to 2.0 GHz instead of 2.2 GHz.
> PLL3 feeds C0 and PLL4 feeds C1, but their rate tables currently contain
> only the 2.2 GHz overclocking operating point. This causes the linux
> kernel to hang at boot.
> 
> Add the 2.0 GHz configuration in both tables to fix the issue. Tested
> with both k3-br-v1.0.5 (X100 running at 2.2 GHz) and k3-br-v1.0.7 (X100
> cores running at 2.0 GHz).
> 
> Cc: Troy Mitchell <troy.mitchell@linux.spacemit.com>
> Cc: stable@kernel.org
> Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree")
> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
> ---
>  drivers/clk/spacemit/ccu-k3.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> The related U-Boot change is available at:
> https://github.com/spacemit-com/uboot-2022.10/commit/274f664150dade144df265baf7dc8e15dd9cce52

FYI, this is the Sashiko review:
https://lore.kernel.org/20260830173644.193B21F000E9@smtp.kernel.org

While I agree we can fix the SpacemiT clock driver, we'll need to add 
this rate anyway, and it immediately fixes the issue. Fixing the clock 
driver is more work and this will take more time to fix.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

On Mon Aug 31, 2026 at 2:12 AM +08, Aurelien Jarno wrote:
> On 2026-08-30 19:28, Aurelien Jarno wrote:
>> Starting with version k3-br-v1.0.7, the vendor U-Boot configures the C0
>> and C1 CPU clock domains (X100 cores) to 2.0 GHz instead of 2.2 GHz.
>> PLL3 feeds C0 and PLL4 feeds C1, but their rate tables currently contain
>> only the 2.2 GHz overclocking operating point. This causes the linux
>> kernel to hang at boot.
>> 
>> Add the 2.0 GHz configuration in both tables to fix the issue. Tested
>> with both k3-br-v1.0.5 (X100 running at 2.2 GHz) and k3-br-v1.0.7 (X100
>> cores running at 2.0 GHz).
>> 
>> Cc: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>> Cc: stable@kernel.org
>> Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree")
>> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
>> ---
>>  drivers/clk/spacemit/ccu-k3.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> The related U-Boot change is available at:
>> https://github.com/spacemit-com/uboot-2022.10/commit/274f664150dade144df265baf7dc8e15dd9cce52
>
> FYI, this is the Sashiko review:
> https://lore.kernel.org/20260830173644.193B21F000E9@smtp.kernel.org
>
> While I agree we can fix the SpacemiT clock driver, we'll need to add 
> this rate anyway, and it immediately fixes the issue. Fixing the clock 
> driver is more work and this will take more time to fix.
This is indeed an issue that needs to be fixed, but not right now.

It isn't directly related to adding the frequency table either,
so I chose to submit the frequency table separately first to get it merged
as soon as possible.

-- 
Troy Mitchell