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]

Message-ID: <2573506.7YG5XaKc65@bagend>
Date: Sun, 30 Jun 2024 17:43:05 +0200
From: Diederik de Haas <didi.debian@...ow.org>
To: Dragan Simic <dsimic@...jaro.org>
Cc: linux-rockchip@...ts.infradead.org, heiko@...ech.de,
 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

Hi Dragan,

On Sunday, 30 June 2024 14:04:50 CEST Dragan Simic wrote:
> > 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 trouble with applying the same strategy, ...

One of the reasons I like/hoped for it is that I'm a 'sucker' for consistency.

> ... the need for voltage ranges depends on one of the board features,
> i.e. the GPU and NPU voltage regulators.  As such, it still has to
> affect the RK356x SoC dtsi, which may warrant separate
> rk356x-gpu-range.dtsi, for example, but the troubles would arise ...

... but it's probably better if I (generally) abstain from taking part
in the discussion about the correct/desired implementation as I don't
understand the material in enough detail to meaningfully contribute.

> That's why the v1 went with a macro instead.

... which didn't seem to help with my consistency wish ;-)
(AFAIC there's no need to discuss this further (publicly))

> > When we/upstream adds npu support, I think we should also follow
> > downstream's OPP values, unless we have a very good reason to
> > deviate from that.
> 
> That would make sense, especially because we haven't had the NPU
> supported before in the mainline.

I first wondered why you hadn't *updated* the npu OPP values ... 
to later find out they haven't been specified at all in 'upstream'.

Cheers,
  Diederik
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)