mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: AngeloGioacchino Del Regno  <angelogioacchino.delregno@collabora.com>
To: Matthias Brugger <matthias.bgg@gmail.com>, robh+dt@kernel.org
Cc: krzysztof.kozlowski+dt@linaro.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	wenst@chromium.org
Subject: Re: [PATCH 0/5] Allow getting regulator on MFG for multiple SoCs
Date: Thu, 23 Jun 2022 14:27:59 +0200	[thread overview]
Message-ID: <24bd8e36-d836-74f0-2006-781d6458b7da@collabora.com> (raw)
In-Reply-To: <11da278b-f7ce-d668-2c8a-46d7a9c71eb9@gmail.com>

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(-)
>>

      reply	other threads:[~2022-06-23 12:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23 10:09 AngeloGioacchino Del Regno
2022-06-23 10:09 ` [PATCH 1/5] soc: mediatek: mt8192-pm-domains: Allow probing vreg supply on MFG0/1 AngeloGioacchino Del Regno
2022-06-23 10:09 ` [PATCH 2/5] soc: mediatek: mt8183-pm-domains: Allow probing vreg supply on MFG_ASYNC AngeloGioacchino Del Regno
2022-06-23 10:09 ` [PATCH 3/5] soc: mediatek: mt8195-pm-domains: Allow probing vreg supply on MFG1 AngeloGioacchino Del Regno
2022-06-23 10:09 ` [PATCH 4/5] soc: mediatek: mt8186-pm-domains: " AngeloGioacchino Del Regno
2022-06-23 10:09 ` [PATCH 5/5] arm64: dts: mediatek: mt8183-kukui: Assign sram supply to mfg_async pd AngeloGioacchino Del Regno
2022-06-23 11:40 ` [PATCH 0/5] Allow getting regulator on MFG for multiple SoCs Matthias Brugger
2022-06-23 12:27   ` AngeloGioacchino Del Regno [this message]

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=24bd8e36-d836-74f0-2006-781d6458b7da@collabora.com \
    --to=angelogioacchino.delregno@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=wenst@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®