From: Dragan Simic <dsimic@manjaro.org>
To: "Heiko Stübner" <heiko@sntech.de>
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:22:14 +0200 [thread overview]
Message-ID: <54fc7e18a6498d15e008733864f26070@manjaro.org> (raw)
In-Reply-To: <9297854.CDJkKcVGEf@diego>
On 2024-06-29 18:18, Heiko Stübner wrote:
> 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 ;-) .
Yes, but we still need new regulator/OPP debugging facilities
that should to be used while writing DTs for new boards and while
verifying already existing board DTs. :)
I'll prepare and send the v2 of this patch, and I'll also start
working on the new patch for those debugging facilities.
_______________________________________________
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: Dragan Simic <dsimic@manjaro.org>
To: "Heiko Stübner" <heiko@sntech.de>
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:22:14 +0200 [thread overview]
Message-ID: <54fc7e18a6498d15e008733864f26070@manjaro.org> (raw)
In-Reply-To: <9297854.CDJkKcVGEf@diego>
On 2024-06-29 18:18, Heiko Stübner wrote:
> 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 ;-) .
Yes, but we still need new regulator/OPP debugging facilities
that should to be used while writing DTs for new boards and while
verifying already existing board DTs. :)
I'll prepare and send the v2 of this patch, and I'll also start
working on the new patch for those debugging facilities.
next prev parent reply other threads:[~2024-06-29 16:22 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
2024-06-29 16:18 ` Heiko Stübner
2024-06-29 16:22 ` Dragan Simic [this message]
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=54fc7e18a6498d15e008733864f26070@manjaro.org \
--to=dsimic@manjaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=didi.debian@cknow.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.