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

[Igor Paunovic]

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.

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