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

[Jonas Karlman]

Hi again,

On 8/18/2026 2:12 PM, Jonas Karlman wrote:
> Hi Igor,
> 
> On 8/18/2026 9:27 AM, Igor Paunovic wrote:
>> Hi Nicolas,
>>
>>> I'm only looking at the RK3588, I suppose all the issues below
>>> related to RK3576 ?
>>
>> No - everything in the RFC is RK3588 (Orange Pi 5 Plus, all three
>> cores). RK3576 is Jiaxing's enablement series and has its own set of
>> problems; nothing I reported came from there.
>>
>> I went through the four commits on rock5b-npu-poc-4 today. We
>> converged on the same shape independently, which is encouraging:
>> 200 MHz kept as the suspend rate, a single devfreq instance modelled
>> on panfrost with busy time aggregated across the three cores, and a
>> cooling device on top. Your ~2.5x on the SSD pipeline also matches
>> the 2.58x I measured here with simple_ondemand against the 200 MHz
>> pin.
>>
>> The TF-A pointer (rk3588_clk.c, PVTPLL vs normal path) is the most
>> valuable part for me - it names the mechanism behind the power-on
>> ack failure I could only demonstrate empirically. I will reference
>> it in the cover letter once I have checked the firmware source
>> myself.
> 
> Based on what I learnt when playing around with the SCMI GPU pvtpll [1],
> we must keep core block clock enabled as long as PVTPLL mode is enabled
> instead of the normal PLL mode.
> 
> When PVTPLL mode is enabled, the PVTPLL GRF, PD and GPU block is fully
> provided by the PVTPLL clock, i.e. SError when accessing hw regs in
> case Linux disables CLK_GPU.

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.

Regards,
Jonas

> Linux does not know anything about PVTPLL mode, the SCMI clocks are
> fully controlled by firmware (tf-a) and basically switches to use PVTPLL
> mode for all rates above 100/200/300 MHz.
> 
> Vendor kernel typically always changes to use 100/200/300 MHz at system
> and runtime suspend to disable use of PVTPLL.
> 
> Because this PVTPLL dependency is not really known to Linux we must
> use workarounds to hide this, ideally we should fully implement PVTPLL
> handling in Linux or ensure firmware always keep dependent clocks
> enabled to avoid SError when accessing regs.
> 
> For GPU case I depend on the opp-suspend rate to ensure opp and runtime
> pm framework make best effort to restore normal mode when GPU is unused.
> 
> However, opp framework does not provide any integration into pm runtime
> so it will happily clk_set_rate() when pm runtime is suspended. My
> workaround to avoid SError was to use a custom .config_clks() ops in
> struct dev_pm_opp_config that just checks pm_runtime_suspended().
> 
> The RFC series at [1] was never posted on mailing list, but is currently
> in use by e.g. Armbian to allow use of full 1 GHz rate of GPU on RK3588.
> 
> I am guessing NPU have similar limitations/requirements as the GPU block.
> 
> [1] https://github.com/Kwiboo/linux-rockchip/commits/next-20260619-rk35xx-scmi-gpu-clk/
> 
> Regards,
> Jonas
> 
>>
>> Status here: after Tomeu's go-ahead I am preparing the series -
>> bindings, a full-range OPP table in the DT (300-1000 MHz plus the
>> 200 MHz suspend point, so essentially the table you ended up with),
>> a safe-rate-on-suspend guard, the devfreq itself, and a hold-all
>> guard that resumes all cores around any rate change. The guard is
>> ordered before the devfreq patch so no bisect point has scaling
>> without it. The one hard dependency is my "request the core clocks
>> by name" v2, still waiting for pickup.
>>
>> Agreed on OPP staying optional - the plan in my series is that the
>> driver keeps working with no OPP table in the DT, which I saw you
>> intend to fix on your side as well.
>>
>> One path worth checking in your PoC, because it is the one that
>> made me write the hold-all guard: a sysfs min_freq/max_freq write
>> while all three cores are runtime-suspended goes straight to
>> clk_set_rate, which can select the PVTPLL path while the domain is
>> off - exactly the case your TF-A reference explains. With the guard
>> in place I measured that write waking the cores and completing
>> cleanly.
>>
>> One difference in test conditions worth keeping in mind: my numbers
>> are with the vendor bl31 that EDK2 bundles, yours is upstream TF-A.
>> Comparing SCMI behaviour on both seems wise before either of us
>> claims anything firmware-specific.
>>
>> Thank you for the "take whatever you like" - anything I lift will
>> carry credit, and I will Cc you on the series.
>>
>> Regards,
>> Igor
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>