From: Quentin Schulz <quentin.schulz@cherry.de>
To: Alexey Charkov <alchark@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Dragan Simic <dsimic@manjaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Chen-Yu Tsai <wens@kernel.org>,
Diederik de Haas <didi.debian@cknow.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
Kever Yang <kever.yang@rock-chips.com>
Subject: Re: [PATCH v5 7/8] arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j
Date: Tue, 11 Feb 2025 17:32:42 +0100 [thread overview]
Message-ID: <d8ce8db2-1717-40f8-b53e-24cc71a758c9@cherry.de> (raw)
In-Reply-To: <20240617-rk-dts-additions-v5-7-c1f5f3267f1e@gmail.com>
Hi all,
On 6/17/24 8:28 PM, Alexey Charkov wrote:
> RK3588j is the 'industrial' variant of RK3588, and it uses a different
> set of OPPs both in terms of allowed frequencies and in terms of
> applicable voltages at each frequency setpoint.
>
> Add the OPPs that apply to RK3588j (and apparently RK3588m too) to
> enable dynamic CPU frequency scaling.
>
> OPP values are derived from Rockchip downstream sources [1] by taking
> only those OPPs which have the highest frequency for a given voltage
> level and dropping the rest (if they are included, the kernel complains
> at boot time about them being inefficient)
>
> [1] https://github.com/rockchip-linux/kernel/blob/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
>
Funny stuff actually. Rockchip have their own downstream cpufreq driver
which autodetects at runtime the SoC variant and filter out OPPs based
on that info. And this patch is based on those values and filters.
However, they also decided that maybe this isn't the best way to do it
and they decided to have an rk3588j.dtsi where they remove some of those
OPPs instead of just updating the mask/filter in their base dtsi
(rk3588s.dtsi downstream). See
https://github.com/rockchip-linux/kernel/blob/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
So...
> Signed-off-by: Alexey Charkov <alchark@gmail.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3588j.dtsi | 108 ++++++++++++++++++++++++++++++
> 1 file changed, 108 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
> index 0bbeee399a63..b7e69553857b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
> @@ -5,3 +5,111 @@
> */
>
> #include "rk3588-extra.dtsi"
> +
> +/ {
> + cluster0_opp_table: opp-table-cluster0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-1416000000 {
> + opp-hz = /bits/ 64 <1416000000>;
> + opp-microvolt = <750000 750000 950000>;
> + clock-latency-ns = <40000>;
> + opp-suspend;
> + };
> + opp-1608000000 {
> + opp-hz = /bits/ 64 <1608000000>;
> + opp-microvolt = <887500 887500 950000>;
> + clock-latency-ns = <40000>;
> + };
> + opp-1704000000 {
> + opp-hz = /bits/ 64 <1704000000>;
> + opp-microvolt = <937500 937500 950000>;
> + clock-latency-ns = <40000>;
> + };
None of those are valid according to Rockchip, we should have
opp-1296000000 {
opp-hz = /bits/ 64 <1296000000>;
opp-microvolt = <750000 750000 950000>;
clock-latency-ns = <40000>;
opp-suspend;
};
instead?
and...
> + };
> +
> + cluster1_opp_table: opp-table-cluster1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-1416000000 {
> + opp-hz = /bits/ 64 <1416000000>;
> + opp-microvolt = <750000 750000 950000>;
> + clock-latency-ns = <40000>;
> + };
> + opp-1608000000 {
> + opp-hz = /bits/ 64 <1608000000>;
> + opp-microvolt = <787500 787500 950000>;
> + clock-latency-ns = <40000>;
> + };
> + opp-1800000000 {
> + opp-hz = /bits/ 64 <1800000000>;
> + opp-microvolt = <875000 875000 950000>;
> + clock-latency-ns = <40000>;
> + };
> + opp-2016000000 {
> + opp-hz = /bits/ 64 <2016000000>;
> + opp-microvolt = <950000 950000 950000>;
> + clock-latency-ns = <40000>;
> + };
opp-1800000000 and opp-2016000000 should be removed.
and...
> + };
> +
> + cluster2_opp_table: opp-table-cluster2 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-1416000000 {
> + opp-hz = /bits/ 64 <1416000000>;
> + opp-microvolt = <750000 750000 950000>;
> + clock-latency-ns = <40000>;
> + };
> + opp-1608000000 {
> + opp-hz = /bits/ 64 <1608000000>;
> + opp-microvolt = <787500 787500 950000>;
> + clock-latency-ns = <40000>;
> + };
> + opp-1800000000 {
> + opp-hz = /bits/ 64 <1800000000>;
> + opp-microvolt = <875000 875000 950000>;
> + clock-latency-ns = <40000>;
> + };
> + opp-2016000000 {
> + opp-hz = /bits/ 64 <2016000000>;
> + opp-microvolt = <950000 950000 950000>;
> + clock-latency-ns = <40000>;
> + };
opp-1800000000 and opp-2016000000 should be removed as well.
Did I misunderstand what Rockchip did here? Adding Kever in Cc at least
for awareness on Rockchip side :)
I guess another option could be to mark those above as
turbo-mode;
though no clue what this would entail. From a glance at cpufreq, it
seems that for Rockchip since we use the default cpufreq-dt, it would
mark those as unusable, so essentially a no-op, so better remove them
entirely?
Cheers,
Quentin
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-02-11 17:56 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 18:28 [PATCH v5 0/8] RK3588 and Rock 5B dts additions: thermal, OPP and fan Alexey Charkov
2024-06-17 18:28 ` [PATCH v5 1/8] arm64: dts: rockchip: add thermal zones information on RK3588 Alexey Charkov
2024-06-17 18:28 ` [PATCH v5 2/8] arm64: dts: rockchip: enable thermal management on all RK3588 boards Alexey Charkov
2024-06-17 18:28 ` [PATCH v5 3/8] arm64: dts: rockchip: add passive GPU cooling on RK3588 Alexey Charkov
2024-06-17 18:28 ` [PATCH v5 4/8] arm64: dts: rockchip: enable automatic fan control on Rock 5B Alexey Charkov
2024-06-17 18:28 ` [PATCH v5 5/8] arm64: dts: rockchip: Add CPU/memory regulator coupling for RK3588 Alexey Charkov
2024-06-17 18:28 ` [PATCH v5 6/8] arm64: dts: rockchip: Add OPP data for CPU cores on RK3588 Alexey Charkov
2024-06-17 18:28 ` [PATCH v5 7/8] arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j Alexey Charkov
2025-02-11 16:32 ` Quentin Schulz [this message]
2025-02-15 18:59 ` Alexey Charkov
2025-02-15 20:30 ` Heiko Stübner
2025-02-15 21:26 ` Dragan Simic
2025-02-16 12:32 ` Alexey Charkov
2025-02-17 16:24 ` Quentin Schulz
2025-03-12 10:15 ` Quentin Schulz
2025-03-12 10:34 ` Dragan Simic
2025-03-13 10:42 ` Dragan Simic
2025-03-13 19:00 ` Heiko Stuebner
2025-03-13 19:43 ` Dragan Simic
2025-03-21 3:37 ` Dragan Simic
2024-06-17 18:28 ` [PATCH v5 8/8] arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j Alexey Charkov
2025-02-11 16:34 ` Quentin Schulz
2024-06-17 18:56 ` [PATCH v5 0/8] RK3588 and Rock 5B dts additions: thermal, OPP and fan Dragan Simic
2024-06-20 20:39 ` (subset) " Heiko Stuebner
2024-06-21 6:15 ` Alexey Charkov
2024-06-24 16:20 ` Heiko Stuebner
2024-07-07 9:39 ` Piotr Oniszczuk
2024-07-07 11:11 ` Heiko Stübner
2024-07-07 12:37 ` Piotr Oniszczuk
2024-07-07 18:32 ` Piotr Oniszczuk
2024-07-08 7:59 ` Alexey Charkov
2024-07-08 10:29 ` Piotr Oniszczuk
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=d8ce8db2-1717-40f8-b53e-24cc71a758c9@cherry.de \
--to=quentin.schulz@cherry.de \
--cc=alchark@gmail.com \
--cc=conor+dt@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=didi.debian@cknow.org \
--cc=dsimic@manjaro.org \
--cc=heiko@sntech.de \
--cc=kever.yang@rock-chips.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh+dt@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=wens@kernel.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