Message-ID: <CABjd4Yy0rjET+TyA3pNGrzfKd1xKKG1AjWFFLsgb+mgDpu_TRg@mail.gmail.com>
Date: Wed, 18 Jun 2025 18:48:27 +0400
From: Alexey Charkov <alchark@...il.com>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>, 
	XiaoDong Huang <derrick.huang@...k-chips.com>
Cc: Piotr Oniszczuk <piotr.oniszczuk@...il.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Heiko Stuebner <heiko@...ech.de>, devicetree@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, Jonas Karlman <jonas@...boo.se>
Subject: Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

On Wed, Jun 18, 2025 at 6:06 PM Nicolas Frattaroli
<nicolas.frattaroli@...labora.com> wrote:
>
> Hello,
>
> +Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,
>
> On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
> > On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
> > <piotr.oniszczuk@...il.com> wrote:
> > >
> > >
> > >
> > > > Wiadomość napisana przez Alexey Charkov <alchark@...il.com> w dniu 9 cze 2025, o godz. 16:05:
> > > >
> > > > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > > > <piotr.oniszczuk@...il.com> wrote:
> > > >>> Wiadomość napisana przez Alexey Charkov <alchark@...il.com> w dniu 5 cze 2025, o godz. 15:42:
> > > >>>> Alexey,
> > > >>>> I see you are using rk3576 board like me (nanopi-m5)
> > > >>>> Have you on your board correctly working cpu dvfs?
> > > >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> > > >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> > > >>>
> > > >>> Hi Piotr,
> > > >>>
> > > >>> I haven't tried to validate actual running frequencies vs. requested
> > > >>> frequencies, but subjective performance and power consumption seem to
> > > >>> be in line with what I expect.
> > > >>
> > > >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> > > >
> > > > In my experience, native compilation of GCC 14 using 8 threads on
> > > > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > > > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > > > case and throttling enabled but never kicking in): 1 hour 10 minutes
> > >
> > > by curiosity i looked randomly on 3576 vs 3588:
> > > multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> > > multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
> > >
> > > assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> > > 70 min compile on 3588 should take something like ~86min on 3576.
> > > In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> > > Roughly 3576 should do this task in 40min less than you currently see i think
> > >
> > >
> > > > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > > > use comparable ATF images. Do you use the same kernel and dtb in all
> > > > these cases? Also, what's your thermal setup?
> > >
> > > yes. in all cases only change was: uboot & atf
> > > thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
> > >
> > > >
> > > >
> > > > Not sure UX is a particularly good measure of CPU performance, as long
> > > > as you've got a properly accelerated DRM graphics pipeline. More
> > > > likely 2D/3D and memory.
> > >
> > > indeed.
> > > For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> > > by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> > > on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
> > >
> > > >
> > > > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > > > RK3588. But frankly first I would check if you are using comparable
> > > > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > > > thermal environment :)
> > >
> > > all tests: the same 6.15.2 mainline + some collabora patches
> > >
> > > diffs were:
> > > 1.collabora uboot[1] + mainline atf 2.13
> > > 2.collabora uboot[1] + rockchip rkbin bl31 blob
> > > 3.vendor uboot (bin dump from friendlyelec ubuntu image)
> > >
> > > on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> > > 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
> >
> > There is indeed something weird going on. I've tried running sbc-bench
> > [1], and even though I observe dynamically varying CPU frequencies
> > after boot with schedutil governor, once sbc-bench switches the
> > governor to "performance" and goes through the OPPs in descending
> > frequency order, the CPUs seem to get stuck at the last applied low
> > frequency. Even after max frequency gets reverted from 408 MHz to
> > something higher, even after I switch the governor to something else -
> > no matter what. Only a reboot gets the higher frequencies 'unstuck'
> > for me.
> >
> > These are all observed at around 55C SoC temperature, so throttling is
> > not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
> > that the 408 MHz OPP requires (and power readings seem to match: I'm
> > getting about 2.3W consumption at 408 MHz in idle vs. normal idle
> > reading of 1.4W at around 1 GHz).
> >
> > Not sure what's going on here, and I don't remember seeing anything
> > similar on RK3588. Thoughts welcome.
>
> This may once again be a "accidentally uses wrong clock IDs" type
> situation. The other possibility is that we're getting confused
> between what we think the clock rate is and what SCMI actually set
> the clock rate to.
>
> Things to check is whether the right clock controller (scmi vs cru)
> and the right clock id (check ATF source for this) is used.

Clock IDs in the kernel seem to match those in ATF, but I've noticed
what appears to be a buffer overflow in some of the SCMI clock names
defined in the opensource TF-A (thanks GCC 15 and its zealous
warnings):

alchark@...hark-surface ~/trusted-firmware-a $ make
CC=aarch64-unknown-linux-gnu-gcc PLAT=rk3576 -j12
Building rk3576
  CC      plat/rockchip/rk3576/scmi/rk3576_clk.c
plat/rockchip/rk3576/scmi/rk3576_clk.c:1102:154: error:
initializer-string for array of ‘char’ truncates NUL terminator but
destination lacks ‘nonstring’ attribute (17 chars into 16 available)
[-Werror=unterminated-string-initialization]
 1102 | stimer0_root, p_100m_24m, clk_stimer0_root_info,
&clk_scmi_ops_com_critical, rk3576_common_rates, false, true);
      |
                                              ^
plat/rockchip/rk3576/scmi/rk3576_clk.c:246:18: note: in definition of
macro ‘RK3576_SCMI_CLOCK_COM’
  246 |         .name = #_name,
         \
      |                  ^~~~~
plat/rockchip/rk3576/scmi/rk3576_clk.c:1103:154: error:
initializer-string for array of ‘char’ truncates NUL terminator but
destination lacks ‘nonstring’ attribute (17 chars into 16 available)
[-Werror=unterminated-string-initialization]
 1103 | stimer1_root, p_100m_24m, clk_stimer1_root_info,
&clk_scmi_ops_com_critical, rk3576_common_rates, false, true);
      |
                                              ^
plat/rockchip/rk3576/scmi/rk3576_clk.c:246:18: note: in definition of
macro ‘RK3576_SCMI_CLOCK_COM’
  246 |         .name = #_name,
         \
      |                  ^~~~~
plat/rockchip/rk3576/scmi/rk3576_clk.c:1107:155: error:
initializer-string for array of ‘char’ truncates NUL terminator but
destination lacks ‘nonstring’ attribute (17 chars into 16 available)
[-Werror=unterminated-string-initialization]
 1107 | ka_crypto_s, p_350m_175m_116m_24m, clk_pka_crypto_s_info,
&clk_scmi_ops_com, rk3576_common_rates, false, true);
      |
                                              ^
plat/rockchip/rk3576/scmi/rk3576_clk.c:246:18: note: in definition of
macro ‘RK3576_SCMI_CLOCK_COM’
  246 |         .name = #_name,
         \
      |                  ^~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:1644:
/home/alchark/trusted-firmware-a/build/rk3576/release/bl31/rk3576_clk.o]
Error 1

And indeed, clock names such as "clk_stimer0_root" don't leave enough
space in .name for the null terminator (given that .name is defined as
char name[SCMI_CLOCK_NAME_LENGTH_MAX]; a.k.a. 16).

Not sure if the binary BL31 has a similar issue and if it can lead to
the observed weirdness in CPU frequency switching. Looping in XiaoDong
Huang who last touched those lines in the opensource TF-A - any
insights would be much appreciated!

Thanks a lot,
Alexey

Powered by blists - more mailing lists