[PATCH v2] arm64: dts: rockchip: Add GPU OPP voltage ranges to RK356x SoC dtsi
Diederik de Haas
didi.debian at cknow.org
Sun Jun 30 08:43:05 PDT 2024
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240630/54f25574/attachment.sig>
More information about the linux-arm-kernel
mailing list