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
