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

Igor Paunovic <[email protected]> Sat, 1 Aug 2026 16:40:21 +0200
Newsgroups org.infradead.lists.linux-rockchip,org.freedesktop.lists.dri-devel
Message-ID <[email protected]>
Hi Diederik,

(re-adding the lists, your reply came to me only)

Thanks - that pointer was useful, and it changes what I thought I was
looking at.  Two things came out of following it.

First, a data point that may narrow your search rather than widen it:
this board is not running upstream TF-A.  Its SCMI implementation
identifies itself as Rockchip's own:

  arm-scmi arm-scmi.0.auto: SCMI Protocol v2.0 'rockchip:' Firmware version 0x0

and it still fails, so whatever this is, it is not exclusive to upstream
TF-A BL31.  If rkbin BL31 makes your PineTab2 suspend/resume work, the
difference there may be something more specific than the ack handshake
itself.

Second, going through the archive for that error string, the history is
longer than I realised - Peter Geis' and Sebastian Reichel's pmdomain
work on RK3588, and further back "arm64: dts: rockchip: add hevc power
domain clock to rk3328".  That last one is interesting because the fix
was to add a missing clock to the power domain, i.e. the handshake
needs its clocks.

What I have looks like a neighbouring case rather than the same one.
Here the clocks are not missing - all three NPU domains already list the
NPU clock (rk3588-base.dtsi lines 864, 877 and 885).  It is the rate
that matters: the ack never arrives if the domain is moved while that
clock is above its DT assigned-clock-rate, and the same domain moves
cleanly once the rate is back down.  I have not seen that variant
described anywhere, which is why I wrote it up.

That suggests something you could try, though it is a guess and you know
your board far better than I do: if any clock listed in a domain you are
suspending happens to be at a non-boot rate at that moment - left there
by devfreq, by an assigned-clock-rate, or by whatever ran last - then it
would be the same shape as what I am seeing.  Pinning those clocks to
their boot rates before the transition would be a cheap thing to rule
out.  If it does nothing, at least it is eliminated.

Thanks again for taking the time, and good luck with the PineTab2.

Igor

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip