From: Diederik de Haas <didi.debian@cknow.org>
To: Dragan Simic <dsimic@manjaro.org>
Cc: linux-rockchip@lists.infradead.org, heiko@sntech.de,
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 17:43:05 +0200 [thread overview]
Message-ID: <2573506.7YG5XaKc65@bagend> (raw)
In-Reply-To: <b8951ac4e29184fa35919c6ab85b8f87@manjaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 1472 bytes --]
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
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Diederik de Haas <didi.debian@cknow.org>
To: Dragan Simic <dsimic@manjaro.org>
Cc: linux-rockchip@lists.infradead.org, heiko@sntech.de,
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 17:43:05 +0200 [thread overview]
Message-ID: <2573506.7YG5XaKc65@bagend> (raw)
In-Reply-To: <b8951ac4e29184fa35919c6ab85b8f87@manjaro.org>
[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]
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
[-- 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 15:43 UTC|newest]
Thread overview: 14+ 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 16:39 ` Dragan Simic
2024-06-29 22:01 ` Diederik de Haas
2024-06-29 22:01 ` Diederik de Haas
2024-06-30 9:07 ` Heiko Stübner
2024-06-30 9:07 ` Heiko Stübner
2024-06-30 11:53 ` Diederik de Haas
2024-06-30 11:53 ` Diederik de Haas
2024-06-30 12:04 ` Dragan Simic
2024-06-30 12:04 ` Dragan Simic
2024-06-30 15:43 ` Diederik de Haas [this message]
2024-06-30 15:43 ` Diederik de Haas
2024-06-30 15:51 ` Dragan Simic
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=2573506.7YG5XaKc65@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.