diff mbox series

arm64: dts: rockchip: Remove overdrive-mode OPPs from RK3588J SoC dtsi

Message ID f929da061de35925ea591c969f985430e23c4a7e.1742526811.git.dsimic@manjaro.org (mailing list archive)
State New
Headers show
Series arm64: dts: rockchip: Remove overdrive-mode OPPs from RK3588J SoC dtsi | expand

Commit Message

Dragan Simic March 21, 2025, 3:28 a.m. UTC
The differences in the vendor-approved CPU and GPU OPPs for the standard
Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J variant [2]
come from the latter, presumably, supporting an extended temperature range
that's usually associated with industrial applications, despite the two SoC
variant datasheets specifying the same upper limit for the allowed ambient
temperature for both variants.  However, the lower temperature limit is
specified much lower for the RK3588J variant. [1][2]

To be on the safe side and to ensure maximum longevity of the RK3588J SoCs,
only the CPU and GPU OPPs that are declared by the vendor to be always safe
for this SoC variant may be provided.  As explained by the vendor [3] and
according to its datasheet, [2] the RK3588J variant can actually run safely
at higher CPU and GPU OPPs as well, but only when not enjoying the assumed
extended temperature range that the RK3588J, as an SoC variant targeted
specifically at industrial applications, is made (or binned) for.

Thus, only the CPU and GPU OPPs that are specified by the vendor to be safe
throughout the entire RK3588J's extended temperature range may be provided,
while anyone who actually can ensure that their RK3588J-based board is
never going to run within the extended temperature range, may probably
safely apply a DT overlay that adds the higher CPU and GPU OPPs.  As we
obviously can't know what will be the runtime temperature conditions for
a particular board, we may provide only the always-safe OPPs.

With all this and the downstream RK3588(J) DT definitions [4][5] in mind,
let's delete the RK3588J CPU and GPU OPPs that are not considered belonging
to the normal operation mode for this SoC variant.  To quote the RK3588J
datasheet [2], "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", while "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".

To sum up the RK3588J datasheet [2] and the vendor-provided DTs, [4][5]
the maximum allowed CPU core and GPU frequencies are as follows:

   IP core    | Normal mode | Overdrive mode
  ------------+-------------+----------------
   Cortex-A55 |   1,296 MHz |      1,704 MHz
   Cortex-A76 |   1,608 MHz |      2,016 MHz
   GPU        |     700 MHz |        850 MHz

Unfortunately, when it comes to the actual voltages for the RK3588J CPU and
GPU OPPs, there's a discrepancy between the RK3588J datasheet [2] and the
downstream kernel code. [4][5]  The RK3588J datasheet states that "the max.
working voltage of CPU/GPU/NPU is 0.75 V under the normal mode", while the
downstream kernel code actually allows voltage ranges that go up to 0.95 V,
which is still within the voltage range allowed by the datasheet.  However,
the RK3588J datasheet also tells us to "strictly refer to the software
configuration of SDK and the hardware reference design", so let's embrace
the voltage ranges provided by the downstream kernel code, which also
prevents the undesirable theoretical outcome of ending up with no usable
OPPs on a particular board, as a result of the board's voltage regulator(s)
being unable to deliver the exact voltages, for whatever reason.

The above-described voltage ranges for the RK3588J CPU OPPs remain taken
from the downstream kernel code [4][5] by picking the highest, worst-bin
values, which ensure that all RK3588J bins will work reliably.  Yes, with
some power inevitably wasted as unnecessarily generated heat, but the
reliability is paramount, together with the longevity.  This deficiency
may be revisited separately at some point in the future.

The provided RK3588J CPU OPPs follow the slightly debatable "provide only
the highest-frequency OPP from the same-voltage group" approach that's been
established earlier, [6] as a result of the "same-voltage, lower-frequency"
OPPs being considered inefficient from the IPA governor's standpoint, which
may also be revisited separately at some point in the future.

[1] https://wiki.friendlyelec.com/wiki/images/e/ee/Rockchip_RK3588_Datasheet_V1.6-20231016.pdf
[2] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2403201054_Rockchip-RK3588J_C22364189.pdf
[3] https://lore.kernel.org/linux-rockchip/e55125ed-64fb-455e-b1e4-cebe2cf006e4@cherry.de/T/#u
[4] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
[5] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
[6] https://lore.kernel.org/all/20240229-rk-dts-additions-v3-5-6afe8473a631@gmail.com/

Fixes: 667885a68658 ("arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j")
Fixes: a7b2070505a2 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j")
Cc: stable@vger.kernel.org
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Alexey Charkov <alchark@gmail.com>
Helped-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
---
 arch/arm64/boot/dts/rockchip/rk3588j.dtsi | 53 ++++++++---------------
 1 file changed, 17 insertions(+), 36 deletions(-)

Comments

Quentin Schulz March 21, 2025, 9:53 a.m. UTC | #1
Hi Dragan,

On 3/21/25 4:28 AM, Dragan Simic wrote:
> The differences in the vendor-approved CPU and GPU OPPs for the standard
> Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J variant [2]
> come from the latter, presumably, supporting an extended temperature range
> that's usually associated with industrial applications, despite the two SoC
> variant datasheets specifying the same upper limit for the allowed ambient
> temperature for both variants.  However, the lower temperature limit is

