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

[Igor Paunovic]

Hi Hüseyin,

A correction to my two mails of 3 September in this thread, where I
told you that the NPU readback from BL31 was the counter and not the
request. You were right and I was wrong.

The reading stopped at clk_scmi_npu_get_rate() in rk3588_clk.c. The
call goes through plat_scmi_clock_get_rate() in
plat/rockchip/common/scmi/scmi_clock.c, which returns the last
accepted rate (clock->cur_rate) whenever ->get_rate() returns 0. So
"no fallback" was false: a zero in NPUGRF+0x24 comes back as the last
rate the firmware accepted, which at an accepted OPP is the rate asked
for, and that is exactly what I saw, 1000000000 in all 104 samples at
the 1 GHz OPP. The GPU readback on the same BL31 moved (1047 to
1054 MHz), so on the GPU a counter is being read. The TRM lists NPU
GRF 0x24 as NPU_GRF_NPUTOP_CON, but the GPU status word your commit
reads at GPU GRF 0x18 is not in the TRM either, so the offset alone
settles nothing. What I have is the EL1 read of NPU GRF 0x24, 0 in all
20 samples, and this: on 15 September, with the rail pinned at 850 mV,
requests of 800, 900 and 1000 MHz read back exactly 800, 900 and 1000,
although your table programs the same ring length for all three. One
counter cannot return three numbers for one ring at one voltage.

What stands: the CRU selector (CLKSEL_CON74 bit 0) shows the PVTPLL
path, and the inference numbers in those mails and in the v2 cover are
unchanged. What I withdraw: "secure world sees the counter", "the
counter is alive in silicon", "EL3 reports raw measurements" and "the
readback is the counter"; "constant to the MHz", which I offered in
place of "locks", goes with them as a statement about the hardware;
and "the clean telemetry path for rocket DVFS" holds for the GPU and
the CPUs, not for the NPU. The actual NPU PVTPLL frequency is not
measured on my board. I will say the same in the v3 cover. Sorry for
arguing with you about it.

An LLM (Claude) found the fallback and drafted this mail in English;
I read it back in Serbian before sending.

Igor