linux-kernel - Re: [PATCH v2] arm64: dts: rockchip: Add GPU OPP voltage ranges to RK356x SoC dtsi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 30 Jun 2024 13:53:36 +0200
From: Diederik de Haas <didi.debian@...ow.org>
To: linux-rockchip@...ts.infradead.org,
 Heiko Stübner <heiko@...ech.de>
Cc: Dragan Simic <dsimic@...jaro.org>, linux-arm-kernel@...ts.infradead.org,
 devicetree@...r.kernel.org, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, linux-kernel@...r.kernel.org,
 Jonas Karlman <jonas@...boo.se>, Diederik de Haas <didi.debian@...ow.org>
Subject:
 Re: [PATCH v2] arm64: dts: rockchip: Add GPU OPP voltage ranges to RK356x SoC
 dtsi

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
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)