RK3588 is rated for 0-80°C, RK3588J for -40-85°C, c.f. Recommended 
Operating Conditions, Table 3-2, Ambient Operating Temperature.

> specified much lower for the RK3588J variant. [1][2]
> 
> To be on the safe side and to ensure maximum longevity of the RK3588J SoCs,
> only the CPU and GPU OPPs that are declared by the vendor to be always safe
> for this SoC variant may be provided.  As explained by the vendor [3] and
> according to its datasheet, [2] the RK3588J variant can actually run safely
> at higher CPU and GPU OPPs as well, but only when not enjoying the assumed
> extended temperature range that the RK3588J, as an SoC variant targeted

"only when not enjoying the assumed extended temperature range" is 
extrapolated by me/us and not confirmed by Rockchip themselves. I've 
asked for a statement on what "industrial environment" they specify in 
the Normal Mode explanation means since it's the only time they use the 
term. I've yet to receive an answer. The only thing Rockchip in their 
datasheet is that the overdrive mode will shorten lifetime when used for 
a long time, especially in high temperature conditions. It's not clear 
whether we can use the overdrive mode even within the RK3588 typical 
range of operation.

> specifically at industrial applications, is made (or binned) for.
> 
> Thus, only the CPU and GPU OPPs that are specified by the vendor to be safe
> throughout the entire RK3588J's extended temperature range may be provided,
> while anyone who actually can ensure that their RK3588J-based board is
> never going to run within the extended temperature range, may probably
> safely apply a DT overlay that adds the higher CPU and GPU OPPs.  As we

Wouldn't say "safely" here, Rockchip still says that running overdrive 
mode for a long time may shorten lifetime... that followed by 
"especially in high temperature condition" doesn't mean that operating 
the RK3588J within the RK3588 typical range is safe to do.

> obviously can't know what will be the runtime temperature conditions for
> a particular board, we may provide only the always-safe OPPs.
> 
> With all this and the downstream RK3588(J) DT definitions [4][5] in mind,
> let's delete the RK3588J CPU and GPU OPPs that are not considered belonging
> to the normal operation mode for this SoC variant.  To quote the RK3588J
> datasheet [2], "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", while "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".
> 
> To sum up the RK3588J datasheet [2] and the vendor-provided DTs, [4][5]
> the maximum allowed CPU core and GPU frequencies are as follows:
> 
>     IP core    | Normal mode | Overdrive mode
>    ------------+-------------+----------------
>     Cortex-A55 |   1,296 MHz |      1,704 MHz
>     Cortex-A76 |   1,608 MHz |      2,016 MHz
>     GPU        |     700 MHz |        850 MHz
> 

The NPU too is impacted by this, so maybe list it anyway here? Even if 
we don't support it right now and don't have OPPs for it.

> Unfortunately, when it comes to the actual voltages for the RK3588J CPU and
> GPU OPPs, there's a discrepancy between the RK3588J datasheet [2] and the
> downstream kernel code. [4][5]  The RK3588J datasheet states that "the max.
> working voltage of CPU/GPU/NPU is 0.75 V under the normal mode", while the
> downstream kernel code actually allows voltage ranges that go up to 0.95 V,
> which is still within the voltage range allowed by the datasheet.  However,
> the RK3588J datasheet also tells us to "strictly refer to the software
> configuration of SDK and the hardware reference design", so let's embrace
> the voltage ranges provided by the downstream kernel code, which also
> prevents the undesirable theoretical outcome of ending up with no usable
> OPPs on a particular board, as a result of the board's voltage regulator(s)
> being unable to deliver the exact voltages, for whatever reason.
> 
> The above-described voltage ranges for the RK3588J CPU OPPs remain taken
> from the downstream kernel code [4][5] by picking the highest, worst-bin
> values, which ensure that all RK3588J bins will work reliably.  Yes, with
> some power inevitably wasted as unnecessarily generated heat, but the
> reliability is paramount, together with the longevity.  This deficiency
> may be revisited separately at some point in the future.
> 
> The provided RK3588J CPU OPPs follow the slightly debatable "provide only
> the highest-frequency OPP from the same-voltage group" approach that's been

Interesting that we went for a different strategy for the GPU OPPs :)

> established earlier, [6] as a result of the "same-voltage, lower-frequency"
> OPPs being considered inefficient from the IPA governor's standpoint, which
> may also be revisited separately at some point in the future.
> 
> [1] https://wiki.friendlyelec.com/wiki/images/e/ee/Rockchip_RK3588_Datasheet_V1.6-20231016.pdf
> [2] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2403201054_Rockchip-RK3588J_C22364189.pdf
> [3] https://lore.kernel.org/linux-rockchip/e55125ed-64fb-455e-b1e4-cebe2cf006e4@cherry.de/T/#u
> [4] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> [5] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
> [6] https://lore.kernel.org/all/20240229-rk-dts-additions-v3-5-6afe8473a631@gmail.com/
> 
> Fixes: 667885a68658 ("arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j")
> Fixes: a7b2070505a2 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j")
> Cc: stable@vger.kernel.org
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Alexey Charkov <alchark@gmail.com>
> Helped-by: Quentin Schulz <quentin.schulz@cherry.de>

