Update, encapsulate and expand the RK356x SoC dtsi files

PATCH Superseded Dragan Simic 3 participants 19 messages Oct 12, 2024 – Oct 23, 2024

Subsystems (2)

Device tree bindings Arm Rockchip

lore

Share & tools

lore

Dragan Simic

author

2024-10-12 17:04 UTC #0 lore raw

cover Update, encapsulate and expand the RK356x SoC dtsi files

This series tackles the Rockchip RK356x SoC dtsi files in a few different ways. First, it updates the lower and upper voltage limits and the exact voltages for the Rockchip RK356x CPU OPPs, using the most conservative per-OPP values for different SoC bins. This is rather similar to the already performed adjustment of the GPU OPP voltages. [1]

Next, this series prepares the RK356x SoC dtsi files for per-variant OPPs, with the RK3566T being the first new RK356x SoC variant to be introduced. This follows the approach used for the RK3588 SoC variants. [2]

Lastly, this series introduces new SoC dtsi for the RK3566T variant, which is capable of operating at the CPU and GPU OPPs/frequencies lower than the "full-fat" RK3566 variant's. The RK3566T is found on some of the already supported boards and rather importantly, this stops the CPU cores and the GPU from being overclocked on these boards.

[1] https://lore.kernel.org/linux-rockchip/[email protected]/T/#m786f0e0a45377d29aea826f05c95b5052a8bb3d9
[2] https://lore.kernel.org/all/9ffedc0e2ca7f167d9d795b2a8f43cb9f56a653b.1717923308.git.dsimic@manjaro.org/T/#u

Dragan Simic (3):
arm64: dts: rockchip: Update CPU OPP voltages in RK356x SoC dtsi
arm64: dts: rockchip: Prepare RK356x SoC dtsi files for per-variant
OPPs
arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variant

 .../{rk3566.dtsi => rk3566-base.dtsi}         |   2 +-
 .../dts/rockchip/rk3566-radxa-zero-3.dtsi     |   2 +-
 .../boot/dts/rockchip/rk3566-rock-3c.dts      |   2 +-
 arch/arm64/boot/dts/rockchip/rk3566.dtsi      | 116 ++++++++++++++----
 arch/arm64/boot/dts/rockchip/rk3566t.dtsi     |  90 ++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      | 113 ++++++++++++++++-
 .../{rk356x.dtsi => rk356x-base.dtsi}         |  81 ------------
 7 files changed, 294 insertions(+), 112 deletions(-)
 copy arch/arm64/boot/dts/rockchip/{rk3566.dtsi => rk3566-base.dtsi} (95%)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566t.dtsi
 rename arch/arm64/boot/dts/rockchip/{rk356x.dtsi => rk356x-base.dtsi} (96%)

Dragan Simic

author

2024-10-12 17:04 UTC #1 lore raw

PATCH 1/3 arm64: dts: rockchip: Update CPU OPP voltages in RK356x SoC dtsi

Update the lower/upper voltage limits and the exact voltages for the Rockchip RK356x CPU OPPs, using the most conservative values (i.e. the highest per-OPP voltages) found in the vendor kernel source. [1]

Using the most conservative per-OPP voltages ensures reliable CPU operation regardless of the actual CPU binning, with the downside of possibly using a bit more power for the CPU cores than absolutely needed.

Additionally, fill in the missing "clock-latency-ns" CPU OPP properties, using the values found in the vendor kernel source. [1]

