All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Brugger <matthias.bgg@gmail.com>
To: AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.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 v2 0/2] Allow getting regulator on MFG for multiple SoCs
Date: Thu, 7 Jul 2022 10:22:45 +0200	[thread overview]
Message-ID: <a0059fb3-c734-84eb-88ee-e0d34fcbca1b@gmail.com> (raw)
In-Reply-To: <20220623123850.110225-1-angelogioacchino.delregno@collabora.com>



On 23/06/2022 14:38, 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.

Both patches applied, thanks!

> 
>   Changes in v2:
>    - Squashed all mtXXXX-pm-domains.h changes in one patch
> 
> AngeloGioacchino Del Regno (2):
>    soc: mediatek: mtk-pm-domains: Allow probing vreg supply on two MFGs
>    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(-)
> 


WARNING: multiple messages have this Message-ID (diff)
From: Matthias Brugger <matthias.bgg@gmail.com>
To: AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.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 v2 0/2] Allow getting regulator on MFG for multiple SoCs
Date: Thu, 7 Jul 2022 10:22:45 +0200	[thread overview]
Message-ID: <a0059fb3-c734-84eb-88ee-e0d34fcbca1b@gmail.com> (raw)
In-Reply-To: <20220623123850.110225-1-angelogioacchino.delregno@collabora.com>



On 23/06/2022 14:38, 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.

Both patches applied, thanks!

> 
>   Changes in v2:
>    - Squashed all mtXXXX-pm-domains.h changes in one patch
> 
> AngeloGioacchino Del Regno (2):
>    soc: mediatek: mtk-pm-domains: Allow probing vreg supply on two MFGs
>    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(-)
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-07-07  8:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23 12:38 [PATCH v2 0/2] Allow getting regulator on MFG for multiple SoCs AngeloGioacchino Del Regno
2022-06-23 12:38 ` AngeloGioacchino Del Regno
2022-06-23 12:38 ` [PATCH v2 1/2] soc: mediatek: mtk-pm-domains: Allow probing vreg supply on two MFGs AngeloGioacchino Del Regno
2022-06-23 12:38   ` AngeloGioacchino Del Regno
2022-06-23 12:38 ` [PATCH v2 2/2] arm64: dts: mediatek: mt8183-kukui: Assign sram supply to mfg_async pd AngeloGioacchino Del Regno
2022-06-23 12:38   ` AngeloGioacchino Del Regno
2022-07-07  8:22 ` Matthias Brugger [this message]
2022-07-07  8:22   ` [PATCH v2 0/2] Allow getting regulator on MFG for multiple SoCs Matthias Brugger

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=a0059fb3-c734-84eb-88ee-e0d34fcbca1b@gmail.com \
    --to=matthias.bgg@gmail.com \
    --cc=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=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 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.