Reported-by/Suggested-by?

I don't see Helped-by in 
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes

I see 2496b2aaacf137250f4ca449f465e2cadaabb0e8 got the Helped-by 
replaced by a Suggested-by for example, but I see other patches with 
Helped-by... if that is a standard trailer for kernel patches, then 
maybe we should add it to that doc?

> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
> ---
>   arch/arm64/boot/dts/rockchip/rk3588j.dtsi | 53 ++++++++---------------
>   1 file changed, 17 insertions(+), 36 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
> index bce72bac4503..3045cb3bd68c 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
> @@ -11,74 +11,59 @@ cluster0_opp_table: opp-table-cluster0 {
>   		compatible = "operating-points-v2";
>   		opp-shared;
>   
> -		opp-1416000000 {
> -			opp-hz = /bits/ 64 <1416000000>;
> +		opp-1200000000 {
> +			opp-hz = /bits/ 64 <1200000000>;
>   			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>;
> +		opp-1296000000 {
> +			opp-hz = /bits/ 64 <1296000000>;
> +			opp-microvolt = <775000 775000 950000>;

Got tricked by this one.

In the Rockchip vendor kernel, the opp-microvolt is 750000 750000 
950000, so the same as CPU OPP 1.2GHz. However, the opp-microvolt-L1 and 
L0 are higher than that. Only a couple of the OPPs in vendor kernel 
actually have opp-microvolt-L* higher than opp-microvolt, that is a 
noteworthy oddity for anyone reviewing this patch :)

Anyway, that is correct, we take the highest voltage among all defined 
opp-microvolt* properties.

I only have comments on the commit log, the diff is fine so:

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin
Dragan Simic March 23, 2025, 10:19 a.m. UTC | #2
Hello Quentin,

Thanks for your comments!  Please see some responses below.

On 2025-03-21 10:53, Quentin Schulz wrote:
> On 3/21/25 4:28 AM, Dragan Simic wrote:
>> The differences in the vendor-approved CPU and GPU OPPs for the 
>> standard
>> Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J 
>> variant [2]
>> come from the latter, presumably, supporting an extended temperature 
>> range
>> that's usually associated with industrial applications, despite the 
>> two SoC
>> variant datasheets specifying the same upper limit for the allowed 
>> ambient
>> temperature for both variants.  However, the lower temperature limit 
>> is
> 
> RK3588 is rated for 0-80°C, RK3588J for -40-85°C, c.f. Recommended
> Operating Conditions, Table 3-2, Ambient Operating Temperature.

Indeed, which is why I specifically wrote "specifying the same upper
limit", because having a lower negative temperature limit could hardly
put the RK3588J in danger of overheating or running hotter. :)

>> specified much lower for the RK3588J variant. [1][2]
>> 
>> To be on the safe side and to ensure maximum longevity of the RK3588J 
>> SoCs,
>> only the CPU and GPU OPPs that are declared by the vendor to be always 
>> safe
>> for this SoC variant may be provided.  As explained by the vendor [3] 
>> and
>> according to its datasheet, [2] the RK3588J variant can actually run 
>> safely
>> at higher CPU and GPU OPPs as well, but only when not enjoying the 
>> assumed
>> extended temperature range that the RK3588J, as an SoC variant 
>> targeted
> 
> "only when not enjoying the assumed extended temperature range" is
> extrapolated by me/us and not confirmed by Rockchip themselves. I've
> asked for a statement on what "industrial environment" they specify in
> the Normal Mode explanation means since it's the only time they use
> the term. I've yet to receive an answer. The only thing Rockchip in
> their datasheet is that the overdrive mode will shorten lifetime when
> used for a long time, especially in high temperature conditions. It's
> not clear whether we can use the overdrive mode even within the RK3588
> typical range of operation.

True.  I'll see to rephrase the patch description a bit in the v2,
to avoid this kind of speculation.  I mean, perhaps the speculation
is right, but it hasn't been confirmed officially by Rockchip.

>> specifically at industrial applications, is made (or binned) for.
>> 
>> Thus, only the CPU and GPU OPPs that are specified by the vendor to be 
>> safe
>> throughout the entire RK3588J's extended temperature range may be 
>> provided,
>> while anyone who actually can ensure that their RK3588J-based board is
>> never going to run within the extended temperature range, may probably
>> safely apply a DT overlay that adds the higher CPU and GPU OPPs.  As 
>> we
> 
> Wouldn't say "safely" here, Rockchip still says that running overdrive
> mode for a long time may shorten lifetime... that followed by
> "especially in high temperature condition" doesn't mean that operating
> the RK3588J within the RK3588 typical range is safe to do.

Also true, and I'll also try to address that in the v2.

>> obviously can't know what will be the runtime temperature conditions 
>> for
>> a particular board, we may provide only the always-safe OPPs.
>> 
>> With all this and the downstream RK3588(J) DT definitions [4][5] in 
>> mind,
>> let's delete the RK3588J CPU and GPU OPPs that are not considered 
>> belonging
>> to the normal operation mode for this SoC variant.  To quote the 
>> RK3588J
>> datasheet [2], "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", while "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".
>> 
>> To sum up the RK3588J datasheet [2] and the vendor-provided DTs, 
>> [4][5]
>> the maximum allowed CPU core and GPU frequencies are as follows:
>> 
>>     IP core    | Normal mode | Overdrive mode
>>    ------------+-------------+----------------
>>     Cortex-A55 |   1,296 MHz |      1,704 MHz
>>     Cortex-A76 |   1,608 MHz |      2,016 MHz
>>     GPU        |     700 MHz |        850 MHz
>> 
> 
> The NPU too is impacted by this, so maybe list it anyway here? Even if
> we don't support it right now and don't have OPPs for it.

Agreed, will add in the v2.  Having all that information in a single
place can only be helpful.

>> Unfortunately, when it comes to the actual voltages for the RK3588J 
>> CPU and
>> GPU OPPs, there's a discrepancy between the RK3588J datasheet [2] and 
>> the
>> downstream kernel code. [4][5]  The RK3588J datasheet states that "the 
>> max.
>> working voltage of CPU/GPU/NPU is 0.75 V under the normal mode", while 
>> the
>> downstream kernel code actually allows voltage ranges that go up to 
>> 0.95 V,
>> which is still within the voltage range allowed by the datasheet.  
>> However,
>> the RK3588J datasheet also tells us to "strictly refer to the software
>> configuration of SDK and the hardware reference design", so let's 
>> embrace
>> the voltage ranges provided by the downstream kernel code, which also
>> prevents the undesirable theoretical outcome of ending up with no 
>> usable
>> OPPs on a particular board, as a result of the board's voltage 
>> regulator(s)
>> being unable to deliver the exact voltages, for whatever reason.
>> 
>> The above-described voltage ranges for the RK3588J CPU OPPs remain 
>> taken
>> from the downstream kernel code [4][5] by picking the highest, 
>> worst-bin
>> values, which ensure that all RK3588J bins will work reliably.  Yes, 
>> with
>> some power inevitably wasted as unnecessarily generated heat, but the
>> reliability is paramount, together with the longevity.  This 
>> deficiency
>> may be revisited separately at some point in the future.
>> 
>> The provided RK3588J CPU OPPs follow the slightly debatable "provide 
>> only
>> the highest-frequency OPP from the same-voltage group" approach that's 
>> been
> 
> Interesting that we went for a different strategy for the GPU OPPs :)

Good point, and I'm fully aware of that. :)  Actually, I'm rather
sure that omitting the additional CPU OPPs does no good to us, but
I didn't want to argue about that when they were dropped originally,
before I can have some hard numbers to prove it in a repeatable way.

>> established earlier, [6] as a result of the "same-voltage, 
>> lower-frequency"
>> OPPs being considered inefficient from the IPA governor's standpoint, 
>> which
>> may also be revisited separately at some point in the future.
>> 
>> [1] 
>> https://wiki.friendlyelec.com/wiki/images/e/ee/Rockchip_RK3588_Datasheet_V1.6-20231016.pdf
>> [2] 
>> https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2403201054_Rockchip-RK3588J_C22364189.pdf
>> [3] 
>> https://lore.kernel.org/linux-rockchip/e55125ed-64fb-455e-b1e4-cebe2cf006e4@cherry.de/T/#u
>> [4] 
>> https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
>> [5] 
>> https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
>> [6] 
>> https://lore.kernel.org/all/20240229-rk-dts-additions-v3-5-6afe8473a631@gmail.com/
>> 
>> Fixes: 667885a68658 ("arm64: dts: rockchip: Add OPP data for CPU cores 
>> on RK3588j")
>> Fixes: a7b2070505a2 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 
>> and RK3588j")
>> Cc: stable@vger.kernel.org
>> Cc: Heiko Stuebner <heiko@sntech.de>
>> Cc: Alexey Charkov <alchark@gmail.com>
>> Helped-by: Quentin Schulz <quentin.schulz@cherry.de>
> 
> Reported-by/Suggested-by?
> 
> I don't see Helped-by in
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
> 
> I see 2496b2aaacf137250f4ca449f465e2cadaabb0e8 got the Helped-by
> replaced by a Suggested-by for example, but I see other patches with
> Helped-by... if that is a standard trailer for kernel patches, then
> maybe we should add it to that doc?

Actually, I already tried to get the Helped-by tag added to the
kernel documentation, by submitting a small patch series. [*]
Unfortunately, it got rejected. :/

However, Heiko accepts Helped-by tags and nobody higher up the
tree seems to complain, so we should be fine. :)  It isn't the
case with all maintainers, though.

[*] 
https://lore.kernel.org/all/cover.1730874296.git.dsimic@manjaro.org/T/#u

>> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>> ---
>>   arch/arm64/boot/dts/rockchip/rk3588j.dtsi | 53 
>> ++++++++---------------
>>   1 file changed, 17 insertions(+), 36 deletions(-)
>> 
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi 
>> b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
>> index bce72bac4503..3045cb3bd68c 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
>> @@ -11,74 +11,59 @@ cluster0_opp_table: opp-table-cluster0 {
>>   		compatible = "operating-points-v2";
>>   		opp-shared;
>>   -		opp-1416000000 {
>> -			opp-hz = /bits/ 64 <1416000000>;
>> +		opp-1200000000 {
>> +			opp-hz = /bits/ 64 <1200000000>;
>>   			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>;
>> +		opp-1296000000 {
>> +			opp-hz = /bits/ 64 <1296000000>;
>> +			opp-microvolt = <775000 775000 950000>;
> 
> Got tricked by this one.
> 
> In the Rockchip vendor kernel, the opp-microvolt is 750000 750000
> 950000, so the same as CPU OPP 1.2GHz. However, the opp-microvolt-L1
> and L0 are higher than that. Only a couple of the OPPs in vendor
> kernel actually have opp-microvolt-L* higher than opp-microvolt, that
> is a noteworthy oddity for anyone reviewing this patch :)
> 
> Anyway, that is correct, we take the highest voltage among all defined
> opp-microvolt* properties.

Indeed, and I also almost got tricked by the same OPP. :)

> I only have comments on the commit log, the diff is fine so:
> 
> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks once again for your detailed review! :)
Quentin Schulz March 24, 2025, 9:23 a.m. UTC | #3
Hi Dragan,

On 3/23/25 11:19 AM, Dragan Simic wrote:
> Hello Quentin,
> 
> Thanks for your comments!  Please see some responses below.
> 
> On 2025-03-21 10:53, Quentin Schulz wrote:
>> On 3/21/25 4:28 AM, Dragan Simic wrote:
>>> The differences in the vendor-approved CPU and GPU OPPs for the standard
>>> Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J 
>>> variant [2]
>>> come from the latter, presumably, supporting an extended temperature 
>>> range
>>> that's usually associated with industrial applications, despite the 
>>> two SoC
>>> variant datasheets specifying the same upper limit for the allowed 
>>> ambient
>>> temperature for both variants.  However, the lower temperature limit is
>>
>> RK3588 is rated for 0-80°C, RK3588J for -40-85°C, c.f. Recommended
>> Operating Conditions, Table 3-2, Ambient Operating Temperature.
> 
> Indeed, which is why I specifically wrote "specifying the same upper
> limit", because having a lower negative temperature limit could hardly
> put the RK3588J in danger of overheating or running hotter. :)
> 

"""
despite the two SoC variant datasheets specifying the same upper limit 
for the allowed temperature for both variants
"""

is incorrect. The whole range is different, yes it's only a 5°C 
difference for the upper limit, but they still are different.

>>> specified much lower for the RK3588J variant. [1][2]
>>>
>>> To be on the safe side and to ensure maximum longevity of the RK3588J 
>>> SoCs,
>>> only the CPU and GPU OPPs that are declared by the vendor to be 
>>> always safe
>>> for this SoC variant may be provided.  As explained by the vendor [3] 
>>> and
>>> according to its datasheet, [2] the RK3588J variant can actually run 
>>> safely
>>> at higher CPU and GPU OPPs as well, but only when not enjoying the 
>>> assumed
>>> extended temperature range that the RK3588J, as an SoC variant targeted
>>
>> "only when not enjoying the assumed extended temperature range" is
>> extrapolated by me/us and not confirmed by Rockchip themselves. I've
>> asked for a statement on what "industrial environment" they specify in
>> the Normal Mode explanation means since it's the only time they use
>> the term. I've yet to receive an answer. The only thing Rockchip in
>> their datasheet is that the overdrive mode will shorten lifetime when
>> used for a long time, especially in high temperature conditions. It's
>> not clear whether we can use the overdrive mode even within the RK3588
>> typical range of operation.
> 
> True.  I'll see to rephrase the patch description a bit in the v2,
> to avoid this kind of speculation.  I mean, perhaps the speculation
> is right, but it hasn't been confirmed officially by Rockchip.
> 

Speculation is fine, but it should be worded as such.

[...]

>>> The provided RK3588J CPU OPPs follow the slightly debatable "provide 
>>> only
>>> the highest-frequency OPP from the same-voltage group" approach 
>>> that's been
>>
>> Interesting that we went for a different strategy for the GPU OPPs :)
> 
> Good point, and I'm fully aware of that. :)  Actually, I'm rather
> sure that omitting the additional CPU OPPs does no good to us, but
> I didn't want to argue about that when they were dropped originally,
> before I can have some hard numbers to prove it in a repeatable way.
> 

