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

[Alexey Charkov]

On Thu, Jun 5, 2025 at 5:22 PM Piotr Oniszczuk
<piotr.oniszczuk at gmail.com> wrote:
>
>
>
> > Wiadomość napisana przez Alexey Charkov <alchark at gmail.com> w dniu 4 cze 2025, o godz. 21:12:
> >
> > On Wed, Jun 4, 2025 at 10:38 PM Nicolas Frattaroli
> > <nicolas.frattaroli at collabora.com> wrote:
> >>
> >>
> >
> > Frequencies are fine, but I don't think the more power hungry big CPU
> > cluster gets any voltage scaling without it. Once I try to load the
> > system enough that the governor decides to bump the big cluster
> > frequency up, the regulator stays at 850000 microvolts, causing random
> > reboots when the whole cluster starts starving. With the patch,
> > voltage oscillates between 700000-737000 microvolts in idle and jumps
> > up to 950000 under load, and the system seems stable.
> >
> > Here's what I used to monitor the voltage (there must be a better way
> > to do it, but it works):
> > sige5 ~ # watch cat `grep -r . /sys/class/regulator/*/name | grep
> > vdd_cpu_big_s0 | sed -e 's/name.*//'`/microvolts
> >
> > And in another terminal:
> > sige5 ~ # stress-ng -c8
>
> 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.

Big thing to note here is that on Rockchip the kernel does not really
set the CPU frequency directly. It only issues an SCMI request to the
ATF firmware with the desired target frequency and provides sufficient
voltage via the supply regulator as defined by the respective OPP.

What the ATF firmware (running on a dedicated MCU completely separate
from the OS) then does is it takes the desired target frequency,
matches it to a loop length for the PVTPLL block via an internal
lookup table, and PVTPLL then determines the stable frequency that
this particular chip specimen can run at with the provided loop length
and voltage. This frequency then gets applied to the hardware via the
CRU - and as you can imagine, it can well differ from what the kernel
was requesting via SCMI.

> Requested is [1]
> Running is [2]
> Measured is [3]
>
> random read 1:
> Requested CPU4: 408 MHz
> Requested CPU0: 408 MHz
> Running CPU4: 1800 MHz
> Running CPU0: 1416 MHz
> Measured on HW: 1579.03 MHz

Hmm, have you tried pinning a particular frequency on each of the
clusters, so that the governor doesn't change it while you are going
from the point where you read the "requested" frequency to "running"
and "measured"? Also I think it would be a good idea to "taskset" the
measuring thread to particular CPU cores - otherwise I'm not sure what
it shows when the scheduler can bounce the process between cores as it
pleases it.

> random read 2:
> Requested CPU4: 1608 MHz
> Requested CPU0: 408 MHz
> Running CPU4: 2016 MHz
> Running CPU0: 1800 MHz
> Measured on HW: 410.33 MHz
>
> random read 3:
> Requested CPU4: 600 MHz
> Requested CPU0: 1800 MHz
> Running CPU4: 816 MHz
> Running CPU0: 1008 MHz
> Measured on HW: 2275.07 MHz
>
> random read 4:
> Requested CPU4: 1608 MHz
> Requested CPU0: 1200 MHz
> Running CPU4: 816 MHz
> Running CPU0: 816 MHz
> Measured on HW: 2114.58 MHz
>
> this is on rk3576
> on i.e allwinner h618 or rk3588 all looks quite normal - [1] and [2] are equal...

Are these taken on the mainline kernel or Rockchip one? Binary BL31
from Rockchip or opensource TF-A? With big-core CPUs linked up to
their supply regulator (as per this patch) or without?

Can't see why the behavior would differ vs. RK3588 though, unless
there are some bugs somewhere.

Best regards,
Alexey