Hi Hüseyin, A correction to my two mails of 3 September in this thread, where I told you that the NPU readback from BL31 was the counter and not the request. You were right and I was wrong.
The reading stopped at clk_scmi_npu_get_rate() in rk3588_clk.c. The call goes through plat_scmi_clock_get_rate() in plat/rockchip/common/scmi/scmi_clock.c, which returns the last accepted rate (clock->cur_rate) whenever ->get_rate() returns 0. So "no fallback" was false: a zero in NPUGRF+0x24 comes back as the last rate the firmware accepted, which at an accepted OPP is the rate asked for, and that is exactly what I saw, 1000000000 in all 104 samples at the 1 GHz OPP. The GPU readback on the same BL31 moved (1047 to 1054 MHz), so on the GPU a counter is being read. The TRM lists NPU GRF 0x24 as NPU_GRF_NPUTOP_CON, but the GPU status word your commit reads at GPU GRF 0x18 is not in the TRM either, so the offset alone settles nothing. What I have is the EL1 read of NPU GRF 0x24, 0 in all 20 samples, and this: on 15 September, with the rail pinned at 850 mV, requests of 800, 900 and 1000 MHz read back exactly 800, 900 and 1000, although your table programs the same ring length for all three. One counter cannot return three numbers for one ring at one voltage. What stands: the CRU selector (CLKSEL_CON74 bit 0) shows the PVTPLL path, and the inference numbers in those mails and in the v2 cover are unchanged. What I withdraw: "secure world sees the counter", "the counter is alive in silicon", "EL3 reports raw measurements" and "the readback is the counter"; "constant to the MHz", which I offered in place of "locks", goes with them as a statement about the hardware; and "the clean telemetry path for rocket DVFS" holds for the GPU and the CPUs, not for the NPU. The actual NPU PVTPLL frequency is not measured on my board. I will say the same in the v3 cover. Sorry for arguing with you about it. An LLM (Claude) found the fallback and drafted this mail in English; I read it back in Serbian before sending. Igor