I assume we'll have some patch in the future with those added and those 
hard numbers you're talking about, so looking forward to seeing it on 
the ML :)

[...]

>>> Helped-by: Quentin Schulz <quentin.schulz@cherry.de>
>>
>> Reported-by/Suggested-by?
>>
>> I don't see Helped-by in
>> https://eur02.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Fwww.kernel.org%2Fdoc%2Fhtml%2Flatest%2Fprocess%2Fsubmitting-patches.html%23using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes&data=05%7C02%7Cquentin.schulz%40cherry.de%7Cdc754791b6844506b11c08dd69f444a7%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638783220330058516%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4bv9pUh6aSD0GVLJ4Zvuyvox1K0xxwf83KXX86QsvMo%3D&reserved=0
>>
>> I see 2496b2aaacf137250f4ca449f465e2cadaabb0e8 got the Helped-by
>> replaced by a Suggested-by for example, but I see other patches with
>> Helped-by... if that is a standard trailer for kernel patches, then
>> maybe we should add it to that doc?
> 
> Actually, I already tried to get the Helped-by tag added to the
> kernel documentation, by submitting a small patch series. [*]
> Unfortunately, it got rejected. :/
> 
> However, Heiko accepts Helped-by tags and nobody higher up the
> tree seems to complain, so we should be fine. :)  It isn't the
> case with all maintainers, though.
> 
> [*] https://eur02.safelinks.protection.outlook.com/? 
> url=https%3A%2F%2Flore.kernel.org%2Fall%2Fcover.1730874296.git.dsimic%40manjaro.org%2FT%2F%23u&data=05%7C02%7Cquentin.schulz%40cherry.de%7Cdc754791b6844506b11c08dd69f444a7%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638783220330070422%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3dZgSG%2FBT6f%2Ffqs7D30HvEl18SzqYPwNeUGWBZfMAqM%3D&reserved=0
> 

