Hi Jonas, On 8/19/2026 6:20 PM, Jonas Karlman wrote: > Correct, the power domain must be powered on when PVTPLL is used, I > thought this had already been concluded. It is hard to fully keep track > when context keeps being removed in each new mail ;-)
Fair point taken - I will keep more of the quoted context from here on. And yes: what the reset run added over the earlier conclusion is only the differential part (bus clocks measurably contribute nothing), plus that the failure is an immediate firmware-level reset rather than a recoverable error. > It is probably not just set_rate, with PD and/or CLKs disabled just > reading clk_summary to read SCMI clock rate can issue SError or a freeze. That is a very useful data point - it widens the hazard from "rate changes" to "any SCMI clock op", so the series' guards have to cover get_rate paths too. It will be quoted in the cover letter. > To my knowledge there are status regs that can be used to get the > measured rate of the PVTPLL, at least upstream TF-A have a commit [3] > for RK3588 that changes to report the measured rate when PVTPLL mode is > used. This was exactly the missing piece - thank you. I tried it from the kernel side tonight, and here is an honest negative result: with the ring demonstrably live (CON74 bit0=1, CON0..2 readback matching the TF-A table for 1 GHz), the domain on, pclk_npu_root held, all three NPU PVTM gates in CLKGATE_CON(29) opened (bits 12/14/15), udelay(2) before each read, and even with the whole set_rate sequence re-run by the firmware after the gates were opened - NPU GRF+0x24 reads a hard 0x00000000 from EL1, twenty samples per arm, four arms. 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. [3] https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a.git/+/d2d6928641bacfa2370a9bb38cdddad229d99ad6 Regards, Igor
