From: Igor Paunovic <royalnet026@gmail.com>
To: Diederik de Haas <diederik@cknow-tech.com>
Cc: Igor Paunovic <royalnet026@gmail.com>,
Tomeu Vizoso <tomeu@tomeuvizoso.net>,
Heiko Stuebner <heiko@sntech.de>,
Jiaxing Hu <gahing@gahingwoo.com>,
Oded Gabbay <ogabbay@kernel.org>,
dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org
Subject: Re: [RFC] accel/rocket: DVFS on RK3588 - a hardware constraint, and some numbers
Date: Sat, 1 Aug 2026 16:40:21 +0200 [thread overview]
Message-ID: <20260801144021.7583-1-royalnet026@gmail.com> (raw)
In-Reply-To: <DKDOBW9CJ2Y3.10EEIZDTXPYJZ@cknow-tech.com>
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
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next parent reply other threads:[~2026-08-01 14:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <DKDOBW9CJ2Y3.10EEIZDTXPYJZ@cknow-tech.com>
2026-08-01 14:40 ` Igor Paunovic [this message]
2026-08-01 16:29 ` [RFC] accel/rocket: DVFS on RK3588 - a hardware constraint, and some numbers Diederik de Haas
2026-08-01 13:16 Igor Paunovic
2026-08-01 19:32 ` Jiaxing Hu
2026-08-02 12:04 ` Igor Paunovic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260801144021.7583-1-royalnet026@gmail.com \
--to=royalnet026@gmail.com \
--cc=diederik@cknow-tech.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gahing@gahingwoo.com \
--cc=heiko@sntech.de \
--cc=linux-rockchip@lists.infradead.org \
--cc=ogabbay@kernel.org \
--cc=tomeu@tomeuvizoso.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox