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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABjd4YwQrnoeFU5Nm8Vy-=rFW-tfQuzQfYi+B2zmBdj_=Qh6EQ@mail.gmail.com>
Date: Sun, 15 Jun 2025 20:20:54 +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 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)
>
> as pvtpll is trying to reach target freq and ends with stable oper. freq for given cpu_vdd/temp/fab.cut - possible theory is: if cpu_vdd is wrongly driven, pvtpll programmed freq will way diff from req. (i.e. way too low).

It is an interesting line of thought. After all, RK3576 boards I
looked at use an I2C connected PMIC, while RK3588 use an SPI connected
one. If there is some bug in the I2C bus glue for the PMIC driver,  it
could theoretically report updated voltage without always updating it
properly.

I still believe it succeeds more often than not though, because I
observe measured power consumption of around 5W under full load vs.
around 1.4W in idle (on ArmSoM Sige5). Which doesn't rule out some
transient weirdness.

> monitoring vdd_big/vdd_lit shows constant 950mv for perf.gov (read from sysfs; not verified with multimeter as i don’t have pcb pdf with components layout so can’t identify i.e. vdd_big filtering caps c1007/c1008 to measure)

Measuring voltages to within 0.1V precision (not just resolution)
sounds like a big ask of a multimeter IMHO :)

Best,
Alexey