linux-kernel - Re: [PATCH 0/5] Allow getting regulator on MFG for multiple SoCs

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] [day] [month] [year] [list]

Message-ID: <24bd8e36-d836-74f0-2006-781d6458b7da@collabora.com>
Date:   Thu, 23 Jun 2022 14:27:59 +0200
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Matthias Brugger <matthias.bgg@...il.com>, robh+dt@...nel.org
Cc:     krzysztof.kozlowski+dt@...aro.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        wenst@...omium.org
Subject: Re: [PATCH 0/5] Allow getting regulator on MFG for multiple SoCs

Il 23/06/22 13:40, Matthias Brugger ha scritto:
> 
> 
> On 23/06/2022 12:09, AngeloGioacchino Del Regno wrote:
>> This is one of the steps to enable DVFS with the Panfrost driver:
>> since Panfrost is already enabling the (required) MFG power domains
>> and since the mtk-pm-domains driver is already responsible for
>> actually enabling the SRAM PDN, it makes sense to make sure that
>> the VSRAM supply is ON when trying to reset/enable the SRAM.
>>
>> For this reason, the MTK_SCPD_DOMAIN_SUPPLY flag was added to one
>> more MFG domain, ensuring that the SRAM is actually powered and
>> also not relying on the bootloader leaving this supply on; on the
>> other hand, this is also making possible to avoid setting a
>> sram-supply on the GPU node, making devfreq happy about having
>> only one supply and finally allowing DVFS to happen.
>>
>> If no domain-supply is declared in devicetree, mtk-pm-domains driver
>> probe will anyway keep going, so this is not breaking old devicetrees.
>>
>> No side effects either when this supply is declared for both a MFG
>> domain and Panfrost together.
>>
>> This series has no dependencies.
>>
>> AngeloGioacchino Del Regno (5):
>>    soc: mediatek: mt8192-pm-domains: Allow probing vreg supply on MFG0/1
>>    soc: mediatek: mt8183-pm-domains: Allow probing vreg supply on
>>      MFG_ASYNC
>>    soc: mediatek: mt8195-pm-domains: Allow probing vreg supply on MFG1
>>    soc: mediatek: mt8186-pm-domains: Allow probing vreg supply on MFG1
> 
> I think we can squash the 4 patches into one. Other then that series looks good.
> 

I was wondering the same... the reason why I haven't squashed the patches is
that I'm not sure if MT8173 also needs that or not - and this makes really
clear to whoever reads the git log that MT8173 was omitted.
Looking back at that though, be it one and squashed, or be it four, shouldn't
change much for that kind of intention, what do you say?

Eh, for clarity - I didn't even check/touch MT8173 because that's PowerVR... and
currently there's no driver that's currently upstream.

Anyway, if you think that squashing is the right way to go, I can do that in
practically no time and send a v2.

Cheers,
Angelo

> Matthias
> 
>>    arm64: dts: mediatek: mt8183-kukui: Assign sram supply to mfg_async pd
>>
>>   arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 ++++
>>   arch/arm64/boot/dts/mediatek/mt8183.dtsi       | 2 +-
>>   drivers/soc/mediatek/mt8183-pm-domains.h       | 1 +
>>   drivers/soc/mediatek/mt8186-pm-domains.h       | 2 +-
>>   drivers/soc/mediatek/mt8192-pm-domains.h       | 2 ++
>>   drivers/soc/mediatek/mt8195-pm-domains.h       | 2 +-
>>   6 files changed, 10 insertions(+), 3 deletions(-)
>>