From: Diederik de Haas <didi.debian@cknow.org>
To: linux-rockchip@lists.infradead.org, "Heiko Stübner" <heiko@sntech.de>
Cc: Dragan Simic <dsimic@manjaro.org>,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
linux-kernel@vger.kernel.org, Jonas Karlman <jonas@kwiboo.se>,
Diederik de Haas <didi.debian@cknow.org>
Subject: Re: [PATCH v2] arm64: dts: rockchip: Add GPU OPP voltage ranges to RK356x SoC dtsi
Date: Sun, 30 Jun 2024 13:53:36 +0200 [thread overview]
Message-ID: <2794811.2mGxvYehNa@bagend> (raw)
In-Reply-To: <1894199.CQOukoFCf9@diego>
[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]
On Sunday, 30 June 2024 11:07:47 CEST Heiko Stübner wrote:
> Am Sonntag, 30. Juni 2024, 00:01:41 CEST schrieb Diederik de Haas:
> > On Saturday, 29 June 2024 18:39:02 CEST Dragan Simic wrote:
> > > Add support for voltage ranges to the GPU OPPs defined in the SoC
> > > dtsi for RK356x. These voltage ranges are useful for RK356x-based
> > > boards that are designed to use the same power supply for the GPU
> > > and NPU portions of the SoC, which is described further in the
> > > following documents:
> > > - Rockchip RK3566 Hardware Design Guide, version 1.1.0, page 37
> > > - Rockchip RK3568 Hardware Design Guide, version 1.2, page 78
> >
> > That was interesting to read, thanks.
> > Now I understand the difference between rk809(-5) and rk817(-5).
> >
> > But AFAIUI the above description described why there were separate tables
> > for rk809 and rk817 in v1. But that was dropped in v2. So it seems to me
> > the (commit) message should be updated accordingly?
> >
> > I also expected that (for v1) there would be a similar construct as was
> > recently added for rk3588. But I should interpret Heiko's comments as that
> > strategy should not be applied to rk356x?
>
> The issue I had was more about the #ifdef'ery and then having a board define
> a constant to enable one or the other.
Yeah, I had some thoughts about that too, but by the time I was ready to
respond to that, there was v2, so that became irrelevant.
> As far as I understood the description, the OPP itself is the same in
> terms of frequency and voltage, just the regulator can't fully realize
> that target voltage, so the solution is to allow a voltage range, to
> also support the less-exact regulator.
>
> On the rk3588 on the other hand the soc variants have different OPP
> tables themselfs, because the soc itself only supports different
> frequencies+voltages. So the solution here is the split of the OPPs so
> that we don't mess around with /delete-node/ edits of one OPP table.
>
> So TL;DR separate OPP tables are the way to go if the user needs different
> freq+voltage values and voltage ranges allows boards to use less-adapted
> regulators.
Thanks for the explanation.
One of the things I researched was whether there was a different OPP table
in Rockchip's rk3566.dtsi (and then the assumption that RK817 = RK3566 and
RK809 = RK3568, which would be flawed/incorrect). But there wasn't.
Cheers,
Diederik
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-06-30 11:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-29 16:39 [PATCH v2] arm64: dts: rockchip: Add GPU OPP voltage ranges to RK356x SoC dtsi Dragan Simic
2024-06-29 22:01 ` Diederik de Haas
2024-06-30 9:07 ` Heiko Stübner
2024-06-30 11:53 ` Diederik de Haas [this message]
2024-06-30 12:04 ` Dragan Simic
2024-06-30 15:43 ` Diederik de Haas
2024-06-30 15:51 ` Dragan Simic
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=2794811.2mGxvYehNa@bagend \
--to=didi.debian@cknow.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dsimic@manjaro.org \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--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).