[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi

Related-to: eb665b1c06bc ("arm64: dts: rockchip: Update GPU OPP voltages in RK356x SoC dtsi")

Signed-off-by Dragan Simic <[email protected]>

---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi |  1 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 18 ++++++++++++------
 2 files changed, 13 insertions(+), 6 deletions(-)

arch/arm64/boot/dts/rockchip/rk3568.dtsi +1 -0

index 0946310e8c12..5c54898f6ed1 100644
@@ -273,6 +273,7 @@ &cpu0_opp_table {
 	opp-1992000000 {
 		opp-hz = /bits/ 64 <1992000000>;
 		opp-microvolt = <1150000 1150000 1150000>;
+		clock-latency-ns = <40000>;
 	};
 };

arch/arm64/boot/dts/rockchip/rk356x.dtsi +12 -6

index 0ee0ada6f0ab..534593f2ed0b 100644
@@ -134,39 +134,45 @@ cpu0_opp_table: opp-table-0 {
 
 		opp-408000000 {
 			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
 			clock-latency-ns = <40000>;
 		};
 
 		opp-600000000 {
 			opp-hz = /bits/ 64 <600000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
 		};
 
 		opp-816000000 {
 			opp-hz = /bits/ 64 <816000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
 			opp-suspend;
 		};
 
 		opp-1104000000 {
 			opp-hz = /bits/ 64 <1104000000>;
 			opp-microvolt = <900000 900000 1150000>;
+			clock-latency-ns = <40000>;
 		};
 
 		opp-1416000000 {
 			opp-hz = /bits/ 64 <1416000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <1025000 1025000 1150000>;
+			clock-latency-ns = <40000>;
 		};
 
 		opp-1608000000 {
 			opp-hz = /bits/ 64 <1608000000>;
-			opp-microvolt = <975000 975000 1150000>;
+			opp-microvolt = <1100000 1100000 1150000>;
+			clock-latency-ns = <40000>;
 		};
 
 		opp-1800000000 {
 			opp-hz = /bits/ 64 <1800000000>;
-			opp-microvolt = <1050000 1050000 1150000>;
+			opp-microvolt = <1150000 1150000 1150000>;
+			clock-latency-ns = <40000>;
 		};
 	};

Diederik de Haas

2024-10-12 19:27 UTC #2 lore raw

Re: [PATCH 1/3] arm64: dts: rockchip: Update CPU OPP voltages in RK356x SoC dtsi

Hi Dragan,

Quoted 49 lines · Dragan Simic

Update the lower/upper voltage limits and the exact voltages for the Rockchip RK356x CPU OPPs, using the most conservative values (i.e. the highest per-OPP voltages) found in the vendor kernel source. [1]
Using the most conservative per-OPP voltages ensures reliable CPU operation regardless of the actual CPU binning, with the downside of possibly using a bit more power for the CPU cores than absolutely needed.
Additionally, fill in the missing "clock-latency-ns" CPU OPP properties, using the values found in the vendor kernel source. [1]
[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
Related-to: eb665b1c06bc ("arm64: dts: rockchip: Update GPU OPP voltages in RK356x SoC dtsi")
Signed-off-by Dragan Simic <[email protected]>
---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi |  1 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 18 ++++++++++++------
 2 files changed, 13 insertions(+), 6 deletions(-)
arch/arm64/boot/dts/rockchip/rk3568.dtsi +1 -0
index 0946310e8c12..5c54898f6ed1 100644
@@ -273,6 +273,7 @@ &cpu0_opp_table {
 	opp-1992000000 {
 		opp-hz = /bits/ 64 <1992000000>;
 		opp-microvolt = <1150000 1150000 1150000>;
+		clock-latency-ns = <40000>;
 	};
 };
 
arch/arm64/boot/dts/rockchip/rk356x.dtsi +2 -2
index 0ee0ada6f0ab..534593f2ed0b 100644
@@ -134,39 +134,45 @@ cpu0_opp_table: opp-table-0 {
 
 		opp-408000000 {
 			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
 			clock-latency-ns = <40000>;
 		};
 
 		opp-600000000 {
 			opp-hz = /bits/ 64 <600000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;

arch/arm64/boot/dts/rockchip/rk356x.dtsi cpu0_opp_table: opp-table-0 { · line 152

Quoted 10 lines

arch/arm64/boot/dts/rockchip/rk356x.dtsi +3 -1

+			clock-latency-ns = <40000>;
 		};
 
 		opp-816000000 {
 			opp-hz = /bits/ 64 <816000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
 			opp-suspend;
 		};

While it felt a bit much to send a patch just to remove the blank lines between the opp nodes, this sounds like an excellent opportunity to make it consistent with the opp list in other DT files?

Cheers,
Diederik

Dragan Simic

author

2024-10-12 19:45 UTC #3 lore raw

Re: [PATCH 1/3] arm64: dts: rockchip: Update CPU OPP voltages in RK356x SoC dtsi

Hello Diederik,

Quoted 53 lines · Diederik de Haas

Quoted 52 lines · Dragan Simic
Update the lower/upper voltage limits and the exact voltages for the Rockchip RK356x CPU OPPs, using the most conservative values (i.e. the highest per-OPP voltages) found in the vendor kernel source. [1]
Using the most conservative per-OPP voltages ensures reliable CPU operation regardless of the actual CPU binning, with the downside of possibly using a bit more power for the CPU cores than absolutely needed.
Additionally, fill in the missing "clock-latency-ns" CPU OPP properties, using the values found in the vendor kernel source. [1]
[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
Related-to: eb665b1c06bc ("arm64: dts: rockchip: Update GPU OPP voltages in RK356x SoC dtsi")
Signed-off-by Dragan Simic <[email protected]>
---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi |  1 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 18 ++++++++++++------
 2 files changed, 13 insertions(+), 6 deletions(-)
arch/arm64/boot/dts/rockchip/rk3568.dtsi +1 -0
index 0946310e8c12..5c54898f6ed1 100644
@@ -273,6 +273,7 @@ &cpu0_opp_table {
 	opp-1992000000 {
 		opp-hz = /bits/ 64 <1992000000>;
 		opp-microvolt = <1150000 1150000 1150000>;
+		clock-latency-ns = <40000>;
 	};
 };
 
arch/arm64/boot/dts/rockchip/rk356x.dtsi +3 -2
index 0ee0ada6f0ab..534593f2ed0b 100644
@@ -134,39 +134,45 @@ cpu0_opp_table: opp-table-0 {
 
 		opp-408000000 {
 			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
 			clock-latency-ns = <40000>;
 		};
 
 		opp-600000000 {
 			opp-hz = /bits/ 64 <600000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
 		};
 

Quoted 11 lines

arch/arm64/boot/dts/rockchip/rk356x.dtsi cpu0_opp_table: opp-table-0 { · line 152
Quoted 7 lines
arch/arm64/boot/dts/rockchip/rk356x.dtsi +2 -1
 		opp-816000000 {
 			opp-hz = /bits/ 64 <816000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
 			opp-suspend;
 		};
While it felt a bit much to send a patch just to remove the blank lines between the opp nodes, this sounds like an excellent opportunity to make it consistent with the opp list in other DT files?

Actually, my plan is to work on the SoC binning, which will involve touching nearly every OPP in the Rockchip DTs, and will add much more data to each OPP node. Thus, having empty lines as the separators between the OPP nodes is something we should actually want, because not having them will actually reduce the readability after the size of the individual OPP nodes is increased.

That's the reason why I opted for having the separator lines in this patch series, i.e. because having them everywhere should be the final outcome, and because in this case they were already present where the OPPs were moved or copied from.

Diederik de Haas

2024-10-12 20:02 UTC #4 lore raw

Re: [PATCH 1/3] arm64: dts: rockchip: Update CPU OPP voltages in RK356x SoC dtsi

Hi Dragan,

Quoted 75 lines · Dragan Simic

Quoted 62 lines · Diederik de Haas
Quoted 61 lines · Dragan Simic
Update the lower/upper voltage limits and the exact voltages for the Rockchip
RK356x CPU OPPs, using the most conservative values (i.e. the highest per-OPP
voltages) found in the vendor kernel source. [1]
Using the most conservative per-OPP voltages ensures reliable CPU operation
regardless of the actual CPU binning, with the downside of possibly using
a bit more power for the CPU cores than absolutely needed.
Additionally, fill in the missing "clock-latency-ns" CPU OPP properties, using
the values found in the vendor kernel source. [1]
[1]
https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
Related-to: eb665b1c06bc ("arm64: dts: rockchip: Update GPU OPP voltages in RK356x SoC dtsi")
Signed-off-by Dragan Simic <[email protected]>
---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi |  1 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 18 ++++++++++++------
 2 files changed, 13 insertions(+), 6 deletions(-)
arch/arm64/boot/dts/rockchip/rk3568.dtsi +1 -0
index 0946310e8c12..5c54898f6ed1 100644
@@ -273,6 +273,7 @@ &cpu0_opp_table {
 	opp-1992000000 {
 		opp-hz = /bits/ 64 <1992000000>;
 		opp-microvolt = <1150000 1150000 1150000>;
+		clock-latency-ns = <40000>;
 	};
 };
 
arch/arm64/boot/dts/rockchip/rk356x.dtsi +3 -2
index 0ee0ada6f0ab..534593f2ed0b 100644
@@ -134,39 +134,45 @@ cpu0_opp_table: opp-table-0 {
 
 		opp-408000000 {
 			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
 			clock-latency-ns = <40000>;
 		};
 
 		opp-600000000 {
 			opp-hz = /bits/ 64 <600000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
 		};
 
Quoted 11 lines
arch/arm64/boot/dts/rockchip/rk356x.dtsi cpu0_opp_table: opp-table-0 { · line 152
Quoted 7 lines
arch/arm64/boot/dts/rockchip/rk356x.dtsi +2 -1
 		opp-816000000 {
 			opp-hz = /bits/ 64 <816000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
 			opp-suspend;
 		};
While it felt a bit much to send a patch just to remove the blank lines between the opp nodes, this sounds like an excellent opportunity to make it consistent with the opp list in other DT files?

Quoted 4 lines

Actually, my plan is to work on the SoC binning, which will involve touching nearly every OPP in the Rockchip DTs, and will add much more data to each OPP node. Thus, having empty lines as the separators between the OPP nodes is something we should actually want, because

As indicated in the "arm64: dts: rockchip: Add dtsi file for RK3399S SoC variant" patch series, I do prefer the separator lines ...

Quoted 7 lines

not having them will actually reduce the readability after the size of the individual OPP nodes is increased.
That's the reason why I opted for having the separator lines in this patch series, i.e. because having them everywhere should be the final outcome, and because in this case they were already present where the OPPs were moved or copied from.

... but you actually removed those lines in the other patch set.

While I'm looking forward to the extra data to the OPP nodes, I don't think the amount of properties should determine whether it should have a separator line or not.

My 0.02

Cheers,
Diederik

Dragan Simic

author

2024-10-12 20:20 UTC #5 lore raw

Re: [PATCH 1/3] arm64: dts: rockchip: Update CPU OPP voltages in RK356x SoC dtsi

Hello Diederik,

Quoted 76 lines · Diederik de Haas

Quoted 75 lines · Dragan Simic
Quoted 73 lines · Diederik de Haas
Quoted 58 lines · Dragan Simic
Update the lower/upper voltage limits and the exact voltages for the Rockchip
RK356x CPU OPPs, using the most conservative values (i.e. the highest per-OPP
voltages) found in the vendor kernel source. [1]
Using the most conservative per-OPP voltages ensures reliable CPU operation
regardless of the actual CPU binning, with the downside of possibly using
a bit more power for the CPU cores than absolutely needed.
Additionally, fill in the missing "clock-latency-ns" CPU OPP properties, using
the values found in the vendor kernel source. [1]
[1]
https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
Related-to: eb665b1c06bc ("arm64: dts: rockchip: Update GPU OPP voltages in RK356x SoC dtsi")
Signed-off-by Dragan Simic <[email protected]>
---
 arch/arm64/boot/dts/rockchip/rk3568.dtsi |  1 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 18 ++++++++++++------
 2 files changed, 13 insertions(+), 6 deletions(-)
arch/arm64/boot/dts/rockchip/rk3568.dtsi +1 -0
index 0946310e8c12..5c54898f6ed1 100644
@@ -273,6 +273,7 @@ &cpu0_opp_table {
 	opp-1992000000 {
 		opp-hz = /bits/ 64 <1992000000>;
 		opp-microvolt = <1150000 1150000 1150000>;
+		clock-latency-ns = <40000>;
 	};
 };
 
arch/arm64/boot/dts/rockchip/rk356x.dtsi +2 -2
index 0ee0ada6f0ab..534593f2ed0b 100644
@@ -134,39 +134,45 @@ cpu0_opp_table: opp-table-0 {
 
 		opp-408000000 {
 			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
 			clock-latency-ns = <40000>;
 		};
 
 		opp-600000000 {
 			opp-hz = /bits/ 64 <600000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
arch/arm64/boot/dts/rockchip/rk356x.dtsi cpu0_opp_table: opp-table-0 { · line 152
Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk356x.dtsi +3 -1
+			clock-latency-ns = <40000>;
 		};
 
 		opp-816000000 {
 			opp-hz = /bits/ 64 <816000000>;
-			opp-microvolt = <900000 900000 1150000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
 			opp-suspend;
 		};
While it felt a bit much to send a patch just to remove the blank lines between the opp nodes, this sounds like an excellent opportunity to make it consistent with the opp list in other DT files?

Quoted 7 lines

Quoted 4 lines
Actually, my plan is to work on the SoC binning, which will involve touching nearly every OPP in the Rockchip DTs, and will add much more data to each OPP node. Thus, having empty lines as the separators between the OPP nodes is something we should actually want, because
As indicated in the "arm64: dts: rockchip: Add dtsi file for RK3399S SoC variant" patch series, I do prefer the separator lines ...

Oh, I also prefer them. I just opted for introducing fewer changes in the RK3399S patch series, to keep the size of the series smaller, and to end up with easier diffing of the SoC variant dtsi files.

Quoted 9 lines

Quoted 7 lines
not having them will actually reduce the readability after the size of the individual OPP nodes is increased.
That's the reason why I opted for having the separator lines in this patch series, i.e. because having them everywhere should be the final outcome, and because in this case they were already present where the OPPs were moved or copied from.
... but you actually removed those lines in the other patch set.

Well, I didn't remove them in place, but en route to another, much larger file, :) which originally didn't have them. As described above, that was my choice to keep the things a bit more consistent (in the "RK3399 way"), and to reduce the amount of "code churn" a bit. I'll try to explain it further below.

Quoted 3 lines

While I'm looking forward to the extra data to the OPP nodes, I don't think the amount of properties should determine whether it should have a separator line or not.

True, the size of the node shouldn't be the determining factor. The reason why I emphasized the node size was because other people may be a bit "allergic" to whitespace changes and such "cosmetic" code layout changes, so justifying such changes can only help.

See, just as you're "triggered" by whitespace inconsistency, some
other people may be "triggered" by cosmetic code changes. It's
quite tough to strike some kind of balance there. :)

Dragan Simic

author

2024-10-12 17:04 UTC #6 lore raw

PATCH 2/3 arm64: dts: rockchip: Prepare RK356x SoC dtsi files for per-variant OPPs

In reply to Dragan Simic

Rename the Rockchip RK356x SoC dtsi files and, consequently, adjust their contents appropriately, to prepare them for the ability to specify different CPU and GPU OPPs for each of the supported RK356x SoC variants.

The first new RK356x SoC variant to be introduced is the RK3566T, which the Pine64 Quartz64 Zero SBC is officially based on. [1] Some other SBCs are also based on the RK3566T variant, including Radxa ROCK 3C and ZERO 3E/3W, but the slight trouble is that Radxa doesn't state that officially. Though, it's rather easy to spot the RK3566T on such boards, because their official specifications state that the maximum frequency for the Cortex-A55 cores is lower than the "full-fat" RK3566's 1.8 GHz. [2][3][4]

These changes follow the approach used for the Rockchip RK3588 SoC variants, which was introduced and described further in commit def88eb4d836 ("arm64:
dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs"). Please see that commit for a more detailed explanation.

No functional changes are introduced, which was validated by decompiling and comparing all affected board dtb files before and after these changes. In more detail, the affected dtb files have some of their blocks shuffled around a bit and some of their phandles have different values, as a result of the changes to the order in which the building blocks from the parent dtsi files are included, but they effectively remain the same as the originals.

[1] https://wiki.pine64.org/wiki/Quartz64
[2] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[3] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf

Related-to: def88eb4d836 ("arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs")

Signed-off-by Dragan Simic <[email protected]>

---
 .../{rk3566.dtsi => rk3566-base.dtsi}         |   2 +-
 arch/arm64/boot/dts/rockchip/rk3566.dtsi      | 116 ++++++++++++++----
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      | 114 +++++++++++++++--
 .../{rk356x.dtsi => rk356x-base.dtsi}         |  87 -------------
 4 files changed, 202 insertions(+), 117 deletions(-)
 copy arch/arm64/boot/dts/rockchip/{rk3566.dtsi => rk3566-base.dtsi} (95%)
 rename arch/arm64/boot/dts/rockchip/{rk356x.dtsi => rk356x-base.dtsi} (96%)

arch/arm64/boot/dts/rockchip/rk3566-base.dtsi renamed from arch/arm64/boot/dts/rockchip/rk3566.dtsi +1 -1

similarity index 95%
copy from arch/arm64/boot/dts/rockchip/rk3566.dtsi
copy to arch/arm64/boot/dts/rockchip/rk3566-base.dtsi
index 6c4b17d27bdc..e56e0b6ba941 100644
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 
-#include "rk356x.dtsi"
+#include "rk356x-base.dtsi"
 
 / {
 	compatible = "rockchip,rk3566";

arch/arm64/boot/dts/rockchip/rk3566.dtsi +94 ~~-22~~

129 lines not on this page · raw message

arch/arm64/boot/dts/rockchip/rk3568.dtsi +107 -7

130 lines not on this page · raw message

arch/arm64/boot/dts/rockchip/rk356x-base.dtsi renamed from arch/arm64/boot/dts/rockchip/rk356x.dtsi +0 ~~-87~~

129 lines not on this page · raw message

Diederik de Haas

2024-10-12 19:41 UTC #7 lore raw

Re: [PATCH 2/3] arm64: dts: rockchip: Prepare RK356x SoC dtsi files for per-variant OPPs

Hi Dragan,

Quoted 11 lines · Dragan Simic

Rename the Rockchip RK356x SoC dtsi files and, consequently, adjust their contents appropriately, to prepare them for the ability to specify different CPU and GPU OPPs for each of the supported RK356x SoC variants.
The first new RK356x SoC variant to be introduced is the RK3566T, which the Pine64 Quartz64 Zero SBC is officially based on. [1] Some other SBCs are also based on the RK3566T variant, including Radxa ROCK 3C and ZERO 3E/3W, but the slight trouble is that Radxa doesn't state that officially. Though, it's rather easy to spot the RK3566T on such boards, because their official specifications state that the maximum frequency for the Cortex-A55 cores is lower than the "full-fat" RK3566's 1.8 GHz. [2][3][4]

I think we changed terminology from "full-fat" to something else in the rk3588 variant? Would be nice to be consisten.

Quoted 6 lines

These changes follow the approach used for the Rockchip RK3588 SoC variants, which was introduced and described further in commit def88eb4d836 ("arm64:
dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs"). Please see that commit for a more detailed explanation.
No functional changes are introduced, which was validated by decompiling and

No functional changes ...

Quoted 61 lines

comparing all affected board dtb files before and after these changes. In more detail, the affected dtb files have some of their blocks shuffled around a bit and some of their phandles have different values, as a result of the changes to the order in which the building blocks from the parent dtsi files are included, but they effectively remain the same as the originals.
[1] https://wiki.pine64.org/wiki/Quartz64
[2] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[3] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
Related-to: def88eb4d836 ("arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs")
Signed-off-by Dragan Simic <[email protected]>
---
 .../{rk3566.dtsi => rk3566-base.dtsi}         |   2 +-
 arch/arm64/boot/dts/rockchip/rk3566.dtsi      | 116 ++++++++++++++----
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      | 114 +++++++++++++++--
 .../{rk356x.dtsi => rk356x-base.dtsi}         |  87 -------------
 4 files changed, 202 insertions(+), 117 deletions(-)
 copy arch/arm64/boot/dts/rockchip/{rk3566.dtsi => rk3566-base.dtsi} (95%)
 rename arch/arm64/boot/dts/rockchip/{rk356x.dtsi => rk356x-base.dtsi} (96%)
arch/arm64/boot/dts/rockchip/rk3566-base.dtsi renamed from arch/arm64/boot/dts/rockchip/rk3566.dtsi +1 -1
similarity index 95%
copy from arch/arm64/boot/dts/rockchip/rk3566.dtsi
copy to arch/arm64/boot/dts/rockchip/rk3566-base.dtsi
index 6c4b17d27bdc..e56e0b6ba941 100644
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 
-#include "rk356x.dtsi"
+#include "rk356x-base.dtsi"
 
 / {
 	compatible = "rockchip,rk3566";
arch/arm64/boot/dts/rockchip/rk3566.dtsi +13 -2
index 6c4b17d27bdc..3fcca79279f7 100644
@@ -1,35 +1,107 @@
 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 
-#include "rk356x.dtsi"
+#include "rk3566-base.dtsi"
 
 / {
-	compatible = "rockchip,rk3566";
+	cpu0_opp_table: opp-table-0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 27

Quoted 10 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi +10 -0

+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+			opp-suspend;
+		};

Just like with patch 1 of this series, drop the blank line?

Quoted 53 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi +53 -0

+
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1025000 1025000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1608000000 {
+			opp-hz = /bits/ 64 <1608000000>;
+			opp-microvolt = <1100000 1100000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1150000 1150000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+	};
+
+	gpu_opp_table: opp-table-1 {
+		compatible = "operating-points-v2";
+
+		opp-200000000 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <900000 900000 1000000>;
+		};
+
+		opp-700000000 {
+			opp-hz = /bits/ 64 <700000000>;
+			opp-microvolt = <950000 950000 1000000>;
+		};

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 10

Quoted 10 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi +6 -2

+
+		opp-800000000 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-microvolt = <1000000 1000000 1000000>;
+		};
+	};
 };
 
-&pipegrf {
-	compatible = "rockchip,rk3566-pipe-grf", "syscon";

This seems unrelated?

Quoted 5 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi +2 -1
+&cpu0 {
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 
-&power {

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 23

Quoted 10 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi +0 ~~-10~~

-	power-domain@RK3568_PD_PIPE {
-		reg = <RK3568_PD_PIPE>;
-		clocks = <&cru PCLK_PIPE>;
-		pm_qos = <&qos_pcie2x1>,
-			 <&qos_sata1>,
-			 <&qos_sata2>,
-			 <&qos_usb3_0>,
-			 <&qos_usb3_1>;
-		#power-domain-cells = <0>;
-	};

This seems unrelated to me and possibly a functional change? If this was intended, then a description in the commit message would be nice why this is appropriate and possibly moved to a separate patch?

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 30

Quoted 13 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi +6 -5

+&cpu1 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 
-&usb_host0_xhci {
-	phys = <&usb2phy0_otg>;
-	phy-names = "usb2-phy";
-	extcon = <&usb2phy0>;
-	maximum-speed = "high-speed";

This also looks unrelated and a functional change?

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 34

Quoted 6 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi +2 -2

+&cpu3 {
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 
-&vop {
-	compatible = "rockchip,rk3566-vop";

This also looks unrelated?

Cheers,
Diederik

Quoted 287 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi +2 -0

+&gpu {
+	operating-points-v2 = <&gpu_opp_table>;
 };

arch/arm64/boot/dts/rockchip/rk3568.dtsi +107 -7

index 5c54898f6ed1..ecaefe208e3e 100644
@@ -3,11 +3,99 @@
  * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
  */
 
-#include "rk356x.dtsi"
+#include "rk356x-base.dtsi"
 
 / {
 	compatible = "rockchip,rk3568";
 
+	cpu0_opp_table: opp-table-0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+			opp-suspend;
+		};
+
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1025000 1025000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1608000000 {
+			opp-hz = /bits/ 64 <1608000000>;
+			opp-microvolt = <1100000 1100000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1150000 1150000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1992000000 {
+			opp-hz = /bits/ 64 <1992000000>;
+			opp-microvolt = <1150000 1150000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+	};
+
+	gpu_opp_table: opp-table-1 {
+		compatible = "operating-points-v2";
+
+		opp-200000000 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <900000 900000 1000000>;
+		};
+
+		opp-700000000 {
+			opp-hz = /bits/ 64 <700000000>;
+			opp-microvolt = <950000 950000 1000000>;
+		};
+
+		opp-800000000 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-microvolt = <1000000 1000000 1000000>;
+		};
+	};
+
 	sata0: sata@fc000000 {
 		compatible = "rockchip,rk3568-dwc-ahci", "snps,dwc-ahci";
 		reg = <0 0xfc000000 0 0x1000>;

@@ -269,12 +357,24 @@ combphy0: phy@fe820000 {
 	};
 };
 
-&cpu0_opp_table {
-	opp-1992000000 {
-		opp-hz = /bits/ 64 <1992000000>;
-		opp-microvolt = <1150000 1150000 1150000>;
-		clock-latency-ns = <40000>;
-	};
+&cpu0 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu1 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu3 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&gpu {
+	operating-points-v2 = <&gpu_opp_table>;
 };
 
 &pipegrf {

arch/arm64/boot/dts/rockchip/rk356x-base.dtsi renamed from arch/arm64/boot/dts/rockchip/rk356x.dtsi +0 ~~-87~~

similarity index 96%
rename from arch/arm64/boot/dts/rockchip/rk356x.dtsi
rename to arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
index 534593f2ed0b..62be06f3b863 100644
@@ -56,7 +56,6 @@ cpu0: cpu@0 {
 			clocks = <&scmi_clk 0>;
 			#cooling-cells = <2>;
 			enable-method = "psci";
-			operating-points-v2 = <&cpu0_opp_table>;
 			i-cache-size = <0x8000>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <128>;

@@ -72,7 +71,6 @@ cpu1: cpu@100 {
 			reg = <0x0 0x100>;
 			#cooling-cells = <2>;
 			enable-method = "psci";
-			operating-points-v2 = <&cpu0_opp_table>;
 			i-cache-size = <0x8000>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <128>;

@@ -88,7 +86,6 @@ cpu2: cpu@200 {
 			reg = <0x0 0x200>;
 			#cooling-cells = <2>;
 			enable-method = "psci";
-			operating-points-v2 = <&cpu0_opp_table>;
 			i-cache-size = <0x8000>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <128>;

@@ -104,7 +101,6 @@ cpu3: cpu@300 {
 			reg = <0x0 0x300>;
 			#cooling-cells = <2>;
 			enable-method = "psci";
-			operating-points-v2 = <&cpu0_opp_table>;
 			i-cache-size = <0x8000>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <128>;

@@ -128,54 +124,6 @@ l3_cache: l3-cache {
 		cache-sets = <512>;
 	};
 
-	cpu0_opp_table: opp-table-0 {
-		compatible = "operating-points-v2";
-		opp-shared;
-
-		opp-408000000 {
-			opp-hz = /bits/ 64 <408000000>;
-			opp-microvolt = <850000 850000 1150000>;
-			clock-latency-ns = <40000>;
-		};
-
-		opp-600000000 {
-			opp-hz = /bits/ 64 <600000000>;
-			opp-microvolt = <850000 850000 1150000>;
-			clock-latency-ns = <40000>;
-		};
-
-		opp-816000000 {
-			opp-hz = /bits/ 64 <816000000>;
-			opp-microvolt = <850000 850000 1150000>;
-			clock-latency-ns = <40000>;
-			opp-suspend;
-		};
-
-		opp-1104000000 {
-			opp-hz = /bits/ 64 <1104000000>;
-			opp-microvolt = <900000 900000 1150000>;
-			clock-latency-ns = <40000>;
-		};
-
-		opp-1416000000 {
-			opp-hz = /bits/ 64 <1416000000>;
-			opp-microvolt = <1025000 1025000 1150000>;
-			clock-latency-ns = <40000>;
-		};
-
-		opp-1608000000 {
-			opp-hz = /bits/ 64 <1608000000>;
-			opp-microvolt = <1100000 1100000 1150000>;
-			clock-latency-ns = <40000>;
-		};
-
-		opp-1800000000 {
-			opp-hz = /bits/ 64 <1800000000>;
-			opp-microvolt = <1150000 1150000 1150000>;
-			clock-latency-ns = <40000>;
-		};
-	};
-
 	display_subsystem: display-subsystem {
 		compatible = "rockchip,display-subsystem";
 		ports = <&vop_out>;

@@ -196,40 +144,6 @@ scmi_clk: protocol@14 {
 		};
 	};
 
-	gpu_opp_table: opp-table-1 {
-		compatible = "operating-points-v2";
-
-		opp-200000000 {
-			opp-hz = /bits/ 64 <200000000>;
-			opp-microvolt = <850000 850000 1000000>;
-		};
-
-		opp-300000000 {
-			opp-hz = /bits/ 64 <300000000>;
-			opp-microvolt = <850000 850000 1000000>;
-		};
-
-		opp-400000000 {
-			opp-hz = /bits/ 64 <400000000>;
-			opp-microvolt = <850000 850000 1000000>;
-		};
-
-		opp-600000000 {
-			opp-hz = /bits/ 64 <600000000>;
-			opp-microvolt = <900000 900000 1000000>;
-		};
-
-		opp-700000000 {
-			opp-hz = /bits/ 64 <700000000>;
-			opp-microvolt = <950000 950000 1000000>;
-		};
-
-		opp-800000000 {
-			opp-hz = /bits/ 64 <800000000>;
-			opp-microvolt = <1000000 1000000 1000000>;
-		};
-	};
-
 	hdmi_sound: hdmi-sound {
 		compatible = "simple-audio-card";
 		simple-audio-card,name = "HDMI";

@@ -635,7 +549,6 @@ gpu: gpu@fde60000 {
 		clocks = <&scmi_clk 1>, <&cru CLK_GPU>;
 		clock-names = "gpu", "bus";
 		#cooling-cells = <2>;
-		operating-points-v2 = <&gpu_opp_table>;
 		power-domains = <&power RK3568_PD_GPU>;
 		status = "disabled";
 	};

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Dragan Simic

author

2024-10-12 20:01 UTC #8 lore raw

Re: [PATCH 2/3] arm64: dts: rockchip: Prepare RK356x SoC dtsi files for per-variant OPPs

Hello Diederik,

Quoted 13 lines · Diederik de Haas

Quoted 11 lines · Dragan Simic
Rename the Rockchip RK356x SoC dtsi files and, consequently, adjust their contents appropriately, to prepare them for the ability to specify different CPU and GPU OPPs for each of the supported RK356x SoC variants.
The first new RK356x SoC variant to be introduced is the RK3566T, which the Pine64 Quartz64 Zero SBC is officially based on. [1] Some other SBCs are also based on the RK3566T variant, including Radxa ROCK 3C and ZERO 3E/3W, but the slight trouble is that Radxa doesn't state that officially. Though, it's rather easy to spot the RK3566T on such boards, because their official specifications state that the maximum frequency for the Cortex-A55 cores is lower than the "full-fat" RK3566's 1.8 GHz. [2][3][4]

Quoted 2 lines

I think we changed terminology from "full-fat" to something else in the rk3588 variant? Would be nice to be consisten.

Back then, it was about the naming of one of the dtsi files, [*] not about using "full-fat" in the commit description. Using "full-fat" in one of the file names was just part of the RFC, as a temporary solution. OTOH, frankly, I don't feel like using "full-fat" in this commit description is inappropriate or inconsistent.

[*] https://lore.kernel.org/linux-rockchip/673dcf47596e7bc8ba065034e339bb1bbf9cdcb0.1716948159.git.dsimic@manjaro.org/T/#u

Quoted 8 lines

Quoted 6 lines
These changes follow the approach used for the Rockchip RK3588 SoC variants, which was introduced and described further in commit def88eb4d836 ("arm64:
dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs"). Please see that commit for a more detailed explanation.
No functional changes are introduced, which was validated by decompiling and
No functional changes ...

This will be covered later in my response...

Quoted 69 lines

Quoted 69 lines
comparing all affected board dtb files before and after these changes.
In
more detail, the affected dtb files have some of their blocks shuffled around a bit and some of their phandles have different values, as a result of the changes to the order in which the building blocks from the parent dtsi files are included, but they effectively remain the same as the originals.
[1] https://wiki.pine64.org/wiki/Quartz64
[2] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[3] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
Related-to: def88eb4d836 ("arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs")
Signed-off-by Dragan Simic <[email protected]>
---
 .../{rk3566.dtsi => rk3566-base.dtsi}         |   2 +-
 arch/arm64/boot/dts/rockchip/rk3566.dtsi      | 116 
++++++++++++++----
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      | 114 +++++++++++++++--
 .../{rk356x.dtsi => rk356x-base.dtsi}         |  87 -------------
 4 files changed, 202 insertions(+), 117 deletions(-)
 copy arch/arm64/boot/dts/rockchip/{rk3566.dtsi => rk3566-base.dtsi} 
(95%)
 rename arch/arm64/boot/dts/rockchip/{rk356x.dtsi => rk356x-base.dtsi} 
(96%)
arch/arm64/boot/dts/rockchip/rk3566-base.dtsi renamed from arch/arm64/boot/dts/rockchip/rk3566.dtsi +1 -1
similarity index 95%
copy from arch/arm64/boot/dts/rockchip/rk3566.dtsi
copy to arch/arm64/boot/dts/rockchip/rk3566-base.dtsi
index 6c4b17d27bdc..e56e0b6ba941 100644
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 
-#include "rk356x.dtsi"
+#include "rk356x-base.dtsi"
 
 / {
 	compatible = "rockchip,rk3566";
arch/arm64/boot/dts/rockchip/rk3566.dtsi +17 -2
index 6c4b17d27bdc..3fcca79279f7 100644
@@ -1,35 +1,107 @@
 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 
-#include "rk356x.dtsi"
+#include "rk3566-base.dtsi"
 
 / {
-	compatible = "rockchip,rk3566";
+	cpu0_opp_table: opp-table-0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+

Quoted 8 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 27
Quoted 6 lines
arch/arm64/boot/dts/rockchip/rk3566.dtsi +6 -0
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+			opp-suspend;
+		};
Just like with patch 1 of this series, drop the blank line?

I believe I've already explained the reasoning behind that. [**]

[**] https://lore.kernel.org/linux-rockchip/[email protected]/

Quoted 61 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi +59 -0

+
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1025000 1025000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1608000000 {
+			opp-hz = /bits/ 64 <1608000000>;
+			opp-microvolt = <1100000 1100000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1150000 1150000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+	};
+
+	gpu_opp_table: opp-table-1 {
+		compatible = "operating-points-v2";
+
+		opp-200000000 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <900000 900000 1000000>;
+		};
+
+		opp-700000000 {
+			opp-hz = /bits/ 64 <700000000>;
+			opp-microvolt = <950000 950000 1000000>;
+		};
+
+		opp-800000000 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-microvolt = <1000000 1000000 1000000>;
+		};
+	};
 };

Quoted 4 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 10
Quoted 2 lines
arch/arm64/boot/dts/rockchip/rk3566.dtsi +0 -2
-&pipegrf {
-	compatible = "rockchip,rk3566-pipe-grf", "syscon";
This seems unrelated?

Yes, it looks completely out of place, but it's just the way this diff ended up looking like. It's actually fine.

Quoted 4 lines

Quoted 4 lines
arch/arm64/boot/dts/rockchip/rk3566.dtsi +2 -0
+&cpu0 {
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 

Quoted 15 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 23
Quoted 11 lines
arch/arm64/boot/dts/rockchip/rk3566.dtsi +0 ~~-11~~
-&power {
-	power-domain@RK3568_PD_PIPE {
-		reg = <RK3568_PD_PIPE>;
-		clocks = <&cru PCLK_PIPE>;
-		pm_qos = <&qos_pcie2x1>,
-			 <&qos_sata1>,
-			 <&qos_sata2>,
-			 <&qos_usb3_0>,
-			 <&qos_usb3_1>;
-		#power-domain-cells = <0>;
-	};
This seems unrelated to me and possibly a functional change? If this was intended, then a description in the commit message would be nice why this is appropriate and possibly moved to a separate patch?

Just another instance of the diff ending up looking strange, while there are actually no such changes.

Quoted 8 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi +6 -0

+&cpu1 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+	operating-points-v2 = <&cpu0_opp_table>;
 };

Quoted 7 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 30
Quoted 5 lines
arch/arm64/boot/dts/rockchip/rk3566.dtsi +0 -5
-&usb_host0_xhci {
-	phys = <&usb2phy0_otg>;
-	phy-names = "usb2-phy";
-	extcon = <&usb2phy0>;
-	maximum-speed = "high-speed";
This also looks unrelated and a functional change?

Already explained above.

Quoted 8 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 34
Quoted 6 lines
arch/arm64/boot/dts/rockchip/rk3566.dtsi +2 -2
+&cpu3 {
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 
-&vop {
-	compatible = "rockchip,rk3566-vop";
This also looks unrelated?

Already explained above.

Diederik de Haas

2024-10-19 18:09 UTC #9 lore raw

Re: [PATCH 2/3] arm64: dts: rockchip: Prepare RK356x SoC dtsi files for per-variant OPPs

In reply to Diederik de Haas

Hi Dragan,

Quoted 43 lines · Diederik de Haas

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 10
Quoted 3 lines · Dragan Simic
-&pipegrf {
arch/arm64/boot/dts/rockchip/rk3566.dtsi +0 -1
-	compatible = "rockchip,rk3566-pipe-grf", "syscon";
This seems unrelated?
Quoted 5 lines
+&cpu0 {
arch/arm64/boot/dts/rockchip/rk3566.dtsi +1 -1
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 
-&power {
arch/arm64/boot/dts/rockchip/rk3566.dtsi line 23
Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3566.dtsi +0 ~~-10~~
-	power-domain@RK3568_PD_PIPE {
-		reg = <RK3568_PD_PIPE>;
-		clocks = <&cru PCLK_PIPE>;
-		pm_qos = <&qos_pcie2x1>,
-			 <&qos_sata1>,
-			 <&qos_sata2>,
-			 <&qos_usb3_0>,
-			 <&qos_usb3_1>;
-		#power-domain-cells = <0>;
-	};
This seems unrelated to me and possibly a functional change? If this was intended, then a description in the commit message would be nice why this is appropriate and possibly moved to a separate patch?
arch/arm64/boot/dts/rockchip/rk3566.dtsi line 30
Quoted 13 lines
+&cpu1 {
arch/arm64/boot/dts/rockchip/rk3566.dtsi +5 -5
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 
-&usb_host0_xhci {
-	phys = <&usb2phy0_otg>;
-	phy-names = "usb2-phy";
-	extcon = <&usb2phy0>;
-	maximum-speed = "high-speed";
This also looks unrelated and a functional change?

Quoted 8 lines

arch/arm64/boot/dts/rockchip/rk3566.dtsi line 34
Quoted 6 lines
+&cpu3 {
arch/arm64/boot/dts/rockchip/rk3566.dtsi +1 -2
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 
-&vop {
-	compatible = "rockchip,rk3566-vop";
This also looks unrelated?

It turns out I was wrong.
The elements I thought were removed, aren't removed.

Sorry for the noise.

Diederik

Dragan Simic

author

2024-10-20 18:04 UTC #10 lore raw

Re: [PATCH 2/3] arm64: dts: rockchip: Prepare RK356x SoC dtsi files for per-variant OPPs

Hello Diederik,

Quoted 53 lines · Diederik de Haas

Quoted 43 lines · Diederik de Haas
arch/arm64/boot/dts/rockchip/rk3566.dtsi line 10
Quoted 3 lines · Dragan Simic
-&pipegrf {
arch/arm64/boot/dts/rockchip/rk3566.dtsi +0 -1
-	compatible = "rockchip,rk3566-pipe-grf", "syscon";
This seems unrelated?
Quoted 5 lines
+&cpu0 {
arch/arm64/boot/dts/rockchip/rk3566.dtsi +1 -1
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 
-&power {
arch/arm64/boot/dts/rockchip/rk3566.dtsi line 23
Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3566.dtsi +0 ~~-10~~
-	power-domain@RK3568_PD_PIPE {
-		reg = <RK3568_PD_PIPE>;
-		clocks = <&cru PCLK_PIPE>;
-		pm_qos = <&qos_pcie2x1>,
-			 <&qos_sata1>,
-			 <&qos_sata2>,
-			 <&qos_usb3_0>,
-			 <&qos_usb3_1>;
-		#power-domain-cells = <0>;
-	};
This seems unrelated to me and possibly a functional change? If this was intended, then a description in the commit message would be nice why this is appropriate and possibly moved to a separate patch?
arch/arm64/boot/dts/rockchip/rk3566.dtsi line 30
Quoted 13 lines
+&cpu1 {
arch/arm64/boot/dts/rockchip/rk3566.dtsi +5 -5
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 
-&usb_host0_xhci {
-	phys = <&usb2phy0_otg>;
-	phy-names = "usb2-phy";
-	extcon = <&usb2phy0>;
-	maximum-speed = "high-speed";
This also looks unrelated and a functional change?
Quoted 8 lines
arch/arm64/boot/dts/rockchip/rk3566.dtsi line 34
Quoted 6 lines
+&cpu3 {
arch/arm64/boot/dts/rockchip/rk3566.dtsi +1 -2
+	operating-points-v2 = <&cpu0_opp_table>;
 };
 
-&vop {
-	compatible = "rockchip,rk3566-vop";
This also looks unrelated?

Quoted 4 lines

It turns out I was wrong.
The elements I thought were removed, aren't removed.
Sorry for the noise.

No worries. I tried to tune and adjust the patch generation parameters as best as possible, but some parts of the produced patches still remained slightly confusing.

By the way, a few months ago there was a discussion on the Git mailing list about making Git perform such parameter adjustment magic itself, which back then seemed like a good idea to me, but after dealing with a few rather complex patches myself, I no longer think that's actually possible.

Dragan Simic

author

2024-10-12 17:04 UTC #11 lore raw

PATCH 3/3 arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variant

In reply to Dragan Simic

Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC. The difference between the RK3566T variant and the "full-fat" RK3566 variant is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of a functional NPU, which we currently don't have to worry about.

Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero SBC, [2] the Radxa ROCK 3C and the Radxa ZERO 3E/3W SBCs. Unfortunately, Radxa doesn't mention the use of RK3566T officially, but its official SBC specifications do state that the maximum frequency for the Cortex-A55 cores on those SBCs is lower than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of the RK3566T SoC variant rather easy. [3][4][5] An additional, helpful cue is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately in its downstream kernel. [6]

The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the vendor kernel source, [1] which uses the values of the "opp-supported-hw" OPP properties to determine which ones are supported on a particular SoC variant. The actual values of the "opp-supported-hw" properties make it rather easy to see what OPPs are supported on the RK3566T SoC variant, but that, rather unfortunately, clashes with the maximum frequencies advertised officially for the Cortex-A55 CPU cores on the above-mentioned SBCs. [2][3][4][5] The vendor kernel source indicates that the maximum frequency for the CPU cores is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Unless that discrepancy is resolved somehow, let's take the safe approach and use the lower maximum frequency for the CPU cores.

Update the dts files of the currently supported RK3566T-based boards to use the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores and the GPUs found on these boards out of their earlier overclocks, but it also means that the officially advertised specifications [2][3][4][5] of the highest supported frequencies for the Cortex-A55 CPU cores on these boards may actually be wrong, as already explained above.

The correctness of the introduced changes was validated by decompiling and comparing all affected board dtb files before and after these changes.

[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
[2] https://wiki.pine64.org/wiki/Quartz64
[3] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[5] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
[6] https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8

Cc TL Lim <[email protected]>

Cc Marek Kraus <[email protected]>

Cc Tom Cubie <[email protected]>

Cc FUKAUMI Naoki <[email protected]>

Helped-by Nicolas Frattaroli <[email protected]>

Helped-by Jonas Karlman <[email protected]>

Signed-off-by Dragan Simic <[email protected]>

---
 .../dts/rockchip/rk3566-radxa-zero-3.dtsi     |  2 +-
 .../boot/dts/rockchip/rk3566-rock-3c.dts      |  2 +-
 arch/arm64/boot/dts/rockchip/rk3566t.dtsi     | 90 +++++++++++++++++++
 3 files changed, 92 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566t.dtsi

arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +1 -1

index de390d92c35e..1ee5d96a46a1 100644
@@ -3,7 +3,7 @@
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"
 
 / {
 	chosen {

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +1 -1

index f2cc086e5001..9a8f4f774dbc 100644
@@ -5,7 +5,7 @@
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/rockchip.h>
 #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"
 
 / {
 	model = "Radxa ROCK 3C";

arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +90 -0

90 lines not on this page · raw message

Diederik de Haas

2024-10-12 19:42 UTC #12 lore raw

Re: [PATCH 3/3] arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variant

Hi Dragan,

Quoted 107 lines · Dragan Simic

Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC. The difference between the RK3566T variant and the "full-fat" RK3566 variant is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of a functional NPU, which we currently don't have to worry about.
Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero SBC, [2] the Radxa ROCK 3C and the Radxa ZERO 3E/3W SBCs. Unfortunately, Radxa doesn't mention the use of RK3566T officially, but its official SBC specifications do state that the maximum frequency for the Cortex-A55 cores on those SBCs is lower than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of the RK3566T SoC variant rather easy. [3][4][5] An additional, helpful cue is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately in its downstream kernel. [6]
The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the vendor kernel source, [1] which uses the values of the "opp-supported-hw" OPP properties to determine which ones are supported on a particular SoC variant. The actual values of the "opp-supported-hw" properties make it rather easy to see what OPPs are supported on the RK3566T SoC variant, but that, rather unfortunately, clashes with the maximum frequencies advertised officially for the Cortex-A55 CPU cores on the above-mentioned SBCs. [2][3][4][5] The vendor kernel source indicates that the maximum frequency for the CPU cores is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Unless that discrepancy is resolved somehow, let's take the safe approach and use the lower maximum frequency for the CPU cores.
Update the dts files of the currently supported RK3566T-based boards to use the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores and the GPUs found on these boards out of their earlier overclocks, but it also means that the officially advertised specifications [2][3][4][5] of the highest supported frequencies for the Cortex-A55 CPU cores on these boards may actually be wrong, as already explained above.
The correctness of the introduced changes was validated by decompiling and comparing all affected board dtb files before and after these changes.
[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
[2] https://wiki.pine64.org/wiki/Quartz64
[3] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[5] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
[6] https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8
Cc TL Lim <[email protected]>
Cc Marek Kraus <[email protected]>
Cc Tom Cubie <[email protected]>
Cc FUKAUMI Naoki <[email protected]>
Helped-by Nicolas Frattaroli <[email protected]>
Helped-by Jonas Karlman <[email protected]>
Signed-off-by Dragan Simic <[email protected]>
---
 .../dts/rockchip/rk3566-radxa-zero-3.dtsi     |  2 +-
 .../boot/dts/rockchip/rk3566-rock-3c.dts      |  2 +-
 arch/arm64/boot/dts/rockchip/rk3566t.dtsi     | 90 +++++++++++++++++++
 3 files changed, 92 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566t.dtsi
arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +1 -1
index de390d92c35e..1ee5d96a46a1 100644
@@ -3,7 +3,7 @@
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"
 
 / {
 	chosen {
arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +1 -1
index f2cc086e5001..9a8f4f774dbc 100644
@@ -5,7 +5,7 @@
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/rockchip.h>
 #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"
 
 / {
 	model = "Radxa ROCK 3C";
arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +18 -0
new file mode 100644
index 000000000000..cd89bd3b125b
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3566-base.dtsi"
+
+/ {
+	cpu0_opp_table: opp-table-0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <850000 850000 1150000>;

arch/arm64/boot/dts/rockchip/rk3566t.dtsi line 28

Quoted 10 lines

arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +10 -0

+			clock-latency-ns = <40000>;
+		};
+
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+			opp-suspend;
+		};
+

For consistency, no blank lines between the opp nodes would be nice ;)

Cheers,
Diederik

Quoted 67 lines

arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +62 -0

+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1025000 1025000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+	};
+
+	gpu_opp_table: opp-table-1 {
+		compatible = "operating-points-v2";
+
+		opp-200000000 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <900000 900000 1000000>;
+		};
+
+		opp-700000000 {
+			opp-hz = /bits/ 64 <700000000>;
+			opp-microvolt = <950000 950000 1000000>;
+		};
+	};
+};
+
+&cpu0 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu1 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu3 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&gpu {
+	operating-points-v2 = <&gpu_opp_table>;
+};

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Dragan Simic

author

2024-10-12 20:07 UTC #13 lore raw

Re: [PATCH 3/3] arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variant

Hello Diederik,

Quoted 114 lines · Diederik de Haas

Quoted 113 lines · Dragan Simic
Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC. The difference between the RK3566T variant and the "full-fat" RK3566 variant is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of a functional NPU, which we currently don't have to worry about.
Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero SBC, [2] the Radxa ROCK 3C and the Radxa ZERO 3E/3W SBCs. Unfortunately, Radxa doesn't mention the use of RK3566T officially, but its official SBC specifications do state that the maximum frequency for the Cortex-A55 cores on those SBCs is lower than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of the RK3566T SoC variant rather easy. [3][4][5] An additional, helpful cue is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately in its downstream kernel. [6]
The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the vendor kernel source, [1] which uses the values of the "opp-supported-hw" OPP properties to determine which ones are supported on a particular SoC variant. The actual values of the "opp-supported-hw" properties make it rather easy to see what OPPs are supported on the RK3566T SoC variant, but that, rather unfortunately, clashes with the maximum frequencies advertised officially for the Cortex-A55 CPU cores on the above-mentioned SBCs. [2][3][4][5]
The
vendor kernel source indicates that the maximum frequency for the CPU cores is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Unless that discrepancy is resolved somehow, let's take the safe approach and use the lower maximum frequency for the CPU cores.
Update the dts files of the currently supported RK3566T-based boards to use the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores and the GPUs found on these boards out of their earlier overclocks, but it also means that the officially advertised specifications [2][3][4][5] of the highest supported frequencies for the Cortex-A55 CPU cores on these boards may actually be wrong, as already explained above.
The correctness of the introduced changes was validated by decompiling and comparing all affected board dtb files before and after these changes.
[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
[2] https://wiki.pine64.org/wiki/Quartz64
[3] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[5] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
[6] https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8
Cc TL Lim <[email protected]>
Cc Marek Kraus <[email protected]>
Cc Tom Cubie <[email protected]>
Cc FUKAUMI Naoki <[email protected]>
Helped-by Nicolas Frattaroli <[email protected]>
Helped-by Jonas Karlman <[email protected]>
Signed-off-by Dragan Simic <[email protected]>
---
 .../dts/rockchip/rk3566-radxa-zero-3.dtsi     |  2 +-
 .../boot/dts/rockchip/rk3566-rock-3c.dts      |  2 +-
 arch/arm64/boot/dts/rockchip/rk3566t.dtsi     | 90 
+++++++++++++++++++
 3 files changed, 92 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3566t.dtsi
arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +1 -1
index de390d92c35e..1ee5d96a46a1 100644
@@ -3,7 +3,7 @@
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"
 
 / {
 	chosen {
arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +1 -1
index f2cc086e5001..9a8f4f774dbc 100644
@@ -5,7 +5,7 @@
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/rockchip.h>
 #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"
 
 / {
 	model = "Radxa ROCK 3C";
arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +22 -0
new file mode 100644
index 000000000000..cd89bd3b125b
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3566-base.dtsi"
+
+/ {
+	cpu0_opp_table: opp-table-0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-816000000 {

Quoted 8 lines

arch/arm64/boot/dts/rockchip/rk3566t.dtsi line 28
Quoted 6 lines
arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +6 -0
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+			opp-suspend;
+		};
+
For consistency, no blank lines between the opp nodes would be nice ;)

I hope the way I already explained the background [*] provides a satisfactory explanation for this choice. :)

[*] https://lore.kernel.org/linux-rockchip/[email protected]/

FUKAUMI Naoki

2024-10-14 04:38 UTC #14 lore raw

Re: [PATCH 3/3] arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variant

In reply to Dragan Simic

Hi,

Quoted 62 lines · Dragan Simic

Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC. The difference between the RK3566T variant and the "full-fat" RK3566 variant is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of a functional NPU, which we currently don't have to worry about.
Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero SBC, [2] the Radxa ROCK 3C and the Radxa ZERO 3E/3W SBCs. Unfortunately, Radxa doesn't mention the use of RK3566T officially, but its official SBC specifications do state that the maximum frequency for the Cortex-A55 cores on those SBCs is lower than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of the RK3566T SoC variant rather easy. [3][4][5] An additional, helpful cue is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately in its downstream kernel. [6]
The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the vendor kernel source, [1] which uses the values of the "opp-supported-hw" OPP properties to determine which ones are supported on a particular SoC variant. The actual values of the "opp-supported-hw" properties make it rather easy to see what OPPs are supported on the RK3566T SoC variant, but that, rather unfortunately, clashes with the maximum frequencies advertised officially for the Cortex-A55 CPU cores on the above-mentioned SBCs. [2][3][4][5] The vendor kernel source indicates that the maximum frequency for the CPU cores is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Unless that discrepancy is resolved somehow, let's take the safe approach and use the lower maximum frequency for the CPU cores.
Update the dts files of the currently supported RK3566T-based boards to use the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores and the GPUs found on these boards out of their earlier overclocks, but it also means that the officially advertised specifications [2][3][4][5] of the highest supported frequencies for the Cortex-A55 CPU cores on these boards may actually be wrong, as already explained above.
The correctness of the introduced changes was validated by decompiling and comparing all affected board dtb files before and after these changes.
[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
[2] https://wiki.pine64.org/wiki/Quartz64
[3] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[5] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
[6] https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8
Cc TL Lim <[email protected]>
Cc Marek Kraus <[email protected]>
Cc Tom Cubie <[email protected]>
Cc FUKAUMI Naoki <[email protected]>
Helped-by Nicolas Frattaroli <[email protected]>
Helped-by Jonas Karlman <[email protected]>
Signed-off-by Dragan Simic <[email protected]>
---
  .../dts/rockchip/rk3566-radxa-zero-3.dtsi     |  2 +-
  .../boot/dts/rockchip/rk3566-rock-3c.dts      |  2 +-
  arch/arm64/boot/dts/rockchip/rk3566t.dtsi     | 90 +++++++++++++++++++
  3 files changed, 92 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3566t.dtsi
arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +0 -0
index de390d92c35e..1ee5d96a46a1 100644

arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi line 6

Quoted 5 lines

arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +1 -1

@@ -3,7 +3,7 @@
  #include <dt-bindings/gpio/gpio.h>
  #include <dt-bindings/leds/common.h>
  #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"

could you drop this change for now?

We(Radxa) think we use RK3566.

and vendor kernel[6] refers efuse value to determine it's -T or not. can you do similar way?

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts line 8

Quoted 12 lines

arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +0 -0

  / {
  	chosen {

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +1 -1

index f2cc086e5001..9a8f4f774dbc 100644
@@ -5,7 +5,7 @@
  #include <dt-bindings/leds/common.h>
  #include <dt-bindings/pinctrl/rockchip.h>
  #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"

same here.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

Quoted 98 lines

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +0 -0

  / {
  	model = "Radxa ROCK 3C";

arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +90 -0

new file mode 100644
index 000000000000..cd89bd3b125b
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3566-base.dtsi"
+
+/ {
+	cpu0_opp_table: opp-table-0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+			opp-suspend;
+		};
+
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1025000 1025000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+	};
+
+	gpu_opp_table: opp-table-1 {
+		compatible = "operating-points-v2";
+
+		opp-200000000 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <900000 900000 1000000>;
+		};
+
+		opp-700000000 {
+			opp-hz = /bits/ 64 <700000000>;
+			opp-microvolt = <950000 950000 1000000>;
+		};
+	};
+};
+
+&cpu0 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu1 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu3 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&gpu {
+	operating-points-v2 = <&gpu_opp_table>;
+};

Dragan Simic

author

2024-10-14 05:16 UTC #15 lore raw

Re: [PATCH 3/3] arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variant

Hello Fukaumi,

Quoted 60 lines · FUKAUMI Naoki

Quoted 59 lines · Dragan Simic
Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC. The difference between the RK3566T variant and the "full-fat" RK3566 variant is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of a functional NPU, which we currently don't have to worry about.
Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero SBC, [2] the Radxa ROCK 3C and the Radxa ZERO 3E/3W SBCs. Unfortunately, Radxa doesn't mention the use of RK3566T officially, but its official SBC specifications do state that the maximum frequency for the Cortex-A55 cores on those SBCs is lower than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of the RK3566T SoC variant rather easy. [3][4][5] An additional, helpful cue is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately in its downstream kernel. [6]
The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the vendor kernel source, [1] which uses the values of the "opp-supported-hw" OPP properties to determine which ones are supported on a particular SoC variant. The actual values of the "opp-supported-hw" properties make it rather easy to see what OPPs are supported on the RK3566T SoC variant, but that, rather unfortunately, clashes with the maximum frequencies advertised officially for the Cortex-A55 CPU cores on the above-mentioned SBCs. [2][3][4][5]
The
vendor kernel source indicates that the maximum frequency for the CPU cores is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Unless that discrepancy is resolved somehow, let's take the safe approach and use the lower maximum frequency for the CPU cores.
Update the dts files of the currently supported RK3566T-based boards to use the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores and the GPUs found on these boards out of their earlier overclocks, but it also means that the officially advertised specifications [2][3][4][5] of the highest supported frequencies for the Cortex-A55 CPU cores on these boards may actually be wrong, as already explained above.
The correctness of the introduced changes was validated by decompiling and comparing all affected board dtb files before and after these changes.
[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
[2] https://wiki.pine64.org/wiki/Quartz64
[3] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[5] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
[6] https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8
Cc TL Lim <[email protected]>
Cc Marek Kraus <[email protected]>
Cc Tom Cubie <[email protected]>
Cc FUKAUMI Naoki <[email protected]>
Helped-by Nicolas Frattaroli <[email protected]>
Helped-by Jonas Karlman <[email protected]>
Signed-off-by Dragan Simic <[email protected]>
---
  .../dts/rockchip/rk3566-radxa-zero-3.dtsi     |  2 +-
  .../boot/dts/rockchip/rk3566-rock-3c.dts      |  2 +-
  arch/arm64/boot/dts/rockchip/rk3566t.dtsi     | 90 
+++++++++++++++++++
  3 files changed, 92 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3566t.dtsi

Quoted 12 lines

arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi line 6
Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +1 -1
index de390d92c35e..1ee5d96a46a1 100644
@@ -3,7 +3,7 @@
  #include <dt-bindings/gpio/gpio.h>
  #include <dt-bindings/leds/common.h>
  #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"
could you drop this change for now?

This patch is also going to be used for the upcoming board dts for the Pine64 Quartz64 Zero, so there's no need for dropping it. The Quartz64 Zero definitely uses the RK3566T.

Quoted 1 line

We (Radxa) think we use RK3566.

Well, the available documentation for the Radxa ROCK 3C and ZERO 3E/3W boards doesn't say so; instead, everything points to the RK3566T being used. The referenced commit in the Radxa downstream kernel also indicates that RK3566T is used at least on some boards.

Also, some independent testing, by reading the efuses, has showed that at least some ROCK 3C and ZERO 3E/3W boards actually have the RK3566T, which means that we should handle them all as having the RK3566T, to avoid overclocking the CPU cores and the GPU. I'll get back to this below.

Quoted 2 lines

and vendor kernel[6] refers efuse value to determine it's -T or not. can you do similar way?

Unfortunately not at the moment, because that would require major changes to the way OPPs are handled in the upstream kernel. Maybe we can do that at some point in the future, as part of my planned work on supporting SoC binning.

With that in place, hopefully, we could handle any ROCK 3C and ZERO 3E/3W boards that actually have the "full-fat" RK3566 variant as such, but until then, it's much safer to treat them all as having the RK3566T, and avoid the possible overclocking.

Quoted 119 lines

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts line 8

Quoted 12 lines

arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +0 -0

  / {
  	chosen {

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +1 -1

index f2cc086e5001..9a8f4f774dbc 100644
@@ -5,7 +5,7 @@
  #include <dt-bindings/leds/common.h>
  #include <dt-bindings/pinctrl/rockchip.h>
  #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"

same here.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

Quoted 98 lines

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +0 -0

  / {
  	model = "Radxa ROCK 3C";

arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +90 -0

new file mode 100644
index 000000000000..cd89bd3b125b
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3566-base.dtsi"
+
+/ {
+	cpu0_opp_table: opp-table-0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+			opp-suspend;
+		};
+
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1025000 1025000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+	};
+
+	gpu_opp_table: opp-table-1 {
+		compatible = "operating-points-v2";
+
+		opp-200000000 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <900000 900000 1000000>;
+		};
+
+		opp-700000000 {
+			opp-hz = /bits/ 64 <700000000>;
+			opp-microvolt = <950000 950000 1000000>;
+		};
+	};
+};
+
+&cpu0 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu1 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu3 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&gpu {
+	operating-points-v2 = <&gpu_opp_table>;
+};

Dragan Simic

author

2024-10-22 20:13 UTC #16 lore raw

Re: [PATCH 3/3] arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variant

Hello Fukaumi and Tom,

Quoted 98 lines · Dragan Simic

Quoted 59 lines · FUKAUMI Naoki
Quoted 58 lines · Dragan Simic
Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC. The difference between the RK3566T variant and the "full-fat" RK3566 variant is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of a functional NPU, which we currently don't have to worry about.
Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero SBC, [2] the Radxa ROCK 3C and the Radxa ZERO 3E/3W SBCs. Unfortunately, Radxa doesn't mention the use of RK3566T officially, but its official SBC specifications do state that the maximum frequency for the Cortex-A55 cores on those SBCs is lower than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of the RK3566T SoC variant rather easy. [3][4][5] An additional, helpful cue is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately in its downstream kernel. [6]
The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the vendor kernel source, [1] which uses the values of the "opp-supported-hw" OPP properties to determine which ones are supported on a particular SoC variant. The actual values of the "opp-supported-hw" properties make it rather easy to see what OPPs are supported on the RK3566T SoC variant, but that, rather unfortunately, clashes with the maximum frequencies advertised officially for the Cortex-A55 CPU cores on the above-mentioned SBCs. [2][3][4][5] The vendor kernel source indicates that the maximum frequency for the CPU cores is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Unless that discrepancy is resolved somehow, let's take the safe approach and use the lower maximum frequency for the CPU cores.
Update the dts files of the currently supported RK3566T-based boards to use the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores and the GPUs found on these boards out of their earlier overclocks, but it also means that the officially advertised specifications [2][3][4][5] of the highest supported frequencies for the Cortex-A55 CPU cores on these boards may actually be wrong, as already explained above.
The correctness of the introduced changes was validated by decompiling and comparing all affected board dtb files before and after these changes.
[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
[2] https://wiki.pine64.org/wiki/Quartz64
[3] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[5] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
[6] https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8
Cc TL Lim <[email protected]>
Cc Marek Kraus <[email protected]>
Cc Tom Cubie <[email protected]>
Cc FUKAUMI Naoki <[email protected]>
Helped-by Nicolas Frattaroli <[email protected]>
Helped-by Jonas Karlman <[email protected]>
Signed-off-by Dragan Simic <[email protected]>
---
  .../dts/rockchip/rk3566-radxa-zero-3.dtsi     |  2 +-
  .../boot/dts/rockchip/rk3566-rock-3c.dts      |  2 +-
  arch/arm64/boot/dts/rockchip/rk3566t.dtsi     | 90 
+++++++++++++++++++
  3 files changed, 92 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3566t.dtsi
Quoted 12 lines
arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi line 6
Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +1 -1
index de390d92c35e..1ee5d96a46a1 100644
@@ -3,7 +3,7 @@
  #include <dt-bindings/gpio/gpio.h>
  #include <dt-bindings/leds/common.h>
  #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"
could you drop this change for now?
This patch is also going to be used for the upcoming board dts for the Pine64 Quartz64 Zero, so there's no need for dropping it. The Quartz64 Zero definitely uses the RK3566T.
Quoted 1 line
We (Radxa) think we use RK3566.
Well, the available documentation for the Radxa ROCK 3C and ZERO 3E/3W boards doesn't say so; instead, everything points to the RK3566T being used. The referenced commit in the Radxa downstream kernel also indicates that RK3566T is used at least on some boards.
Also, some independent testing, by reading the efuses, has showed that at least some ROCK 3C and ZERO 3E/3W boards actually have the RK3566T, which means that we should handle them all as having the RK3566T, to avoid overclocking the CPU cores and the GPU. I'll get back to this below.
Quoted 2 lines
and vendor kernel[6] refers efuse value to determine it's -T or not. can you do similar way?
Unfortunately not at the moment, because that would require major changes to the way OPPs are handled in the upstream kernel. Maybe we can do that at some point in the future, as part of my planned work on supporting SoC binning.

Quoted 4 lines

With that in place, hopefully, we could handle any ROCK 3C and ZERO 3E/3W boards that actually have the "full-fat" RK3566 variant as such, but until then, it's much safer to treat them all as having the RK3566T, and avoid the possible overclocking.

Just checking, and having the subsequent discussion on IRC in mind, are you fine with the above-proposed approach? Please let me know if some further clarification is needed.

Quoted 113 lines

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts line 8

Quoted 12 lines

arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +0 -0

  / {
  	chosen {

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +1 -1

index f2cc086e5001..9a8f4f774dbc 100644
@@ -5,7 +5,7 @@
  #include <dt-bindings/leds/common.h>
  #include <dt-bindings/pinctrl/rockchip.h>
  #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"

same here.

Quoted 98 lines

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +0 -0

  / {
  	model = "Radxa ROCK 3C";

arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +90 -0

new file mode 100644
index 000000000000..cd89bd3b125b
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3566-base.dtsi"
+
+/ {
+	cpu0_opp_table: opp-table-0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <850000 850000 1150000>;
+			clock-latency-ns = <40000>;
+			opp-suspend;
+		};
+
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1025000 1025000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+	};
+
+	gpu_opp_table: opp-table-1 {
+		compatible = "operating-points-v2";
+
+		opp-200000000 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <850000 850000 1000000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <900000 900000 1000000>;
+		};
+
+		opp-700000000 {
+			opp-hz = /bits/ 64 <700000000>;
+			opp-microvolt = <950000 950000 1000000>;
+		};
+	};
+};
+
+&cpu0 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu1 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu3 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&gpu {
+	operating-points-v2 = <&gpu_opp_table>;
+};

FUKAUMI Naoki

2024-10-22 23:30 UTC #17 lore raw

Re: [PATCH 3/3] arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variant

Hi Dragan Simic,

Quoted 101 lines · Dragan Simic

Hello Fukaumi and Tom,
Quoted 98 lines · Dragan Simic
Quoted 59 lines · FUKAUMI Naoki
Quoted 58 lines · Dragan Simic
Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC. The difference between the RK3566T variant and the "full-fat" RK3566 variant is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of a functional NPU, which we currently don't have to worry about.
Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero SBC, [2] the Radxa ROCK 3C and the Radxa ZERO 3E/3W SBCs. Unfortunately, Radxa doesn't mention the use of RK3566T officially, but its official SBC specifications do state that the maximum frequency for the Cortex-A55 cores on those SBCs is lower than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of the RK3566T SoC variant rather easy. [3][4][5] An additional, helpful cue is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately in its downstream kernel. [6]
The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the vendor kernel source, [1] which uses the values of the "opp-supported-hw" OPP properties to determine which ones are supported on a particular SoC variant. The actual values of the "opp-supported-hw" properties make it rather easy to see what OPPs are supported on the RK3566T SoC variant, but that, rather unfortunately, clashes with the maximum frequencies advertised officially for the Cortex-A55 CPU cores on the above-mentioned SBCs. [2][3][4][5] The vendor kernel source indicates that the maximum frequency for the CPU cores is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Unless that discrepancy is resolved somehow, let's take the safe approach and use the lower maximum frequency for the CPU cores.
Update the dts files of the currently supported RK3566T-based boards to use the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores and the GPUs found on these boards out of their earlier overclocks, but it also means that the officially advertised specifications [2][3][4][5] of the highest supported frequencies for the Cortex-A55 CPU cores on these boards may actually be wrong, as already explained above.
The correctness of the introduced changes was validated by decompiling and comparing all affected board dtb files before and after these changes.
[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
[2] https://wiki.pine64.org/wiki/Quartz64
[3] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[5] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
[6] https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8
Cc TL Lim <[email protected]>
Cc Marek Kraus <[email protected]>
Cc Tom Cubie <[email protected]>
Cc FUKAUMI Naoki <[email protected]>
Helped-by Nicolas Frattaroli <[email protected]>
Helped-by Jonas Karlman <[email protected]>
Signed-off-by Dragan Simic <[email protected]>
---
.../dts/rockchip/rk3566-radxa-zero-3.dtsi | 2 +- .../boot/dts/rockchip/rk3566-rock-3c.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3566t.dtsi | 90
+++++++++++++++++++
  3 files changed, 92 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3566t.dtsi
Quoted 12 lines
arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi line 6
Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +1 -1
index de390d92c35e..1ee5d96a46a1 100644
@@ -3,7 +3,7 @@
   #include <dt-bindings/gpio/gpio.h>
   #include <dt-bindings/leds/common.h>
   #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"
could you drop this change for now?
This patch is also going to be used for the upcoming board dts for the Pine64 Quartz64 Zero, so there's no need for dropping it. The Quartz64 Zero definitely uses the RK3566T.
Quoted 1 line
We (Radxa) think we use RK3566.
Well, the available documentation for the Radxa ROCK 3C and ZERO 3E/3W boards doesn't say so; instead, everything points to the RK3566T being used. The referenced commit in the Radxa downstream kernel also indicates that RK3566T is used at least on some boards.
Also, some independent testing, by reading the efuses, has showed that at least some ROCK 3C and ZERO 3E/3W boards actually have the RK3566T, which means that we should handle them all as having the RK3566T, to avoid overclocking the CPU cores and the GPU. I'll get back to this below.
Quoted 2 lines
and vendor kernel[6] refers efuse value to determine it's -T or not. can you do similar way?
Unfortunately not at the moment, because that would require major changes to the way OPPs are handled in the upstream kernel. Maybe we can do that at some point in the future, as part of my planned work on supporting SoC binning.

Quoted 8 lines

Quoted 4 lines
With that in place, hopefully, we could handle any ROCK 3C and ZERO 3E/3W boards that actually have the "full-fat" RK3566 variant as such, but until then, it's much safer to treat them all as having the RK3566T, and avoid the possible overclocking.
Just checking, and having the subsequent discussion on IRC in mind, are you fine with the above-proposed approach? Please let me know if some further clarification is needed.

we have no objection. please do safer way.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

Quoted 114 lines

Quoted 113 lines

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts line 8

Quoted 12 lines

arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +0 -0

   / {
       chosen {

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +1 -1

index f2cc086e5001..9a8f4f774dbc 100644
@@ -5,7 +5,7 @@
   #include <dt-bindings/leds/common.h>
   #include <dt-bindings/pinctrl/rockchip.h>
   #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"

same here.

Quoted 98 lines

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +0 -0

   / {
       model = "Radxa ROCK 3C";

arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +90 -0

new file mode 100644
index 000000000000..cd89bd3b125b
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3566-base.dtsi"
+
+/ {
+    cpu0_opp_table: opp-table-0 {
+        compatible = "operating-points-v2";
+        opp-shared;
+
+        opp-408000000 {
+            opp-hz = /bits/ 64 <408000000>;
+            opp-microvolt = <850000 850000 1150000>;
+            clock-latency-ns = <40000>;
+        };
+
+        opp-600000000 {
+            opp-hz = /bits/ 64 <600000000>;
+            opp-microvolt = <850000 850000 1150000>;
+            clock-latency-ns = <40000>;
+        };
+
+        opp-816000000 {
+            opp-hz = /bits/ 64 <816000000>;
+            opp-microvolt = <850000 850000 1150000>;
+            clock-latency-ns = <40000>;
+            opp-suspend;
+        };
+
+        opp-1104000000 {
+            opp-hz = /bits/ 64 <1104000000>;
+            opp-microvolt = <900000 900000 1150000>;
+            clock-latency-ns = <40000>;
+        };
+
+        opp-1416000000 {
+            opp-hz = /bits/ 64 <1416000000>;
+            opp-microvolt = <1025000 1025000 1150000>;
+            clock-latency-ns = <40000>;
+        };
+    };
+
+    gpu_opp_table: opp-table-1 {
+        compatible = "operating-points-v2";
+
+        opp-200000000 {
+            opp-hz = /bits/ 64 <200000000>;
+            opp-microvolt = <850000 850000 1000000>;
+        };
+
+        opp-300000000 {
+            opp-hz = /bits/ 64 <300000000>;
+            opp-microvolt = <850000 850000 1000000>;
+        };
+
+        opp-400000000 {
+            opp-hz = /bits/ 64 <400000000>;
+            opp-microvolt = <850000 850000 1000000>;
+        };
+
+        opp-600000000 {
+            opp-hz = /bits/ 64 <600000000>;
+            opp-microvolt = <900000 900000 1000000>;
+        };
+
+        opp-700000000 {
+            opp-hz = /bits/ 64 <700000000>;
+            opp-microvolt = <950000 950000 1000000>;
+        };
+    };
+};
+
+&cpu0 {
+    operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu1 {
+    operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+    operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu3 {
+    operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&gpu {
+    operating-points-v2 = <&gpu_opp_table>;
+};

Dragan Simic

author

2024-10-23 00:38 UTC #18 lore raw

Re: [PATCH 3/3] arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variant

Hello Fukaumi,

Quoted 105 lines · FUKAUMI Naoki

Quoted 104 lines · Dragan Simic
Quoted 102 lines · Dragan Simic
Quoted 59 lines · FUKAUMI Naoki
Quoted 58 lines · Dragan Simic
Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC. The difference between the RK3566T variant and the "full-fat" RK3566 variant is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of a functional NPU, which we currently don't have to worry about.
Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero SBC, [2] the Radxa ROCK 3C and the Radxa ZERO 3E/3W SBCs. Unfortunately, Radxa doesn't mention the use of RK3566T officially, but its official SBC specifications do state that the maximum frequency for the Cortex-A55 cores on those SBCs is lower than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of the RK3566T SoC variant rather easy. [3][4][5] An additional, helpful cue is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately in its downstream kernel. [6]
The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the vendor kernel source, [1] which uses the values of the "opp-supported-hw" OPP properties to determine which ones are supported on a particular SoC variant. The actual values of the "opp-supported-hw" properties make it rather easy to see what OPPs are supported on the RK3566T SoC variant, but that, rather unfortunately, clashes with the maximum frequencies advertised officially for the Cortex-A55 CPU cores on the above-mentioned SBCs. [2][3][4][5] The vendor kernel source indicates that the maximum frequency for the CPU cores is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Unless that discrepancy is resolved somehow, let's take the safe approach and use the lower maximum frequency for the CPU cores.
Update the dts files of the currently supported RK3566T-based boards to use the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores and the GPUs found on these boards out of their earlier overclocks, but it also means that the officially advertised specifications [2][3][4][5] of the highest supported frequencies for the Cortex-A55 CPU cores on these boards may actually be wrong, as already explained above.
The correctness of the introduced changes was validated by decompiling and comparing all affected board dtb files before and after these changes.
[1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
[2] https://wiki.pine64.org/wiki/Quartz64
[3] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[5] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
[6] https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8
Cc TL Lim <[email protected]>
Cc Marek Kraus <[email protected]>
Cc Tom Cubie <[email protected]>
Cc FUKAUMI Naoki <[email protected]>
Helped-by Nicolas Frattaroli <[email protected]>
Helped-by Jonas Karlman <[email protected]>
Signed-off-by Dragan Simic <[email protected]>
---
.../dts/rockchip/rk3566-radxa-zero-3.dtsi | 2 +- .../boot/dts/rockchip/rk3566-rock-3c.dts | 2 +- arch/arm64/boot/dts/rockchip/rk3566t.dtsi | 90
+++++++++++++++++++
  3 files changed, 92 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3566t.dtsi
Quoted 12 lines
arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi line 6
Quoted 10 lines
arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +1 -1
index de390d92c35e..1ee5d96a46a1 100644
@@ -3,7 +3,7 @@
   #include <dt-bindings/gpio/gpio.h>
   #include <dt-bindings/leds/common.h>
   #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"
could you drop this change for now?
This patch is also going to be used for the upcoming board dts for the Pine64 Quartz64 Zero, so there's no need for dropping it. The Quartz64 Zero definitely uses the RK3566T.
Quoted 1 line
We (Radxa) think we use RK3566.
Well, the available documentation for the Radxa ROCK 3C and ZERO 3E/3W boards doesn't say so; instead, everything points to the RK3566T being used. The referenced commit in the Radxa downstream kernel also indicates that RK3566T is used at least on some boards.
Also, some independent testing, by reading the efuses, has showed that at least some ROCK 3C and ZERO 3E/3W boards actually have the RK3566T, which means that we should handle them all as having the RK3566T, to avoid overclocking the CPU cores and the GPU. I'll get back to this below.
Quoted 2 lines
and vendor kernel[6] refers efuse value to determine it's -T or not. can you do similar way?
Unfortunately not at the moment, because that would require major changes to the way OPPs are handled in the upstream kernel. Maybe we can do that at some point in the future, as part of my planned work on supporting SoC binning.
With that in place, hopefully, we could handle any ROCK 3C and ZERO 3E/3W boards that actually have the "full-fat" RK3566 variant as such, but until then, it's much safer to treat them all as having the RK3566T, and avoid the possible overclocking.

Quoted 5 lines

Quoted 3 lines
Just checking, and having the subsequent discussion on IRC in mind, are you fine with the above-proposed approach? Please let me know if some further clarification is needed.
we have no objection. please do safer way.

Great, thanks! It's better to be on the safe side, until we get the full support for SoC binning in the upstream kernel.

Quoted 113 lines

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts line 8

Quoted 12 lines

arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi +0 -0

   / {
       chosen {

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +1 -1

index f2cc086e5001..9a8f4f774dbc 100644
@@ -5,7 +5,7 @@
   #include <dt-bindings/leds/common.h>
   #include <dt-bindings/pinctrl/rockchip.h>
   #include <dt-bindings/soc/rockchip,vop2.h>
-#include "rk3566.dtsi"
+#include "rk3566t.dtsi"

same here.

Quoted 98 lines

arch/arm64/boot/dts/rockchip/rk3566-rock-3c.dts +0 -0

   / {
       model = "Radxa ROCK 3C";

arch/arm64/boot/dts/rockchip/rk3566t.dtsi new file +90 -0

new file mode 100644
index 000000000000..cd89bd3b125b
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3566-base.dtsi"
+
+/ {
+    cpu0_opp_table: opp-table-0 {
+        compatible = "operating-points-v2";
+        opp-shared;
+
+        opp-408000000 {
+            opp-hz = /bits/ 64 <408000000>;
+            opp-microvolt = <850000 850000 1150000>;
+            clock-latency-ns = <40000>;
+        };
+
+        opp-600000000 {
+            opp-hz = /bits/ 64 <600000000>;
+            opp-microvolt = <850000 850000 1150000>;
+            clock-latency-ns = <40000>;
+        };
+
+        opp-816000000 {
+            opp-hz = /bits/ 64 <816000000>;
+            opp-microvolt = <850000 850000 1150000>;
+            clock-latency-ns = <40000>;
+            opp-suspend;
+        };
+
+        opp-1104000000 {
+            opp-hz = /bits/ 64 <1104000000>;
+            opp-microvolt = <900000 900000 1150000>;
+            clock-latency-ns = <40000>;
+        };
+
+        opp-1416000000 {
+            opp-hz = /bits/ 64 <1416000000>;
+            opp-microvolt = <1025000 1025000 1150000>;
+            clock-latency-ns = <40000>;
+        };
+    };
+
+    gpu_opp_table: opp-table-1 {
+        compatible = "operating-points-v2";
+
+        opp-200000000 {
+            opp-hz = /bits/ 64 <200000000>;
+            opp-microvolt = <850000 850000 1000000>;
+        };
+
+        opp-300000000 {
+            opp-hz = /bits/ 64 <300000000>;
+            opp-microvolt = <850000 850000 1000000>;
+        };
+
+        opp-400000000 {
+            opp-hz = /bits/ 64 <400000000>;
+            opp-microvolt = <850000 850000 1000000>;
+        };
+
+        opp-600000000 {
+            opp-hz = /bits/ 64 <600000000>;
+            opp-microvolt = <900000 900000 1000000>;
+        };
+
+        opp-700000000 {
+            opp-hz = /bits/ 64 <700000000>;
+            opp-microvolt = <950000 950000 1000000>;
+        };
+    };
+};
+
+&cpu0 {
+    operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu1 {
+    operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+    operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu3 {
+    operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&gpu {
+    operating-points-v2 = <&gpu_opp_table>;
+};