Hi Nicolas, > I'm only looking at the RK3588, I suppose all the issues below > related to RK3576 ?
No - everything in the RFC is RK3588 (Orange Pi 5 Plus, all three cores). RK3576 is Jiaxing's enablement series and has its own set of problems; nothing I reported came from there. I went through the four commits on rock5b-npu-poc-4 today. We converged on the same shape independently, which is encouraging: 200 MHz kept as the suspend rate, a single devfreq instance modelled on panfrost with busy time aggregated across the three cores, and a cooling device on top. Your ~2.5x on the SSD pipeline also matches the 2.58x I measured here with simple_ondemand against the 200 MHz pin. The TF-A pointer (rk3588_clk.c, PVTPLL vs normal path) is the most valuable part for me - it names the mechanism behind the power-on ack failure I could only demonstrate empirically. I will reference it in the cover letter once I have checked the firmware source myself. Status here: after Tomeu's go-ahead I am preparing the series - bindings, a full-range OPP table in the DT (300-1000 MHz plus the 200 MHz suspend point, so essentially the table you ended up with), a safe-rate-on-suspend guard, the devfreq itself, and a hold-all guard that resumes all cores around any rate change. The guard is ordered before the devfreq patch so no bisect point has scaling without it. The one hard dependency is my "request the core clocks by name" v2, still waiting for pickup. Agreed on OPP staying optional - the plan in my series is that the driver keeps working with no OPP table in the DT, which I saw you intend to fix on your side as well. One path worth checking in your PoC, because it is the one that made me write the hold-all guard: a sysfs min_freq/max_freq write while all three cores are runtime-suspended goes straight to clk_set_rate, which can select the PVTPLL path while the domain is off - exactly the case your TF-A reference explains. With the guard in place I measured that write waking the cores and completing cleanly. One difference in test conditions worth keeping in mind: my numbers are with the vendor bl31 that EDK2 bundles, yours is upstream TF-A. Comparing SCMI behaviour on both seems wise before either of us claims anything firmware-specific. Thank you for the "take whatever you like" - anything I lift will carry credit, and I will Cc you on the series. Regards, Igor
