[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