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

Hüseyin BIYIK boogiepop at gmx.com
Wed Aug 19 13:07:55 PDT 2026


Hello Igor

On 8/19/26 20:48, Igor Paunovic wrote:
> 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.

No you can even read them from userspace with mmap. i think there is 
also a firewall configuration where you can restrict the access per ip 
core, but default configuration should not require any EL escalation.

If the status register is providing 0, most likely it is not started (i 
am guessing by past experience).

Here are the most relevant registers:
GRF.CON0_L.start = 1; // start the status counter
GRF.CON0_L.en = 1; // enable PTVPLL
GRF.CON0_L.osc_ring_sel = n // ring to use
GRF.CON0_H.ring_sel_len = k // length of the ring
GRF.CAL_CNT = 24 // how many sample to average

Result is in:
GRF.STATUS0.OSC_CNT = ...

You can also mess around with this mmm userspace tool where you can edit 
the GRF registers visually in an easy way, the python code also shows 
how registers interact with each other when clock is calculated if you 
want to dig in deeper:

https://github.com/hbiyik/mmm

Here is a quick tutorial i had written on how to observe the PVTPLL 
status using mmm.
https://forum.radxa.com/t/mmm-memory-map-manipulator-perfect-tool-to-un-break-your-soc/15332/6

I hope sharing links is fine in mailing list.

Hüseyin



More information about the Linux-rockchip mailing list