Are you trying to up the numbers of Helped-by in commit logs to make it 
a reasonable request to add the trailer in the documentation :) ?

Cheers,
Quentin
Dragan Simic March 24, 2025, 9:36 a.m. UTC | #4
Hello Quentin,

On 2025-03-23 11:19, Dragan Simic wrote:
> On 2025-03-21 10:53, Quentin Schulz wrote:
>> On 3/21/25 4:28 AM, Dragan Simic wrote:
>>> The differences in the vendor-approved CPU and GPU OPPs for the 
>>> standard
>>> Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J 
>>> variant [2]
>>> come from the latter, presumably, supporting an extended temperature 
>>> range
>>> that's usually associated with industrial applications, despite the 
>>> two SoC
>>> variant datasheets specifying the same upper limit for the allowed 
>>> ambient
>>> temperature for both variants.  However, the lower temperature limit 
>>> is
>> 
>> RK3588 is rated for 0-80°C, RK3588J for -40-85°C, c.f. Recommended
>> Operating Conditions, Table 3-2, Ambient Operating Temperature.
> 
> Indeed, which is why I specifically wrote "specifying the same upper
> limit", because having a lower negative temperature limit could hardly
> put the RK3588J in danger of overheating or running hotter. :)

Oh, now I see what you actually wrote above, which I misread a bit
initially...  In fact, the upper ambient temperature limit is the
same for both RK3588J and RK3588, according to the datasheets;  it's
just that the lower temperature limit is much lower for the RK3588J,
which the patch description says.

