From: Willy Tarreau <w@1wt.eu>
To: Chukun Pan <amadeus@jmu.edu.cn>
Cc: alchark@gmail.com, conor+dt@kernel.org,
devicetree@vger.kernel.org, heiko@sntech.de, jonas@kwiboo.se,
krzk+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
ziyao@disroot.org
Subject: Re: [PATCH v2 1/1] arm64: dts: rockchip: rk3528: Add CPU frequency scaling support
Date: Wed, 30 Jul 2025 09:11:45 +0200 [thread overview]
Message-ID: <20250730071145.GA26734@1wt.eu> (raw)
In-Reply-To: <20250730070026.60109-1-amadeus@jmu.edu.cn>
Hi!
On Wed, Jul 30, 2025 at 03:00:26PM +0800, Chukun Pan wrote:
> Hi,
>
> > It's interesting to note that 816, 1008 and 1200 MHz result in a higher
> > frequency than configured, but upper ones result in slightly smaller
> > frequencies (~2%, might just be a measurement error), particularly for
> > the last one which is 6% lower.
>
> Please refer to the description of this series:
> https://lore.kernel.org/lkml/20250320100002.332720-1-amadeus@jmu.edu.cn/
Yes I had read this one. I'm just getting higher differences on my
device here.
> During the discussion, it was considered that the minimum voltage should
> be 875mV to maintain stability, so there is a deviation in the frequency
> between 816MHz and 1200MHz.
I tend to agree, especially on low voltages, where the gain in stability
is important while the difference in consumptionis barely noticeable.
> > I noticed a missing entry for 2 GHz in clk-rk3528.c so I've added it,
> > expecting that it would solve the problem:
> >
> > + RK3036_PLL_RATE(2016000000, 1, 84, 1, 1, 1, 0),
> >
> > But it had no effect at all, the frequency remains limited to 1896 MHz.
>
> There is a comment in the bsp kernel:
> https://github.com/rockchip-linux/kernel/blob/develop-5.10/drivers/clk/rockchip/clk-rk3528.c#L101
>
> Only 408MHz and 600MHz are generated by normal PLL, the rest of the
> CPU frequency is controlled by TF-A via SCMI.
OK!
> > Or maybe we could simply raise the voltage a little bit. The table above
> > shows that at 1.15V we're close to the configured OPP and still below the
> > stock voltage. This is not critical, but I find it a bit annoying that
> > enabling cpufreq results in lower performance than without!
>
> I also mentioned this in the cover letter. The actual frequency of 2016MHz
> requires 1.13V ~ 1.15V. Not sure if this is safe for the rk3528 SoC.
My point is that if you disable cpufreq, the CPU is running at 1.2V, which
is even higher. I don't know why it's running at this voltage, maybe as
the result of initializing some regulators, but that's what we're getting.
So the question about safety of running between 1.13-1.15 resolves to
"it's at least safer than running without cpufreq" in the current state.
And as I mentioned it's clearly linux and not u-boot that is setting 1.2V,
because under u-boot and during kernel selection and image loading, my
board is at 0.95V. It's only once the kernel starts to boot that it bumps
to 1.2V.
So there's something to fix somewhere, either by lowering the default
setting or by increasing the voltages in OPP, but as it is right now the
situation is inconsistent.
Regards,
Willy
next prev parent reply other threads:[~2025-07-30 7:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-20 10:00 [PATCH v2 0/1] arm64: dts: rockchip: rk3528: Add CPU frequency scaling support Chukun Pan
2025-06-20 10:00 ` [PATCH v2 1/1] " Chukun Pan
2025-07-10 11:45 ` Heiko Stuebner
2025-07-10 12:11 ` Jonas Karlman
2025-07-10 15:59 ` Alexey Charkov
2025-07-16 14:30 ` Chukun Pan
2025-07-16 15:48 ` Alexey Charkov
2025-07-17 7:00 ` Chukun Pan
2025-07-17 8:46 ` Alexey Charkov
2025-07-18 14:01 ` Chukun Pan
2025-07-18 15:03 ` Alexey Charkov
2025-07-20 14:00 ` Chukun Pan
2025-07-27 17:09 ` Willy Tarreau
2025-07-30 7:00 ` Chukun Pan
2025-07-30 7:11 ` Willy Tarreau [this message]
2025-07-30 13:20 ` Chukun Pan
2025-07-30 13:33 ` Willy Tarreau
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=20250730071145.GA26734@1wt.eu \
--to=w@1wt.eu \
--cc=alchark@gmail.com \
--cc=amadeus@jmu.edu.cn \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=ziyao@disroot.org \
/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;
as well as URLs for NNTP newsgroup(s).