linux-kernel - Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CABjd4Yw3FyVS0MBk2WdWKb24vkqrb09Tx3tj6B-xsmG1-Csk7w@mail.gmail.com>
Date: Mon, 9 Jun 2025 18:05:32 +0400
From: Alexey Charkov <alchark@...il.com>
To: Piotr Oniszczuk <piotr.oniszczuk@...il.com>
Cc: Nicolas Frattaroli <nicolas.frattaroli@...labora.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
Subject: Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

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

> This directed me to investigate this issue.
> Test run was media player (mythtv) where ui has gl effects and ui gl transitions „speed” are quite proportional to cpu speed (and gpu).
> My overall feeling is: ux is comparable to slow socs 4xA53@...GHz/G31. This is with mainline atf + collabora uboot [1] and on-demand gov.
> I done test with replacing uboot from mainline atf + collabora uboot to bin. dump of vendor uboot (2017.09) and with this ux become almost as expected (i mean comparable with i.e. rk3399).
>
> I done test with perf gov. and
>
> 1.collabora uboot[1] + mainline atf 2.13
> 2.collabora uboot[1] + rockchip rkbin bl31 blob [2]
> 3.vendor uboot (bin dump from friendlyelec ubuntu image)
>
> [a] on vendor uboot:
> Requested CPU4: 2304 MHz
> Requested CPU0: 2208 MHz
> Running CPU4: 1008 MHz
> Running CPU0: 1008 MHz
> Measured on HW: 1580.11 MHz
>
> [b] on collabora uboot + mainline atf:
> Requested CPU4: 2304 MHz
> Requested CPU0: 2208 MHz
> Running CPU4: 816 MHz
> Running CPU0: 816 MHz
> Measured on HW: 808.72 MHz
>
> [c] on collabora uboot + rockchip rkbin bl31 blob:
> Requested CPU4: 2304 MHz
> Requested CPU0: 2208 MHz
> Running CPU4: 816 MHz
> Running CPU0: 816 MHz
> Measured on HW: 812.49 MHz
>
> in all cases all clocks are constant as they should
> Interesting that on collabora uboot [b][c] measured clock is 808 vs 1580 on vendor uboot [a]...
> sw video decode conforms this diff: hd h264 gets cpu load: 172%[b][c] vs 87%[a]

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?

> So summarising:
>
> 1. i see kind of issue with clock values (e.g. perf gov gives 800MHz on mainline atf).
> imho rot cause seems to be in collabora uboot
>
> 2. on-demand gov. seems behave much more like powersave.
> this seems to be 3576 specific:
> -on 3588 change from perf to on_demand is hardly noticeable in ux

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.

By the way, I'd rather go for the "schedutil" governor, as it is more
forward-looking than "ondemand", thus should be more responsive to
load changes. It's also the default in modern distros AFAIR.

> -on 3576 such change makes ux feeling noticeable slow (like 4xA53 soc)
> i think this is more related to diff between scmi mcu gov algo in 3576 vs. 3588
> (imho 3576 algo has high latency in clock increases when demand happens + too short delay for  clocks decreases to save power)

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 :)

Best regards,
Alexey