All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Dragan Simic <dsimic@manjaro.org>
Cc: linux-rockchip@lists.infradead.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,
	Diederik de Haas <didi.debian@cknow.org>,
	Jonas Karlman <jonas@kwiboo.se>
Subject: Re: [PATCH] arm64: dts: rockchip: Add optional GPU OPP voltage ranges to RK356x SoC dtsi
Date: Sat, 29 Jun 2024 18:18:06 +0200	[thread overview]
Message-ID: <9297854.CDJkKcVGEf@diego> (raw)
In-Reply-To: <36170f8485293b336106e92346478daa@manjaro.org>

Am Samstag, 29. Juni 2024, 17:39:34 CEST schrieb Dragan Simic:
> On 2024-06-29 17:25, Dragan Simic wrote:
> > On 2024-06-29 17:10, Heiko Stübner wrote:
> >> Am Samstag, 29. Juni 2024, 07:11:24 CEST schrieb Dragan Simic:
> >> 
> >>> +#ifndef RK356X_GPU_NPU_SHARED_REGULATOR
> >> 
> >> is there some reason for this duplicating of opps?
> >> 
> >> The regulator framework should pick the lowest supported voltage
> >> anyway, so it seems you're just extending them upwards a bit.
> >> 
> >> So I really don't so why we'd need to sets here.
> > 
> > The reason is improved strictness.  Having the exact GPU OPP voltages
> > required for the boards whose GPU regulators can provide those exact
> > voltages makes it possible to detect misconfigurations much easier,
> > just like it was the case with the board dts misconfiguration that
> > resulted in the recent DCDC_REG2 patch. [1]
> > 
> > If we had GPU OPP voltage ranges in place instead, the aforementioned
> > issue would probably remain undetected for some time.  It wouldn't be
> > the end of the world, :) of course, but the resulting increased power
> > consumption isn't one of the desired outcomes.
> > 
> > [1] 
> > https://lore.kernel.org/linux-rockchip/e70742ea2df432bf57b3f7de542d81ca22b0da2f.1716225483.git.dsimic@manjaro.org/
> 
> On second thought, after seeing that the RK3399 CPU and GPU OPPs
> already specify voltage ranges, I think it would be better to drop
> the distinction between the separate strict voltages and the voltage
> ranges in this patch,

yes, that was what I was trying to say :-)

Also it makes the OPPs less cluttered. Also dt is firmware, I do expect
people to be reasonably knowledgeable if they mess around with their
boards OPPs ;-) .




_______________________________________________
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: "Heiko Stübner" <heiko@sntech.de>
To: Dragan Simic <dsimic@manjaro.org>
Cc: linux-rockchip@lists.infradead.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,
	Diederik de Haas <didi.debian@cknow.org>,
	Jonas Karlman <jonas@kwiboo.se>
Subject: Re: [PATCH] arm64: dts: rockchip: Add optional GPU OPP voltage ranges to RK356x SoC dtsi
Date: Sat, 29 Jun 2024 18:18:06 +0200	[thread overview]
Message-ID: <9297854.CDJkKcVGEf@diego> (raw)
In-Reply-To: <36170f8485293b336106e92346478daa@manjaro.org>

Am Samstag, 29. Juni 2024, 17:39:34 CEST schrieb Dragan Simic:
> On 2024-06-29 17:25, Dragan Simic wrote:
> > On 2024-06-29 17:10, Heiko Stübner wrote:
> >> Am Samstag, 29. Juni 2024, 07:11:24 CEST schrieb Dragan Simic:
> >> 
> >>> +#ifndef RK356X_GPU_NPU_SHARED_REGULATOR
> >> 
> >> is there some reason for this duplicating of opps?
> >> 
> >> The regulator framework should pick the lowest supported voltage
> >> anyway, so it seems you're just extending them upwards a bit.
> >> 
> >> So I really don't so why we'd need to sets here.
> > 
> > The reason is improved strictness.  Having the exact GPU OPP voltages
> > required for the boards whose GPU regulators can provide those exact
> > voltages makes it possible to detect misconfigurations much easier,
> > just like it was the case with the board dts misconfiguration that
> > resulted in the recent DCDC_REG2 patch. [1]
> > 
> > If we had GPU OPP voltage ranges in place instead, the aforementioned
> > issue would probably remain undetected for some time.  It wouldn't be
> > the end of the world, :) of course, but the resulting increased power
> > consumption isn't one of the desired outcomes.
> > 
> > [1] 
> > https://lore.kernel.org/linux-rockchip/e70742ea2df432bf57b3f7de542d81ca22b0da2f.1716225483.git.dsimic@manjaro.org/
> 
> On second thought, after seeing that the RK3399 CPU and GPU OPPs
> already specify voltage ranges, I think it would be better to drop
> the distinction between the separate strict voltages and the voltage
> ranges in this patch,

yes, that was what I was trying to say :-)

Also it makes the OPPs less cluttered. Also dt is firmware, I do expect
people to be reasonably knowledgeable if they mess around with their
boards OPPs ;-) .





  reply	other threads:[~2024-06-29 16:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-29  5:11 [PATCH] arm64: dts: rockchip: Add optional GPU OPP voltage ranges to RK356x SoC dtsi Dragan Simic
2024-06-29  5:11 ` Dragan Simic
2024-06-29 15:10 ` Heiko Stübner
2024-06-29 15:10   ` Heiko Stübner
2024-06-29 15:25   ` Dragan Simic
2024-06-29 15:25     ` Dragan Simic
2024-06-29 15:39     ` Dragan Simic
2024-06-29 15:39       ` Dragan Simic
2024-06-29 16:18       ` Heiko Stübner [this message]
2024-06-29 16:18         ` Heiko Stübner
2024-06-29 16:22         ` Dragan Simic
2024-06-29 16:22           ` 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=9297854.CDJkKcVGEf@diego \
    --to=heiko@sntech.de \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=didi.debian@cknow.org \
    --cc=dsimic@manjaro.org \
    --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.