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
next parent reply other threads:[~2026-08-01 14:40 UTC|newest]
Thread overview: 25+ 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
2026-08-15 18:24 ` Tomeu Vizoso
2026-08-17 18:22 ` Nicolas Dufresne
2026-08-18 7:27 ` Igor Paunovic
2026-08-18 12:12 ` Jonas Karlman
2026-08-18 12:30 ` Jonas Karlman
2026-08-19 5:52 ` Igor Paunovic
2026-08-19 9:40 ` Jonas Karlman
2026-08-19 12:59 ` Igor Paunovic
2026-08-19 16:20 ` Jonas Karlman
2026-08-19 18:48 ` Igor Paunovic
2026-08-19 20:07 ` Hüseyin BIYIK
2026-09-02 11:04 ` Igor Paunovic
2026-09-03 9:16 ` Igor Paunovic
[not found] ` <2f88072c-6aa3-4294-a35d-722d1c7a405c@email.android.com>
2026-09-03 18:51 ` Igor Paunovic
2026-09-04 11:08 ` Jiaxing Hu
2026-09-04 12:46 ` Igor Paunovic
2026-09-05 5:13 ` Jiaxing Hu
2026-09-05 7:01 ` Igor Paunovic
2026-08-19 18:47 ` Nicolas Dufresne
2026-09-04 11:19 ` Jiaxing Hu
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