I'm not sure where did you find the 80 vs. 85 oC difference;  please,
see a couple of screenshots from the datasheets, linked below:

- RK3588 datasheet v1.6 (v1.7 is the same): https://0x0.st/8j1a.png
- RK3588J datasheet v1.1: https://0x0.st/8j1m.png

The v2 of the patch is coming soon, with the patch description improved
according to your suggestions.
Dragan Simic March 24, 2025, 9:53 a.m. UTC | #5
Hello Quentin,

On 2025-03-24 10:23, Quentin Schulz wrote:
> On 3/23/25 11:19 AM, Dragan Simic wrote:
>> On 2025-03-21 10:53, Quentin Schulz wrote:
>>> On 3/21/25 4:28 AM, Dragan Simic wrote:
>>>> The differences in the vendor-approved CPU and GPU OPPs for the 
>>>> standard
>>>> Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J 
>>>> variant [2]
>>>> come from the latter, presumably, supporting an extended temperature 
>>>> range
>>>> that's usually associated with industrial applications, despite the 
>>>> two SoC
>>>> variant datasheets specifying the same upper limit for the allowed 
>>>> ambient
>>>> temperature for both variants.  However, the lower temperature limit 
>>>> is
>>> 
>>> RK3588 is rated for 0-80°C, RK3588J for -40-85°C, c.f. Recommended
>>> Operating Conditions, Table 3-2, Ambient Operating Temperature.
>> 
>> Indeed, which is why I specifically wrote "specifying the same upper
>> limit", because having a lower negative temperature limit could hardly
>> put the RK3588J in danger of overheating or running hotter. :)
> 
> """
> despite the two SoC variant datasheets specifying the same upper limit
> for the allowed temperature for both variants
> """
> 
> is incorrect. The whole range is different, yes it's only a 5°C
> difference for the upper limit, but they still are different.

I just commented on this separately, with a couple of datasheet
screenshots, before I saw your latest response.  Please, have
a look at that message.

>>>> specified much lower for the RK3588J variant. [1][2]
>>>> 
>>>> To be on the safe side and to ensure maximum longevity of the 
>>>> RK3588J SoCs,
>>>> only the CPU and GPU OPPs that are declared by the vendor to be 
>>>> always safe
>>>> for this SoC variant may be provided.  As explained by the vendor 
>>>> [3] and
>>>> according to its datasheet, [2] the RK3588J variant can actually run 
>>>> safely
>>>> at higher CPU and GPU OPPs as well, but only when not enjoying the 
>>>> assumed
>>>> extended temperature range that the RK3588J, as an SoC variant 
>>>> targeted
>>> 
>>> "only when not enjoying the assumed extended temperature range" is
>>> extrapolated by me/us and not confirmed by Rockchip themselves. I've
>>> asked for a statement on what "industrial environment" they specify 
>>> in
>>> the Normal Mode explanation means since it's the only time they use
>>> the term. I've yet to receive an answer. The only thing Rockchip in
>>> their datasheet is that the overdrive mode will shorten lifetime when
>>> used for a long time, especially in high temperature conditions. It's
>>> not clear whether we can use the overdrive mode even within the 
>>> RK3588
>>> typical range of operation.
>> 
>> True.  I'll see to rephrase the patch description a bit in the v2,
>> to avoid this kind of speculation.  I mean, perhaps the speculation
>> is right, but it hasn't been confirmed officially by Rockchip.
> 
> Speculation is fine, but it should be worded as such.

