[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