Re: [RFC] accel/rocket: DVFS on RK3588 - a hardware constraint, and some numbers

[Igor Paunovic <royalnet026@gmail.com>]

Hi Jonas,

On 8/18/2026 2:30 PM, Jonas Karlman wrote:
> Looking closer at my old commits, it was the PCLK_GPU_ROOT that was
> needed for e.g. RK3576 and RK3528. This clock is not described in RK3588
> clock tree so it never gets disabled by Linux clock framework.
>
> I suspect similarly one of the NPU root clocks is what drives the NPU
> PVTPLL and thus always must be kept enabled when PVTPLL mode is used.

Thank you - the PCLK_GPU_ROOT observation was the missing piece. I went
through the firmware my board actually runs and can now name the clock
for the NPU case.

First a correction to what I told Nicolas earlier: my BL31 is not the
vendor blob. The boot banner reports v2.12.0-9-gd5c68fd92, which is the
edk2-rk3588 project's TF-A branch: upstream v2.12.0 plus nine feature
commits (SCMI voltage domain, eMMC clock, TRNG, ...). The only one of
those touching rk3588_clk.c adds an eMMC clock; the NPU set_rate/PVTPLL
path is unmodified mainline v2.12. So Nicolas and I are effectively
running the same clock code, and the firmware-difference caveat from my
earlier mail mostly evaporates.

What clk_npu_set_rate() in plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c
does:

- The rate table gives every OPP from 300 MHz up a ring length > 0, so
  they all take the PVTPLL path; 200 MHz has length 0 and takes the
  normal GPLL divider path. The 200 MHz suspend rate we both converged
  on is therefore safe by construction on this SoC.

- For a PVTPLL rate the firmware programs ring_sel/length/calibration
  (cal cnt = 24, T = 1 us, i.e. a 24 MHz reference) into NPU GRF at
  0xfd5a2000 (NPU_PVTPLL_CON0..2), and only then flips the mux in CRU
  CLKSEL_CON(74) to the PVTPLL path.

The Linux side is where the NPU differs from your GPU case: the NPU
root clocks are fully described in clk-rk3588.c. pclk_npu_root is a
gateable composite (CLKGATE_CON(29) bit 4) and NPU GRF hangs off it
(pclk_npu_grf, CLK_IGNORE_UNUSED). In the mainline DT only core 0
(fdab0000) requests PCLK_NPU_ROOT as its "pclk"; cores 1/2 only hold
their aclk/hclk. So whenever core 0 is runtime-suspended, pclk_npu_root
has no user left and gets gated.

An SCMI set_rate to a PVTPLL rate issued in that state programs a GRF
whose bus clock is off, while the mux write still lands because the CRU
is always clocked - leaving clk_npu_dsu0 parked on a ring that was
never configured. That matches the empirical failure in my RFC exactly:
the sysfs min_freq write while suspended, followed by the power-domain
power-on ack timeout. (I have not put a scope on the APB bus, so "the
GRF write cannot land" is inferred from the failure signature plus the
gate state, not observed directly.)

For the series this reinforces the hold-all guard: resuming all cores -
core 0 in particular - around every rate change keeps pclk_npu_root
enabled for the duration of the SCMI call, closing the window for the
sysfs, governor and cooling paths alike. Your .config_clks() +
pm_runtime_suspended() check covers the OPP-initiated paths; I will
reference it and your branch in the cover letter.

One open point where your GPU experience may help: besides the GRF
programming interface, do you know whether the ring/monitor logic also
depends on hclk_npu_root, or is the 24 MHz calibration reference
(xin24m, always on) the only other input? If you never had to find out,
I will determine it empirically by holding only pclk and cycling rates.

Regards,
Igor

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip