Unify the naming of the existing GPU OPP table nodes found in the RK3588
and RK3588J SoC dtsi files with the other SoC's GPU OPP nodes, following
the more "modern" node naming scheme.

Fixes: a7b2070505a2 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j")
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
---
 arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi | 2 +-
 arch/arm64/boot/dts/rockchip/rk3588j.dtsi    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi
index 0f1a77697351..b5d630d2c879 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi
@@ -115,7 +115,7 @@ opp-2400000000 {
 		};
 	};
 
-	gpu_opp_table: opp-table {
+	gpu_opp_table: opp-table-gpu {
 		compatible = "operating-points-v2";
 
 		opp-300000000 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
index 9884a5df47df..e1e0e3fc0ca7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
@@ -66,7 +66,7 @@ opp-1608000000 {
 		};
 	};
 
-	gpu_opp_table: opp-table {
+	gpu_opp_table: opp-table-gpu {
 		compatible = "operating-points-v2";
 
 		opp-300000000 {

Hi,

On Sat Sep 6, 2025 at 12:01 PM CEST, Dragan Simic wrote:
> Unify the naming of the existing GPU OPP table nodes found in the RK3588
> and RK3588J SoC dtsi files with the other SoC's GPU OPP nodes, following
> the more "modern" node naming scheme.

Like we discussed in private (without an agreement), I think it would be
beneficial if the (gpu) opp naming would be made consistent across SoC
series as right now there are several different naming schemes applied.
They're all valid, but inconsistent. And if consistency is improved,
which I like, then let's go 'all the way'?

Cheers,
  Diederik

> Fixes: a7b2070505a2 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j")
> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
> ---
>  arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi | 2 +-
>  arch/arm64/boot/dts/rockchip/rk3588j.dtsi    | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi
> index 0f1a77697351..b5d630d2c879 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi
> @@ -115,7 +115,7 @@ opp-2400000000 {
>  		};
>  	};
>  
> -	gpu_opp_table: opp-table {
> +	gpu_opp_table: opp-table-gpu {
>  		compatible = "operating-points-v2";
>  
>  		opp-300000000 {
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
> index 9884a5df47df..e1e0e3fc0ca7 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
> @@ -66,7 +66,7 @@ opp-1608000000 {
>  		};
>  	};
>  
> -	gpu_opp_table: opp-table {
> +	gpu_opp_table: opp-table-gpu {
>  		compatible = "operating-points-v2";
>  
>  		opp-300000000 {
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Hello Diederik,

On 2025-09-06 13:40, Diederik de Haas wrote:
> On Sat Sep 6, 2025 at 12:01 PM CEST, Dragan Simic wrote:
>> Unify the naming of the existing GPU OPP table nodes found in the 
>> RK3588
>> and RK3588J SoC dtsi files with the other SoC's GPU OPP nodes, 
>> following
>> the more "modern" node naming scheme.
> 
> Like we discussed in private (without an agreement), I think it would 
> be
> beneficial if the (gpu) opp naming would be made consistent across SoC
> series as right now there are several different naming schemes applied.
> They're all valid, but inconsistent. And if consistency is improved,
> which I like, then let's go 'all the way'?

As we discussed it already in private, I fully agree about performing
the "opp-table-X => opp-table-{clusterX,gpu}" naming cleanup 
consistently
for all Rockchip SoCs, but I'm afraid it would be seen as an unnecessary
"code churn" at this point, especially because my upcoming Rockchip SoC
binning patch series is a good candidate for such a cleanup.

On top of that, I'd be a bit weary about performing at least some of the
testing associated with such a platform-wide cleanup, despite actually
performing no functional changes and being a safe change.  On the other
hand, "bundling" such a cleanup with the Rockchip SoC binning patches
would get us detailed testing for free, so to speak.

Of course, if the maintainers see this as a good opportunity to perform
a platform-wide cleanup at this point, instead of seeing it as a "code
churn", I'll still be happy to extend this small patch into a platform-
wide naming cleanup of the "opp-table-X" nodes.  On the other hand, if
this patch remains as-is, it may hit a good balance between resolving
the currently present naming ambiguity and the amount of introduced
changes.

>> Fixes: a7b2070505a2 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 
>> and RK3588j")
>> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>> ---
>>  arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi | 2 +-
>>  arch/arm64/boot/dts/rockchip/rk3588j.dtsi    | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi 
>> b/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi
>> index 0f1a77697351..b5d630d2c879 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-opp.dtsi
>> @@ -115,7 +115,7 @@ opp-2400000000 {
>>  		};
>>  	};
>> 
>> -	gpu_opp_table: opp-table {
>> +	gpu_opp_table: opp-table-gpu {
>>  		compatible = "operating-points-v2";
>> 
>>  		opp-300000000 {
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi 
>> b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
>> index 9884a5df47df..e1e0e3fc0ca7 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
>> @@ -66,7 +66,7 @@ opp-1608000000 {
>>  		};
>>  	};
>> 
>> -	gpu_opp_table: opp-table {
>> +	gpu_opp_table: opp-table-gpu {
>>  		compatible = "operating-points-v2";
>> 
>>  		opp-300000000 {

Am Samstag, 6. September 2025, 14:10:22 Mitteleuropäische Sommerzeit schrieb Dragan Simic:
> Hello Diederik,
> 
> On 2025-09-06 13:40, Diederik de Haas wrote:
> > On Sat Sep 6, 2025 at 12:01 PM CEST, Dragan Simic wrote:
> >> Unify the naming of the existing GPU OPP table nodes found in the 
> >> RK3588
> >> and RK3588J SoC dtsi files with the other SoC's GPU OPP nodes, 
> >> following
> >> the more "modern" node naming scheme.
> > 
> > Like we discussed in private (without an agreement), I think it would 
> > be
> > beneficial if the (gpu) opp naming would be made consistent across SoC
> > series as right now there are several different naming schemes applied.
> > They're all valid, but inconsistent. And if consistency is improved,
> > which I like, then let's go 'all the way'?
> 
> As we discussed it already in private, I fully agree about performing
> the "opp-table-X => opp-table-{clusterX,gpu}" naming cleanup 
> consistently
> for all Rockchip SoCs, but I'm afraid it would be seen as an unnecessary
> "code churn" at this point, especially because my upcoming Rockchip SoC
> binning patch series is a good candidate for such a cleanup.
> 
> On top of that, I'd be a bit weary about performing at least some of the
> testing associated with such a platform-wide cleanup, despite actually
> performing no functional changes and being a safe change.  On the other
> hand, "bundling" such a cleanup with the Rockchip SoC binning patches
> would get us detailed testing for free, so to speak.
> 
> Of course, if the maintainers see this as a good opportunity to perform
> a platform-wide cleanup at this point, instead of seeing it as a "code
> churn", I'll still be happy to extend this small patch into a platform-
> wide naming cleanup of the "opp-table-X" nodes.  On the other hand, if
> this patch remains as-is, it may hit a good balance between resolving
> the currently present naming ambiguity and the amount of introduced
> changes.

Personally I'm always for the "we strive to get there eventually" thing.
If there is an established goal to reach, steps can be incremental :-) .

And also short and scope-limited patches are easier to review anyway.

Heiko

Hello Heiko,

On 2025-09-06 14:21, Heiko Stübner wrote:
> Am Samstag, 6. September 2025, 14:10:22 Mitteleuropäische Sommerzeit
> schrieb Dragan Simic:
>> On 2025-09-06 13:40, Diederik de Haas wrote:
>> > On Sat Sep 6, 2025 at 12:01 PM CEST, Dragan Simic wrote:
>> >> Unify the naming of the existing GPU OPP table nodes found in the
>> >> RK3588
>> >> and RK3588J SoC dtsi files with the other SoC's GPU OPP nodes,
>> >> following
>> >> the more "modern" node naming scheme.
>> >
>> > Like we discussed in private (without an agreement), I think it would
>> > be
>> > beneficial if the (gpu) opp naming would be made consistent across SoC
>> > series as right now there are several different naming schemes applied.
>> > They're all valid, but inconsistent. And if consistency is improved,
>> > which I like, then let's go 'all the way'?
>> 
>> As we discussed it already in private, I fully agree about performing
>> the "opp-table-X => opp-table-{clusterX,gpu}" naming cleanup
>> consistently
>> for all Rockchip SoCs, but I'm afraid it would be seen as an 
>> unnecessary
>> "code churn" at this point, especially because my upcoming Rockchip 
>> SoC
>> binning patch series is a good candidate for such a cleanup.
>> 
>> On top of that, I'd be a bit weary about performing at least some of 
>> the
>> testing associated with such a platform-wide cleanup, despite actually
>> performing no functional changes and being a safe change.  On the 
>> other
>> hand, "bundling" such a cleanup with the Rockchip SoC binning patches
>> would get us detailed testing for free, so to speak.
>> 
>> Of course, if the maintainers see this as a good opportunity to 
>> perform
>> a platform-wide cleanup at this point, instead of seeing it as a "code
>> churn", I'll still be happy to extend this small patch into a 
>> platform-
>> wide naming cleanup of the "opp-table-X" nodes.  On the other hand, if
>> this patch remains as-is, it may hit a good balance between resolving
>> the currently present naming ambiguity and the amount of introduced
>> changes.
> 
> Personally I'm always for the "we strive to get there eventually" 
> thing.
> If there is an established goal to reach, steps can be incremental :-) 
> .
> 
> And also short and scope-limited patches are easier to review anyway.

I see.  After thinking a bit more about it, I'll turn this patch into
a small series, in which this patch becomes the 1/2, and the 2/2 is
a new, larger patch that extends the "opp-table-X" naming cleanup to
the entire platform.  That way, the 1/2 kind of fixes something, while
the 2/2 performs a cleanup, which may be helpful in the unlikely case
that some regression is found down the road.