Message-ID: <865640012.0ifERbkFSE@diego>
Date: Sun, 10 Nov 2024 22:16:42 +0100
From: Heiko Stübner <heiko@...ech.de>
To: Dragan Simic <dsimic@...jaro.org>
Cc: linux-rockchip@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org, stable@...r.kernel.org
Subject:
 Re: [PATCH] arm64: dts: rockchip: Fix vdd_gpu voltage constraints on
 PinePhone Pro

Am Sonntag, 10. November 2024, 21:47:15 CET schrieb Dragan Simic:
> Hello Heiko,
> 
> On 2024-11-10 21:08, Heiko Stübner wrote:
> > Am Sonntag, 10. November 2024, 19:44:31 CET schrieb Dragan Simic:
> >> The regulator-{min,max}-microvolt values for the vdd_gpu regulator in 
> >> the
> >> PinePhone Pro device dts file are too restrictive, which prevents the 
> >> highest
> >> GPU OPP from being used, slowing the GPU down unnecessarily.  Let's 
> >> fix that
> >> by making the regulator-{min,max}-microvolt values less strict, using 
> >> the
> >> voltage range that the Silergy SYR838 chip used for the vdd_gpu 
> >> regulator is
> >> actually capable of producing. [1][2]
> >> 
> >> This also eliminates the following error messages from the kernel log:
> >> 
> >>   core: _opp_supported_by_regulators: OPP minuV: 1100000 maxuV: 
> >> 1150000, not supported by regulator
> >>   panfrost ff9a0000.gpu: _opp_add: OPP not supported by regulators 
> >> (800000000)
> >> 
> >> These changes to the regulator-{min,max}-microvolt values make the 
> >> PinePhone
> >> Pro device dts consistent with the dts files for other Rockchip 
> >> RK3399-based
> >> boards and devices.  It's possible to be more strict here, by 
> >> specifying the
> >> regulator-{min,max}-microvolt values that don't go outside of what the 
> >> GPU
> >> actually may use, as the consumer of the vdd_gpu regulator, but those 
> >> changes
> >> are left for a later directory-wide regulator cleanup.
> > 
> > With the Pinephone Pro using some sort of special-rk3399, how much of
> > "the soc variant cannot use the highest gpu opp" is in there, and just 
> > the
> > original implementation is wrong?
> 
> Good question, I already asked it myself.  I'm unaware of any kind of
> GPU-OPP-related restrictions when it comes to the PinePhone-Pro-specific
> RK3399S.  Furthermore, "the word on the street" is that the RK3399S can
> work perfectly fine even at the couple of "full-fat" RK3399 CPU OPPs
> that are not defined for the RK3399S, and the only result would be the
> expected higher power consumption and a bit more heat generated.

In the past we already had people submit higher cpu OPPs with the
reasoning "the cpu runs fine with it", but which where outside of the
officially specified frequencies and were essentially overclocking the
CPU cores and thus possibly reducing its lifetime.

So "it runs fine" is a bit of thin argument ;-) . I guess for the gpu it
might not matter too much, compared to the cpu cores, but I still like
the safe sides - especially for the mainline sources.

I guess we'll wait for people to test the change and go from there ;-) .


> This just reaffirms that no known GPU OPP restrictions exist.  Even
> if they existed, enforcing them _primarily_ through the constraints of
> the associated voltage regulator would be the wrong approach.  Instead,
> the restrictions should be defined primarily through the per-SoC-variant
> GPU OPPs, which are, to my best knowledge, not known to be existing for
> the RK3399S SoC variant.

Yes, that is what I was getting at, if that is a limiting implementation
it is of course not done correctly, but I'd like to make sure.

Of course Pine's development model doesn't help at all in that regard.
There isn't even a "vendor" kernel source it seems. [0]


Heiko


[0] https://wiki.pine64.org/wiki/PinePhone_Pro_Development#Kernel
states "There's no canonical location for Pinephone Pro Linux kernel development,"

Powered by blists - more mailing lists