devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dragan Simic <dsimic@manjaro.org>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Diederik de Haas <didi.debian@cknow.org>,
	linux-rockchip@lists.infradead.org, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: rockchip: Make RK3588 GPU OPP table naming uniform
Date: Sat, 06 Sep 2025 14:57:55 +0200	[thread overview]
Message-ID: <f34b6fad7768dd88b40284fa330af4f2@manjaro.org> (raw)
In-Reply-To: <3169011.CbtlEUcBR6@diego>

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.

  reply	other threads:[~2025-09-06 12:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-06 10:01 [PATCH] arm64: dts: rockchip: Make RK3588 GPU OPP table naming uniform Dragan Simic
2025-09-06 11:40 ` Diederik de Haas
2025-09-06 12:10   ` Dragan Simic
2025-09-06 12:21     ` Heiko Stübner
2025-09-06 12:57       ` Dragan Simic [this message]
2025-10-14 18:06 ` Heiko Stuebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f34b6fad7768dd88b40284fa330af4f2@manjaro.org \
    --to=dsimic@manjaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=didi.debian@cknow.org \
    --cc=heiko@sntech.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).