From: Dragan Simic <dsimic@manjaro.org>
To: Quentin Schulz <quentin.schulz@cherry.de>
Cc: "Alexey Charkov" <alchark@gmail.com>,
"Heiko Stübner" <heiko@sntech.de>,
"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>,
"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:34:21 +0100 [thread overview]
Message-ID: <a56b59a21dc3c21192fe45197eee4865@manjaro.org> (raw)
In-Reply-To: <e55125ed-64fb-455e-b1e4-cebe2cf006e4@cherry.de>
Hello Quentin,
On 2025-03-12 11:15, Quentin Schulz wrote:
> On 2/16/25 1:32 PM, Alexey Charkov wrote:
>> 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?
Thanks a lot for obtaining these clarifications!
Yes, I'd say that in this case "industrial environment" boils down
to the extended temperature range for the RK3588J 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?
I agree, we should remove the higher-frequency OPPs. I'd like
to go through everything once again in detail and prepare a patch
that removes the unsafe OPPs, and you could review it once it's
on the ML, to make sure it's fine.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-03-12 10:36 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
2025-03-12 10:34 ` Dragan Simic [this message]
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=a56b59a21dc3c21192fe45197eee4865@manjaro.org \
--to=dsimic@manjaro.org \
--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=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=quentin.schulz@cherry.de \
--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