[RFC] accel/rocket: DVFS on RK3588 - a hardware constraint, and some numbers
Igor Paunovic
royalnet026 at gmail.com
Thu Sep 3 11:51:41 PDT 2026
Hi Huseyin,
> if the ccf is really giving locked 1ghz it is most likely reporting
> back what it is set, since scmi is probably returning 0, and ccf is
> ignoring that.
That was worth testing, so I did, this evening: 104 samples at 1 Hz
under sustained MobileNet load, reading in the same instant
CRU_CLKSEL_CON(74) from the kernel and scmi_clk_npu from clk_summary.
CON74 = 0x00001011, bit0 = 1, in all 104 samples
scmi_clk_npu = 1000000000, in all 104 samples
With bit0 set, clk_scmi_npu_get_rate() in your commit takes the
PVTPLL branch, which has no fallback: it returns whatever
NPUGRF+0x24 holds, so a zero there would have come back as 0 Hz, not
as 1 GHz. The "return the set rate" path is the GPLL branch, and it
was not taken. So the readback is the counter, not the request.
> If you read the clock in each 1 sec, you should almost always see a
> different value with several hertz of difference.
Agreed, and the register cannot show that: it reports whole MHz.
What I can say is that the NPU value was constant to the MHz over
104 samples, while the GPU on the same BL31 moved between 1047 and
1054. I withdraw the word "locks" from my last mail; "constant to
the MHz" is what was measured, and whether that is a tighter loop or
sub-MHz jitter is beyond this register.
> So it was a theory and probably a weak one.
Fair. What is measured is only this: the same register, read in the
same instant, gives a value from EL3 and zero from EL1. I will stop
calling the cause a firewall until someone knows what it is.
One more correction, to my mail of 18 Aug in this thread: "the 2.58x
I measured here with simple_ondemand against the 200 MHz pin" was a
projection from my harness, not a measurement. Measured today on one
boot, rail at 850 mV, bit-exact oracle in every run:
userspace @ 200 MHz 89 inf/s (NPU-side 9.65 ms)
userspace @ 1000 MHz 222 inf/s (NPU-side 3.02 ms)
simple_ondemand 221 inf/s -> 2.47x, 0.7 % below the pin
The magnitude held; the provenance was wrong, and I am sorry for it.
Enjoy the vacation, there is no hurry on any of this.
Igor
More information about the Linux-rockchip
mailing list