From: Igor Paunovic <royalnet026@gmail.com>
To: Huseyin BIYIK <boogiepop@gmx.com>
Cc: Igor Paunovic <royalnet026@gmail.com>,
Nicolas Dufresne <nicolas@ndufresne.ca>,
Tomeu Vizoso <tomeu@tomeuvizoso.net>,
Heiko Stuebner <heiko@sntech.de>,
Jiaxing Hu <gahing@gahingwoo.com>,
Oded Gabbay <ogabbay@kernel.org>, Jonas Karlman <jonas@kwiboo.se>,
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: Thu, 3 Sep 2026 20:51:41 +0200 [thread overview]
Message-ID: <20260903185147.49411-1-royalnet026@gmail.com> (raw)
In-Reply-To: <2f88072c-6aa3-4294-a35d-722d1c7a405c@email.android.com>
Hi Huseyin,
> if the ccf is really giving locked 1ghz it is most likely reporting
> back what it is set, since scmi is probably returning 0, and ccf is
> ignoring that.
That was worth testing, so I did, this evening: 104 samples at 1 Hz
under sustained MobileNet load, reading in the same instant
CRU_CLKSEL_CON(74) from the kernel and scmi_clk_npu from clk_summary.
CON74 = 0x00001011, bit0 = 1, in all 104 samples
scmi_clk_npu = 1000000000, in all 104 samples
With bit0 set, clk_scmi_npu_get_rate() in your commit takes the
PVTPLL branch, which has no fallback: it returns whatever
NPUGRF+0x24 holds, so a zero there would have come back as 0 Hz, not
as 1 GHz. The "return the set rate" path is the GPLL branch, and it
was not taken. So the readback is the counter, not the request.
> If you read the clock in each 1 sec, you should almost always see a
> different value with several hertz of difference.
Agreed, and the register cannot show that: it reports whole MHz.
What I can say is that the NPU value was constant to the MHz over
104 samples, while the GPU on the same BL31 moved between 1047 and
1054. I withdraw the word "locks" from my last mail; "constant to
the MHz" is what was measured, and whether that is a tighter loop or
sub-MHz jitter is beyond this register.
> So it was a theory and probably a weak one.
Fair. What is measured is only this: the same register, read in the
same instant, gives a value from EL3 and zero from EL1. I will stop
calling the cause a firewall until someone knows what it is.
One more correction, to my mail of 18 Aug in this thread: "the 2.58x
I measured here with simple_ondemand against the 200 MHz pin" was a
projection from my harness, not a measurement. Measured today on one
boot, rail at 850 mV, bit-exact oracle in every run:
userspace @ 200 MHz 89 inf/s (NPU-side 9.65 ms)
userspace @ 1000 MHz 222 inf/s (NPU-side 3.02 ms)
simple_ondemand 221 inf/s -> 2.47x, 0.7 % below the pin
The magnitude held; the provenance was wrong, and I am sorry for it.
Enjoy the vacation, there is no hurry on any of this.
Igor
next prev parent reply other threads:[~2026-09-03 18:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-01 13:16 [RFC] accel/rocket: DVFS on RK3588 - a hardware constraint, and some numbers 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 [this message]
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
[not found] <DKDOBW9CJ2Y3.10EEIZDTXPYJZ@cknow-tech.com>
2026-08-01 14:40 ` Igor Paunovic
2026-08-01 16:29 ` Diederik de Haas
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=20260903185147.49411-1-royalnet026@gmail.com \
--to=royalnet026@gmail.com \
--cc=boogiepop@gmx.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gahing@gahingwoo.com \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--cc=linux-rockchip@lists.infradead.org \
--cc=nicolas@ndufresne.ca \
--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