linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Quentin Schulz <quentin.schulz@cherry.de>
To: "Alexey Charkov" <alchark@gmail.com>, "Heiko Stübner" <heiko@sntech.de>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	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: Wed, 12 Mar 2025 11:15:42 +0100	[thread overview]
Message-ID: <e55125ed-64fb-455e-b1e4-cebe2cf006e4@cherry.de> (raw)
In-Reply-To: <CABjd4YxF4N1tAgGUZk-oKkMUO+Q9rWHZsas9gMQdJ+TF4A1=NA@mail.gmail.com>

Hi all,

On 2/16/25 1:32 PM, Alexey Charkov wrote:
> Hi Heiko,
> 
> On Sat, Feb 15, 2025 at 11:30 PM Heiko Stübner <heiko@sntech.de> wrote:
>>
>> Am Samstag, 15. Februar 2025, 19:59:44 MEZ schrieb Alexey Charkov:
>>> On Tue, Feb 11, 2025 at 7:32 PM Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>>> On 6/17/24 8:28 PM, Alexey Charkov wrote:
[...]
>>>>> +     };
>>>>> +
>>>>> +     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?
>>>
>>> I believe the opp core just marks 'turbo-mode' opps as
>>> CPUFREQ_BOOST_FREQ, and cpufreq-dt only passes that flag along to the
>>> cpufreq core. But then to actually use those boost frequencies I would
>>> guess the governor needs to somehow know the power/thermal constraints
>>> of the chip?.. Don't know where that is defined.
>>
>> personally I don't believe in "boost" frequencies - except when they are
>> declared officially.
>>
>> Rockchip for the longest time maintains that running the chip outside
>> the declared power/rate envelope can reduce its overall lifetime.
>>
>> So for Rockchip in mainline a "it runs stable for me" has never been a
>> suitable reasoning ;-) .
> 
> My key concern here was perhaps that we are looking at a file inside
> the Rockchip source tree which looks relevant by the name of it, but
> doesn't actually get included anywhere for any of the boards. This may
> or may not constitute an endorsement by Rockchip of any OPPs listed
> there :-D
> 

Rockchip support stated:

"""
If you run overdrive mode, you do not need to include rk3588j.dtsi, and 
you can change it to #incldue rk3588.dtsi to ensure that the maximum 
frequency can reach 2GHz

below picture from datasheet.
"""

The picture is the table 3-2 Recommended operating conditions, page 30 
from the RK3588J datasheet, e.g. 
https://www.lcsc.com/datasheet/lcsc_datasheet_2403201054_Rockchip-RK3588J_C22364189.pdf

What is overdrive?

"""
Overdrive mode brings higher frequency, and the voltage will increase 
accordingly. Under
the overdrive mode for a long time, the chipset may shorten the 
lifetime, especially in
high temperature condition
"""

according to the same datasheet, end of the same table, page 31.

so this seems like a turbo-mode frequency to me.

Additionally, the note for the "normal mode" (the one with the lower 
freqs) states:

"""
Normal mode means the chipset works under safety voltage and frequency. 
For the
industrial environment, highly recommend to keep in normal mode, the 
lifetime is
reasonably guaranteed.
"""

I believe "industrial environment" means RK3588J used in the 
temperatures that aren't OK for the standard RK3588 variant?

> I haven't seen a TRM for the J variant, nor do I have a board with
> RK3588J to run tests, so it would be great if Kever could chime in
> with how these OPPs are different from the others (or not).
> 
>> So while the situation might be strange for the rk3588j, I really only want
>> correct frequencies here please - not any pseudo "turbo freqs".
>>
>> I don't care that much what people do on their own device{s/trees}, but
>> the devicetrees we supply centrally (and to u-boot, etc) should only
>> contain frequencies vetted by the manufacturer.
> 
> Fair enough. Let's just try and get another data point on whether
> these frequencies are vetted or not.
> 

So the higher freqs seems to be vetted (and used by default on 
Rockchip's BSP kernel), it just feels like you aren't really supposed to 
run those higher frequencies all the time? And especially not in 
"industrial environment"?

I would assume we want to stay on the safer side and remove those higher 
frequencies? Heiko?

Cheers,
Quentin


  parent reply	other threads:[~2025-03-12 10:19 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
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 [this message]
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=e55125ed-64fb-455e-b1e4-cebe2cf006e4@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;
as well as URLs for NNTP newsgroup(s).