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

[Igor Paunovic]

Hi Jonas,

On 8/19/2026 6:20 PM, Jonas Karlman wrote:
> Correct, the power domain must be powered on when PVTPLL is used, I
> thought this had already been concluded. It is hard to fully keep track
> when context keeps being removed in each new mail ;-)

Fair point taken - I will keep more of the quoted context from here on.
And yes: what the reset run added over the earlier conclusion is only
the differential part (bus clocks measurably contribute nothing), plus
that the failure is an immediate firmware-level reset rather than a
recoverable error.

> It is probably not just set_rate, with PD and/or CLKs disabled just
> reading clk_summary to read SCMI clock rate can issue SError or a freeze.

That is a very useful data point - it widens the hazard from "rate
changes" to "any SCMI clock op", so the series' guards have to cover
get_rate paths too. It will be quoted in the cover letter.

> To my knowledge there are status regs that can be used to get the
> measured rate of the PVTPLL, at least upstream TF-A have a commit [3]
> for RK3588 that changes to report the measured rate when PVTPLL mode is
> used.

This was exactly the missing piece - thank you. I tried it from the
kernel side tonight, and here is an honest negative result: with the
ring demonstrably live (CON74 bit0=1, CON0..2 readback matching the
TF-A table for 1 GHz), the domain on, pclk_npu_root held, all three
NPU PVTM gates in CLKGATE_CON(29) opened (bits 12/14/15), udelay(2)
before each read, and even with the whole set_rate sequence re-run by
the firmware after the gates were opened - NPU GRF+0x24 reads a hard
0x00000000 from EL1, twenty samples per arm, four arms.

So a question for you and for Hüseyin (added to Cc): is that
STATUS register perhaps readable from EL3 only, with EL1 reads as
zero? That would explain everything, since [3] reads it inside the
firmware. If so, the clean path is the one [3] already implements -
after my trip I will cherry-pick it into the BL31 my board runs (it is
plain upstream v2.12 there) and re-measure through plain clk_get_rate,
which also spares the kernel any GRF access at all.

[3] https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a.git/+/d2d6928641bacfa2370a9bb38cdddad229d99ad6

Regards,
Igor