Agreed, because that's our understanding so far, but it needs
to be explained a bit better.

>>>> The provided RK3588J CPU OPPs follow the slightly debatable "provide 
>>>> only
>>>> the highest-frequency OPP from the same-voltage group" approach 
>>>> that's been
>>> 
>>> Interesting that we went for a different strategy for the GPU OPPs :)
>> 
>> Good point, and I'm fully aware of that. :)  Actually, I'm rather
>> sure that omitting the additional CPU OPPs does no good to us, but
>> I didn't want to argue about that when they were dropped originally,
>> before I can have some hard numbers to prove it in a repeatable way.
> 
> I assume we'll have some patch in the future with those added and
> those hard numbers you're talking about, so looking forward to seeing
> it on the ML :)

Indeed, that's the plan, and there should be even more patches,
which should remove the slightly annoying "xyz OPP is inefficient"
warnings emitted by the IPA governor. :)

>>>> Helped-by: Quentin Schulz <quentin.schulz@cherry.de>
>>> 
>>> Reported-by/Suggested-by?
>>> 
>>> I don't see Helped-by in
>>> https://eur02.safelinks.protection.outlook.com/? 
>>> url=https%3A%2F%2Fwww.kernel.org%2Fdoc%2Fhtml%2Flatest%2Fprocess%2Fsubmitting-patches.html%23using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes&data=05%7C02%7Cquentin.schulz%40cherry.de%7Cdc754791b6844506b11c08dd69f444a7%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638783220330058516%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4bv9pUh6aSD0GVLJ4Zvuyvox1K0xxwf83KXX86QsvMo%3D&reserved=0
>>> 
>>> I see 2496b2aaacf137250f4ca449f465e2cadaabb0e8 got the Helped-by
>>> replaced by a Suggested-by for example, but I see other patches with
>>> Helped-by... if that is a standard trailer for kernel patches, then
>>> maybe we should add it to that doc?
>> 
>> Actually, I already tried to get the Helped-by tag added to the
>> kernel documentation, by submitting a small patch series. [*]
>> Unfortunately, it got rejected. :/
>> 
>> However, Heiko accepts Helped-by tags and nobody higher up the
>> tree seems to complain, so we should be fine. :)  It isn't the
>> case with all maintainers, though.
>> 
>> [*] https://eur02.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Flore.kernel.org%2Fall%2Fcover.1730874296.git.dsimic%40manjaro.org%2FT%2F%23u&data=05%7C02%7Cquentin.schulz%40cherry.de%7Cdc754791b6844506b11c08dd69f444a7%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638783220330070422%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3dZgSG%2FBT6f%2Ffqs7D30HvEl18SzqYPwNeUGWBZfMAqM%3D&reserved=0
> 
> Are you trying to up the numbers of Helped-by in commit logs to make
> it a reasonable request to add the trailer in the documentation :) ?

It's just that Helped-by is, to me, of a bit "higher value" than
Suggested-by or Reported-by, because Helped-by means that the
tagged person contributed more to the patch than just suggesting
it or reporting a bug.  In addition, having more Helped-by tags
present in various commits can help a bit with, possibly, making
it officially supported at some point in the future. :)
Quentin Schulz March 24, 2025, 10:20 a.m. UTC | #6
Hi Dragan,

On 3/24/25 10:53 AM, Dragan Simic wrote:
> Hello Quentin,
> 
> On 2025-03-24 10:23, Quentin Schulz wrote:
>> On 3/23/25 11:19 AM, Dragan Simic wrote:
>>> On 2025-03-21 10:53, Quentin Schulz wrote:
>>>> On 3/21/25 4:28 AM, Dragan Simic wrote:
>>>>> The differences in the vendor-approved CPU and GPU OPPs for the 
>>>>> standard
>>>>> Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J 
>>>>> variant [2]
>>>>> come from the latter, presumably, supporting an extended 
>>>>> temperature range
>>>>> that's usually associated with industrial applications, despite the 
>>>>> two SoC
>>>>> variant datasheets specifying the same upper limit for the allowed 
>>>>> ambient
>>>>> temperature for both variants.  However, the lower temperature 
>>>>> limit is
>>>>
>>>> RK3588 is rated for 0-80°C, RK3588J for -40-85°C, c.f. Recommended
>>>> Operating Conditions, Table 3-2, Ambient Operating Temperature.
>>>
>>> Indeed, which is why I specifically wrote "specifying the same upper
>>> limit", because having a lower negative temperature limit could hardly
>>> put the RK3588J in danger of overheating or running hotter. :)
>>
>> """
>> despite the two SoC variant datasheets specifying the same upper limit
>> for the allowed temperature for both variants
>> """
>>
>> is incorrect. The whole range is different, yes it's only a 5°C
>> difference for the upper limit, but they still are different.
> 
> I just commented on this separately, with a couple of datasheet
> screenshots, before I saw your latest response.  Please, have
> a look at that message.
> 

