Some RP1 clocks broken in 6.18

[njhollinghurst]

Describe the bug

Raspberry Pi 5: VEC, DPI and Audio Out are all broken with rpi-6.18.y (worked with rpi-6.12.y).

Although the DPI driver messes with its clock setup, both VEC and DPI rely on DeviceTree to assign the correct clock rates and parents. They all now complain that they're unable to select the assigned parent, and seem to end up with wildly wrong frequencies.

I note that in clk-rp1.c, clk_audio_out no longer lists pll_audio_sec in its list of parents, which seems wrong. However, this does not explain why VEC would fail to assign pll_video_sec as a parent.

Steps to reproduce the behaviour

Raspberry Pi 5: enable either VEC or DPI, optionally with Audio Out, using a subset of:

dtoverlay=vc4-kms-v3d,composite
#dtoverlay=vc4-kms-vga666    # remove composite to test this
dtoverlay=audremap

See errors in dmesg; measure the output waveforms or time video fame rate using e.g. kmstest --flip=100.

Device (s)

Raspberry Pi 5

System

Raspberry Pi 5 Model B Rev 1.1
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
Linux raspberrypi 6.18.1-v8-16k+ #241 SMP PREEMPT Wed Dec 17 14:33:37 GMT 2025 aarch64 GNU/Linux

Local kernel build at commit e132677 (HEAD -> rpi-6.18.y, origin/rpi-6.18.y) Fri Dec 12 19:41:23 2025 +0000

Logs

[    4.150084] clk: failed to reparent clk_vec to pll_video_sec: -22
[    4.150385] clk: couldn't set clk_vec clk rate to 108000000 (-22), current rate: 100000000

[    4.219145] clk: failed to reparent clk_audio_out to pll_audio_sec: -22

Additional context

No response

[njhollinghurst]

I can bodge VEC to work using this patch (in rp1.dtsi):

@@ -1202,14 +1202,14 @@ rp1_vec: vec@144000 {
                        clocks = <&rp1_clocks RP1_CLK_VEC>;
 
                        assigned-clocks = <&rp1_clocks RP1_PLL_VIDEO_CORE>,
-                                         <&rp1_clocks RP1_PLL_VIDEO_SEC>,
+                                         <&rp1_clocks RP1_PLL_VIDEO>,
                                          <&rp1_clocks RP1_CLK_VEC>;
-                       assigned-clock-rates = <1188000000>,
-                                              <108000000>,
-                                              <108000000>;
+                       assigned-clock-rates = <1080000000>,
+                                              <216000000>,
+                                              <216000000>;
                        assigned-clock-parents = <0>,
                                                 <&rp1_clocks RP1_PLL_VIDEO_CORE>,
-                                                <&rp1_clocks RP1_PLL_VIDEO_SEC>;
+                                                <&rp1_clocks RP1_PLL_VIDEO>;
                };

Despite asking for 216MHz, it then runs at the desired rate of 108MHz.

This makes little sense.

it's not inconceivable that the RP1 clocks driver is entirely broken, and that clk_sys, Ethernet and USB work only because they've been configured correctly by firmware?

[pelwell]

FYI: I'm looking specifically at the audio_out clock reparenting issue.

[njhollinghurst]

FWIW, a similar bodge works for Audio out: Need to add PLL_AUDIO (primary, not secondary divider!) to the parents table in clk-rp1.c; then change the DTS to use it, and for no good reason double the rate of both the divider and requested clock.

(Even ignoring the factor of 2, that can't be quite done IRL because it shares PLL_AUDIO with I2S.)

[njhollinghurst]

I believe there are at least 3 bugs, but my understanding of the last one is still fuzzy.

• Wrong definition and use of PLL_CS_REFDIV_MASK -- this could be the mysterious factor of 2
• Some clock parents missing from tables, including necessary ones (as well as unused GPIO clock sources)
• Secondary dividers can't be matched as parents, possibly due to confusion between desc.hw and desc.div.hw?

[pelwell]

I've seen evidence of the last of those but didn't manage to root cause it yet

[njhollinghurst]

Draft fix for first one: njhollinghurst@2c1d1aa

[pelwell]

The third one is fixed by the careful use of &<clock>.div.hw in the parent declarations (but then I get complaints about the clock rate:

clk: couldn't set clk_audio_out clk rate to 153600000 (-22), current rate: 192000001

so there is still work to do).

[njhollinghurst]

It's failing the "maximum clock rate" check in rp1_clock_choose_div_and_prate.
This is is expected to fail sometimes, if the wrong parent clock is chosen and fractional division is not available.
EDIT: but in this case it does indeed shed light on the bug: it suggests the divider's rate was not correctly set (or not correctly retrieved).

[njhollinghurst]

Bug 4: rp1_pll_divider_determine_rate() was mixing up its return status value with the returned clock rate, here:

linux/drivers/clk/clk-rp1.c

Line 773 in e132677

req->rate = clk_divider_ops.determine_rate(hw, req);

I also note that my hack to tolerate rounding errors in rp1_clock_choose_div_and_prate() has been deleted. It may be needed for Audio Out, which is returning a calculated rate of 153600001 where the maximum permitted rate is 153600000 (it nevertheless succeeds here because the parent is hard-coded).

I hope that's everything. Expect a PR soon (but it probably won't be merged this year).

[njhollinghurst]

Next problem: XOSC is absent from all the "parents" tables, perhaps because its address isn't known. I guess the solution is to refer to it by name.

I don't understand how any RP1 clocks could ever have worked. CC @P33M @naushir in case it's of interest.

[pelwell]

Isn't XOSC represented by the .index = 0 entries in the _parents arrays?

[njhollinghurst]

Isn't XOSC represented by the .index = 0 entries in the _parents arrays?

How does the driver match that to the source clock defined in DeviceTree, and discover its frequency?
Oh, I get it now -- so that's what "index" means!
(Presumably the ones that define .hw to be non-NULL somehow overrides the default .index = 0. How confusing.)

[pelwell]

Here's my working tree, in case you want to copy my .div.hw patch: https://github.com/pelwell/linux/tree/rp1clk

[njhollinghurst]

I might copy the whole thing.

Ah, I see you have pelwell@d59c58d
Was that a downstream change on 6.12 that got lost? github won't show me the original timestamp!