All of lore.kernel.org
 help / color / mirror / Atom feed
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 15:33:43 +0200	[thread overview]
Message-ID: <20250730133343.GC26787@1wt.eu> (raw)
In-Reply-To: <20250730132026.214754-1-amadeus@jmu.edu.cn>

Hi,

On Wed, Jul 30, 2025 at 09:20:26PM +0800, Chukun Pan wrote:
> Hi,
> 
> > 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.
> 
> If opp-table is not configured, kernel will initialize the pwm-regulator
> to maximum microvolts. This can be solved by configuring the pwm-regulator
> in U-Boot (waiting for U-Boot to synchronize the DT of kernel 6.16):
> 
> ```
> &vdd_arm {
> 	regulator-init-microvolt = <953000>;
> };

OK thanks for the explanation, but will be stable at highest frequency, or
do we expect the TF-A or PVTM mechanism to automatically reduce the
frequency enough to keep everything stable ? I'm asking because right now
I'm booting at 2 GHz, and I don't imagine 2 GHz to work fine at 953mV.

Also, if we'd set this to a low enough voltage that it results in throttling
the CPU, it could significantly slow down the boot for no reason. If we
consider that the configured max-microvolt is valid, then better continue
to use it. And if it's not valid, then maybe just fix it without going
full throttle to a lower value either. Just my two cents.

Willy


WARNING: multiple messages have this Message-ID (diff)
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 15:33:43 +0200	[thread overview]
Message-ID: <20250730133343.GC26787@1wt.eu> (raw)
In-Reply-To: <20250730132026.214754-1-amadeus@jmu.edu.cn>

Hi,

On Wed, Jul 30, 2025 at 09:20:26PM +0800, Chukun Pan wrote:
> Hi,
> 
> > 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.
> 
> If opp-table is not configured, kernel will initialize the pwm-regulator
> to maximum microvolts. This can be solved by configuring the pwm-regulator
> in U-Boot (waiting for U-Boot to synchronize the DT of kernel 6.16):
> 
> ```
> &vdd_arm {
> 	regulator-init-microvolt = <953000>;
> };

OK thanks for the explanation, but will be stable at highest frequency, or
do we expect the TF-A or PVTM mechanism to automatically reduce the
frequency enough to keep everything stable ? I'm asking because right now
I'm booting at 2 GHz, and I don't imagine 2 GHz to work fine at 953mV.

Also, if we'd set this to a low enough voltage that it results in throttling
the CPU, it could significantly slow down the boot for no reason. If we
consider that the configured max-microvolt is valid, then better continue
to use it. And if it's not valid, then maybe just fix it without going
full throttle to a lower value either. Just my two cents.

Willy

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-07-30 13:36 UTC|newest]

Thread overview: 34+ 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 ` Chukun Pan
2025-06-20 10:00 ` [PATCH v2 1/1] " Chukun Pan
2025-06-20 10:00   ` Chukun Pan
2025-07-10 11:45   ` Heiko Stuebner
2025-07-10 11:45     ` Heiko Stuebner
2025-07-10 12:11     ` Jonas Karlman
2025-07-10 12:11       ` Jonas Karlman
2025-07-10 15:59       ` Alexey Charkov
2025-07-10 15:59         ` Alexey Charkov
2025-07-16 14:30         ` Chukun Pan
2025-07-16 14:30           ` Chukun Pan
2025-07-16 15:48           ` Alexey Charkov
2025-07-16 15:48             ` Alexey Charkov
2025-07-17  7:00       ` Chukun Pan
2025-07-17  7:00         ` Chukun Pan
2025-07-17  8:46         ` Alexey Charkov
2025-07-17  8:46           ` Alexey Charkov
2025-07-18 14:01           ` Chukun Pan
2025-07-18 14:01             ` Chukun Pan
2025-07-18 15:03             ` Alexey Charkov
2025-07-18 15:03               ` Alexey Charkov
2025-07-20 14:00               ` Chukun Pan
2025-07-20 14:00                 ` Chukun Pan
2025-07-27 17:09                 ` Willy Tarreau
2025-07-27 17:09                   ` Willy Tarreau
2025-07-30  7:00                   ` Chukun Pan
2025-07-30  7:00                     ` Chukun Pan
2025-07-30  7:11                     ` Willy Tarreau
2025-07-30  7:11                       ` Willy Tarreau
2025-07-30 13:20                       ` Chukun Pan
2025-07-30 13:20                         ` Chukun Pan
2025-07-30 13:33                         ` Willy Tarreau [this message]
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=20250730133343.GC26787@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.