I see, I had a v1.3 datasheet opened:

https://github.com/FanX-Tek/rk3588-TRM-and-Datasheet/blob/master/Rockchip_RK3588_Datasheet_V1.3-20220328.pdf

Interestingly, it seems the RK3588S (still?) has a smaller operating range:

https://www.armboard.cn/download/Rockchip_RK3588S_Datasheet_V1.6-20240821.pdf

Cheers,
Quentin
Dragan Simic March 24, 2025, 10:33 a.m. UTC | #7
On 2025-03-24 11:20, Quentin Schulz wrote:
> On 3/24/25 10:53 AM, Dragan Simic wrote:
>> On 2025-03-24 10:23, Quentin Schulz wrote:
>>> On 3/23/25 11:19 AM, Dragan Simic wrote:
>>>> On 2025-03-21 10:53, Quentin Schulz wrote:
>>>>> On 3/21/25 4:28 AM, Dragan Simic wrote:
>>>>>> The differences in the vendor-approved CPU and GPU OPPs for the 
>>>>>> standard
>>>>>> Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J 
>>>>>> variant [2]
>>>>>> come from the latter, presumably, supporting an extended 
>>>>>> temperature range
>>>>>> that's usually associated with industrial applications, despite 
>>>>>> the two SoC
>>>>>> variant datasheets specifying the same upper limit for the allowed 
>>>>>> ambient
>>>>>> temperature for both variants.  However, the lower temperature 
>>>>>> limit is
>>>>> 
>>>>> RK3588 is rated for 0-80°C, RK3588J for -40-85°C, c.f. Recommended
>>>>> Operating Conditions, Table 3-2, Ambient Operating Temperature.
>>>> 
>>>> Indeed, which is why I specifically wrote "specifying the same upper
>>>> limit", because having a lower negative temperature limit could 
>>>> hardly
>>>> put the RK3588J in danger of overheating or running hotter. :)
>>> 
>>> """
>>> despite the two SoC variant datasheets specifying the same upper 
>>> limit
>>> for the allowed temperature for both variants
>>> """
>>> 
>>> is incorrect. The whole range is different, yes it's only a 5°C
>>> difference for the upper limit, but they still are different.
>> 
>> I just commented on this separately, with a couple of datasheet
>> screenshots, before I saw your latest response.  Please, have
>> a look at that message.
> 
> I see, I had a v1.3 datasheet opened:
> 
> https://github.com/FanX-Tek/rk3588-TRM-and-Datasheet/blob/master/Rockchip_RK3588_Datasheet_V1.3-20220328.pdf

Yup, the v1.6 of the RK3588 datasheet increased the upper ambient
temperature limit from 80 to 85 oC.

> Interestingly, it seems the RK3588S (still?) has a smaller operating 
> range:
> 
> https://www.armboard.cn/download/Rockchip_RK3588S_Datasheet_V1.6-20240821.pdf

Oh, that's quite interesting, I had the v1.5 as the newest version.
The v1.6 of the RK3588S datasheet actually lowered the upper ambient
temperature limit from 85 down to 80 oC.
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
index bce72bac4503..3045cb3bd68c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
@@ -11,74 +11,59 @@  cluster0_opp_table: opp-table-cluster0 {
 		compatible = "operating-points-v2";
 		opp-shared;
 
-		opp-1416000000 {
-			opp-hz = /bits/ 64 <1416000000>;
+		opp-1200000000 {
+			opp-hz = /bits/ 64 <1200000000>;
 			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>;
+		opp-1296000000 {
+			opp-hz = /bits/ 64 <1296000000>;
+			opp-microvolt = <775000 775000 950000>;
 			clock-latency-ns = <40000>;
 		};
 	};
 
 	cluster1_opp_table: opp-table-cluster1 {
 		compatible = "operating-points-v2";
 		opp-shared;
 
+		opp-1200000000{
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <750000 750000 950000>;
+			clock-latency-ns = <40000>;
+		};
 		opp-1416000000 {
 			opp-hz = /bits/ 64 <1416000000>;
-			opp-microvolt = <750000 750000 950000>;
+			opp-microvolt = <762500 762500 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>;
-		};
 	};
 
 	cluster2_opp_table: opp-table-cluster2 {
 		compatible = "operating-points-v2";
 		opp-shared;
 
+		opp-1200000000{
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <750000 750000 950000>;
+			clock-latency-ns = <40000>;
+		};
 		opp-1416000000 {
 			opp-hz = /bits/ 64 <1416000000>;
-			opp-microvolt = <750000 750000 950000>;
+			opp-microvolt = <762500 762500 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>;
-		};
 	};
 
 	gpu_opp_table: opp-table {
@@ -104,10 +89,6 @@  opp-700000000 {
 			opp-hz = /bits/ 64 <700000000>;
 			opp-microvolt = <750000 750000 850000>;
 		};
-		opp-850000000 {
-			opp-hz = /bits/ 64 <800000000>;
-			opp-microvolt = <787500 787500 850000>;
-		};
 	};
 };