linux-kernel - Re: [PATCH] arm64: dts: mediatek: mt8395-genio-1200-evk: Enable GPU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <01020191e5383829-7eb375ea-ee17-419e-b173-30df46f61863-000000@eu-west-1.amazonses.com>
Date: Thu, 12 Sep 2024 07:52:32 +0000
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Pablo Sun <pablo.sun@...iatek.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, 
	Matthias Brugger <matthias.bgg@...il.com>
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, 
	linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH] arm64: dts: mediatek: mt8395-genio-1200-evk: Enable GPU

Il 11/09/24 12:35, Pablo Sun ha scritto:
> Hi Angelo,
> 
> Thanks for the review,
> 
> On 9/11/24 16:57, AngeloGioacchino Del Regno wrote:
> 
> [snip]
> 
>>> +/* for GPU SRAM */
>>> +&mt6359_vsram_others_ldo_reg {
>>> +    regulator-always-on;
>>
>> No, that's not good. Like that, the GPU VSRAM will be subject to current leakage.
>>
>> Remove the regulator-always-on property.
>> The right way of doing that is to add the vgpu to the mfg0's domain supply and
>> vsram to mfg1; that way all of the GPU regulators will be off at PM suspend time.
> 
> Thanks for pointing this out, I'll send v2 to fix this.
> 
>>>   &mt6359codec {
>>>       mediatek,mic-type-0 = <1>; /* ACC */
>>>       mediatek,mic-type-1 = <3>; /* DCC */
>>> @@ -839,8 +851,8 @@ regulators {
>>>               mt6315_7_vbuck1: vbuck1 {
>>>                   regulator-compatible = "vbuck1";
>>>                   regulator-name = "Vgpu";
>>> -                regulator-min-microvolt = <300000>;
>>> -                regulator-max-microvolt = <1193750>;
>>> +                regulator-min-microvolt = <546000>;
>>
>> I'm okay with this constraint but are you sure that MTK-SVS won't go any lower 
>> than 0.546V?
> 
> I'll see if I could confirm the maximum voltage drop that may be lowered by mtk-svs 
> for MT8395. There are 3 constraints that I am aware of:
> 
> - capability of Vgpu buck: 0.3V-1.193V
> - sign-off voltage of the EVK board: 0.6V to 1.2V
> - recommended operating voltage of MT8395 DVDD_GPU: 0.546V to 0.787V
> 
> For the device tree of the board, would you recommend set the regulator voltage 
> constraints in narrower range (because it's safer to keep in recommended operating 
> conditions), or in a wider range (leaving the check to driver software for 
> potential power saving?)
> 

The range should match the target device's Vin constraints; in this case, it
should be no lower than the minimum working voltage of the Vgpu-in of the Mali IP.

The drivers will be responsible of setting the lowest possible voltage for
enhanced efficiency (power saving), taking into account the fused chip quality bits
(in this case, the MediaTek SVS driver!).

You should, at this point, check the constraints of SVS, as in, given a reference
voltage (in this case, located in the GPU OPP table, the voltage associated with
the lowest frequency of the GPU), what is the maximum voltage *subtraction* that
SVS will do on the VGPU?

After the subtraction, may this voltage be lower than 0.546V? :-)

Cheers,
Angelo

> Thanks
> 
>