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

[Igor Paunovic]

Hi Huseyin,

> 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.

You were right, and here is the number that proves it. On my daily
kernel, from plain userspace mmap, the GPU PVTPLL counter reads:

    GPU_GRF+0x18 (STATUS1) = 0x412 -> 1042 MHz measured,
    at the stock 1000 MHz PVTPLL operating point

so the written rate really is just nominal calibration, and the
actual ring runs 4.2% above it on this sample. One detail against
your note: on my board the live value shows up in STATUS1
(OSC_CNT_AVG), while STATUS0.OSC_CNT stays zero. Thank you for mmm
and for the TF-A pointer - both did exactly what you said.

The NPU counter is another story, and I can now bound it tightly.
With the ring alive and clocking the NPU at 1 GHz (CON74[0]=1,
CON0_L=0x103, length 12, CAL_CNT=24), NPU_GRF+0x24 stays zero from
both kernel ioremap and userspace mmap, after eliminating every
lever reachable from the non-secure side:

  - counter input select already xin_osc0_func (CON74[4]=1)
  - REF_CNT (+0x1c) tried both as found (0) and set to 0x18
  - every gate bit in CLKGATE_CON(27/28/29) opened, one register
    at a time and all together (27/28 were already fully ungated)
  - CON registers read and write fine throughout - only STATUS0/1
    stay zero

The GPU counter counts out of the box with its pvtm gates closed,
so none of the pvtm clocks are the reference. SkatterBencher's
rk3588-tools hit the same wall ("NPU PVTPLL is not working", with
the sel flip left unimplemented), so this seems to be a wall and
not my setup.

That leaves two candidates, and one of them is the firewall you
mentioned: either the NPU status words are restricted for
non-secure masters (per-ip-core firewall), or the counter is
simply not wired on the NPU instance. Have you ever seen a nonzero
NPU read on silicon, for example through your d2d6928641ba
get_rate path from EL3? My next step is to cherry-pick that commit
into my BL31: if EL3 also reads zero, the silicon answer wins.

Jonas: the GPU result above also answers the OSC counter offset
question from the pclk thread - GPU STATUS1 sits at GRF_GPU+0x18
and counts without any setup.

I added a GRF_NPU catalog entry to mmm while testing (start
0xFD5A200C, per the TF-A offsets). Happy to send it as a PR if
you want it despite the dead counter.

Igor