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

["Diederik de Haas" <diederik@cknow-tech.com>]

On Sat Aug 1, 2026 at 4:40 PM CEST, Igor Paunovic wrote:
> 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.

Then I guess it's useful I add the main part of that pointer to the ML:

  This is all 'above my paygrade', but the 'failed to get ack on domain' is
  a type of error which seems to surface on a regular basis:
  https://lore.kernel.org/linux-rockchip/?q=%22failed+to+get+ack+on+domain%22

(My hope was that it may have given Igor pointers wrt the problem)

> 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
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip