RK3399 CRU (clock and reset unit)

Identity

Status — ● working

CRU drives the entire boot path: every other working driver in the tree (eMMC, SD, USB, I2C, I2S, panfrost, VOP, DSI) depends on this node. The PMU CRU is a separate compatible node and also attaches.

The driver carries a per-PLL write filter so U-Boot’s live framebuffer hand-off survives kernel boot. As of 13e94af rk_cru: per-PLL whitelist for RK3399 PLL register window the filter is split per PLL window rather than blocking the whole 0x000–0x0FF page:

The display path on the PinePhone Pro feeds VOP-Lit through vop_lit_dclk_src, which muxes between VPLL and CPLL — so both stay frozen. DPLL stays frozen because every CPU is currently fetching from DRAM through it; a bad write halts the SoC. Everything else is writable at runtime, which means cpufreq_dt(4) writes to LPLL / BPLL succeed and powerd -a adaptive runs cleanly across both clusters.

Driver

• Our tree: src/sys/dev/clk/rockchip/rk_cru.c — generic Rockchip CRU framework used by RK3328 / RK3399 / RK3568, with the PinePhone-specific PLL guard layered on top.
• Linux mainline: drivers/clk/rockchip/clk-rk3399.c — upstream reference, allows full PLL programming.
• FreeBSD upstream: sys/dev/clk/rockchip/ — base driver framework.

The filter went through several shapes before 13e94af rk_cru: per-PLL whitelist for RK3399 PLL register window : 9c82b07 cru: only block VPLL writes (display), allow all other PLLs for audio/I2C blocked only VPLL; 854d8b2 cru: block CPLL + VPLL (display), allow GPLL/NPLL/LPLL/BPLL/DPLL blocked CPLL+VPLL; c15e051 cru: only allow GPLL writes (for audio), block all other PLLs — CPU/DDR/display PLLs crash tightened to allow GPLL only for audio; bb92c4f cru: allow CPLL/GPLL/NPLL/VPLL, only block CPU PLLs (LPLL/BPLL) and DDR (DPLL) went the other way and allowed CPLL/GPLL/NPLL/VPLL while blocking the cluster PLLs; the short-lived if (addr >= 0x100) return 1; blanket-block guarded the display through the eMMC migration. 1057e87 debug: log any blocked CRU register writes kept the debug log for blocked writes so surprises surface in dmesg.

cpufreq + powerd

Verified live on kernel #150 after 13e94af rk_cru: per-PLL whitelist for RK3399 PLL register window :

$ sysctl dev.cpu.0.freq_levels
dev.cpu.0.freq_levels: 1416/-1 1200/-1 1008/-1 816/-1 600/-1 408/-1
$ sudo sysctl dev.cpu.0.freq=1416
dev.cpu.0.freq: 600 -> 1416
$ sudo service powerd onestart
$ sysctl dev.cpu.0.freq dev.cpu.4.freq
dev.cpu.0.freq: 1008
dev.cpu.4.freq: 1008

No BLOCKED write lines after the freq change; both clusters scale together under load; display stays mapped through every transition. Init-time CPLL writes (0x60, 0x64, 0x68, 0x6c) from rk3399_cru’s clock-graph init are still blocked at boot, which is exactly what we want — those would re-tune the display feeder.

Open work

• Audit panfrost DVFS path: GPU lives off NPLL (now writable) but the OPP table on this hardware hasn’t been re-validated end-to-end.
• Consider whether one-shot CPLL writes can be re-enabled during a window where the framebuffer is paused (would need cooperation with the rk_vop atomic-helper path; ties into the modeset-lock wedge).
• Upstream cleanup so the PinePhone Pro guard is conditional, not a global hack.

Related

• Building from source — kernel build expectations.
• Audio on device — drove the CPLL allow-list shape.
• Cross-driver audit 2026-04-30 — Rockchip driver audit.
• Work log 2026-05-04 — eMMC migration + WiFi fn2 fix + per-PLL whitelist landing.