Re: [RFC] accel/rocket: DVFS on RK3588 - a hardware constraint, and some numbers
Hüseyin BIYIK <[email protected]>
| Newsgroups | org.infradead.lists.linux-rockchip,org.freedesktop.lists.dri-devel |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ Linux-rockchip mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-rockchip