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

Wed Aug 19 11:47:17 PDT 2026

Le mercredi 19 août 2026 à 11:40 +0200, Jonas Karlman a écrit :
> Hi Igor,
> 
> On 8/19/2026 7:52 AM, Igor Paunovic wrote:
> > 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.)
> 
> Ideally the SCMI firmware code should probably be updated to ensure any
> required root clock is ungated, and possible also hide some related
> clocks from OS. I am not even sure this is feasible option and this may
> diverge too much from vendor blobs and may not be backward compatible.
> 
> > 
> > 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.
> 
> I played around with Nicolas patches and created a more updated
> config_clks() variant that tries to use the clocks configured for opp
> instead of keeping track of the clock, see [2]. Have not done any
> runtime testing of that, but wanted to share the link anyway :-)
> 
> If I remember correctly for the GPU path on RK3576, keeping the 'bus'
> clock enabled at all times helped ensure any root clock was enabled
> while GRF is accessed. I cannot remember that I had any issues with GPU
> GRF access for PD and sysfs governor paths. The config_clks() helped
> ensure set_rate never was called during GPU probe or when governor was
> changed. Maybe I missed testing some other paths :-)
> 
> [2] https://github.com/Kwiboo/linux-rockchip/commits/next-20260803-rk-hdmi-v6/

This looks like one of many hacks down, I'll make sure to test and integrate
that.

cheers,
Nicolas

> 
> > 
> > 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.
> 
> I do not know, and never looked too deep into it, with the root clk
> enabled everything seemed to work great, so I was happy enough with that
> and just moved on to next thing :-)
> 
> Regards,
> Jonas
> 
> > 
> > Regards,
> > Igor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20260819/6b0d2f83/attachment.sig>