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 >> [email protected] >> http://lists.infradead.org/mailman/listinfo/linux-rockchip >
