[PATCH v2 0/6] Enable Mali GPU on MediaTek Genio 700 EVK

[PATCH v2 0/6] Enable Mali GPU on MediaTek Genio 700 EVK

[Pablo Sun]

This series is based on linux-next, tag: next-20240927

Enables the GPU on mt8390-genio-700-evk.dts. 
The panfrost driver probed with dmesg:

panfrost 13000000.gpu: clock rate = 390000000
panfrost 13000000.gpu: mali-g57 id 0x9093 major 0x0 minor 0x0 status 0x0
panfrost 13000000.gpu: features: 00000000,000019f7, 
  issues: 00000003,80000400
panfrost 13000000.gpu: Features: L2:0x08130206 Shader:0x00000000
  Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7
panfrost 13000000.gpu: shader_present=0x10005 l2_present=0x1
[drm] Initialized panfrost 1.2.0 for 13000000.gpu on minor 0

Changes in v2:
- Fixes the "Fixes" tag in patch ("arm64: dts: mediatek: mt8188: 
  Fix wrong clock provider in MFG1 power domain")
- Reuse mtk_mt8186_efuse_pdata
- Remove comma at the end of mainpll_d5_d2
- Add patch ("soc: mediatek: mediatek-regulator-coupler: Support mt8188")
- Couple GPU SRAM voltage to GPU voltage instead of fixed value

Pablo Sun (6):
  arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power
    domain
  clk: mediatek: clk-mt8188-topckgen: Remove univpll from parents of
    mfg_core_tmp
  nvmem: mtk-efuse: Enable postprocess for mt8188 GPU speed binning
  arm64: dts: mediatek: mt8188: Add efuse for GPU speed binning
  soc: mediatek: mediatek-regulator-coupler: Support mt8188
  arm64: dts: mediatek: mt8390-genio-700-evk: Enable Mali GPU

 arch/arm64/boot/dts/mediatek/mt8188.dtsi      | 11 +++++--
 .../dts/mediatek/mt8390-genio-700-evk.dts     | 31 +++++++++++++++++++
 drivers/clk/mediatek/clk-mt8188-topckgen.c    |  9 ++++--
 drivers/nvmem/mtk-efuse.c                     |  1 +
 drivers/soc/mediatek/mtk-regulator-coupler.c  |  1 +
 5 files changed, 48 insertions(+), 5 deletions(-)

-- 
2.45.2

[PATCH v2 1/6] arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain

[Pablo Sun]

The clock index "CLK_APMIXED_MFGPLL" belongs to the "apmixedsys" provider,
so fix the index.

In addition, add a "mfg1" label so following commits could set
domain-supply for MFG1 power domain.

Fixes: eaf73e4224a3 ("arm64: dts: mediatek: mt8188: Add support for SoC power domains")
Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8188.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8188.dtsi b/arch/arm64/boot/dts/mediatek/mt8188.dtsi
index cd27966d2e3c..02a5bb4dbd1f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8188.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8188.dtsi
@@ -956,9 +956,9 @@ mfg0: power-domain@MT8188_POWER_DOMAIN_MFG0 {
 					#size-cells = <0>;
 					#power-domain-cells = <1>;
 
-					power-domain@MT8188_POWER_DOMAIN_MFG1 {
+					mfg1: power-domain@MT8188_POWER_DOMAIN_MFG1 {
 						reg = <MT8188_POWER_DOMAIN_MFG1>;
-						clocks = <&topckgen CLK_APMIXED_MFGPLL>,
+						clocks = <&apmixedsys CLK_APMIXED_MFGPLL>,
 							 <&topckgen CLK_TOP_MFG_CORE_TMP>;
 						clock-names = "mfg", "alt";
 						mediatek,infracfg = <&infracfg_ao>;
-- 
2.45.2

[PATCH v2 2/6] clk: mediatek: clk-mt8188-topckgen: Remove univpll from parents of mfg_core_tmp

[Pablo Sun]

Same as MT8195, MT8188 GPU clock is primarly supplied by the dedicated
mfgpll. The clock "mfg_core_tmp" is only used as an alt clock when
setting mfgpll clock rate.

If we keep the univpll parents from mfg_core_tmp, when setting
GPU frequency to 390000000, the common clock framework would switch
the parent to univpll, instead of setting mfgpll to 390000000:

    mfgpll                            0        0        0   949999756
    univpll                           2        2        0  2340000000
       univpll_d6                     1        1        0   390000000
          top_mfg_core_tmp            1        1        0   390000000
             mfg_ck_fast_ref          1        1        0   390000000
                mfgcfg_bg3d           1        1        0   390000000

This results in failures when subsequent devfreq operations need to
switch to other frequencies. So remove univpll from the parent list.

This solution is taken from commit 72d38ed720e9 ("clk: mediatek:
clk-mt8195-topckgen: Drop univplls from mfg mux parents")

Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/clk/mediatek/clk-mt8188-topckgen.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8188-topckgen.c b/drivers/clk/mediatek/clk-mt8188-topckgen.c
index c4baf4076ed6..6b07abe9a8f5 100644
--- a/drivers/clk/mediatek/clk-mt8188-topckgen.c
+++ b/drivers/clk/mediatek/clk-mt8188-topckgen.c
@@ -342,11 +342,14 @@ static const char * const dsp7_parents[] = {
 	"univpll_d3"
 };
 
+/*
+ * MFG can be also parented to "univpll_d6" and "univpll_d7":
+ * these have been removed from the parents list to let us
+ * achieve GPU DVFS without any special clock handlers.
+ */
 static const char * const mfg_core_tmp_parents[] = {
 	"clk26m",
-	"mainpll_d5_d2",
-	"univpll_d6",
-	"univpll_d7"
+	"mainpll_d5_d2"
 };
 
 static const char * const camtg_parents[] = {
-- 
2.45.2

Re: [PATCH v2 2/6] clk: mediatek: clk-mt8188-topckgen: Remove univpll from parents of mfg_core_tmp

[Stephen Boyd]

Quoting Pablo Sun (2024-09-27 03:30:01)
> Same as MT8195, MT8188 GPU clock is primarly supplied by the dedicated
> mfgpll. The clock "mfg_core_tmp" is only used as an alt clock when
> setting mfgpll clock rate.
> 
> If we keep the univpll parents from mfg_core_tmp, when setting
> GPU frequency to 390000000, the common clock framework would switch
> the parent to univpll, instead of setting mfgpll to 390000000:
> 
>     mfgpll                            0        0        0   949999756
>     univpll                           2        2        0  2340000000
>        univpll_d6                     1        1        0   390000000
>           top_mfg_core_tmp            1        1        0   390000000
>              mfg_ck_fast_ref          1        1        0   390000000
>                 mfgcfg_bg3d           1        1        0   390000000
> 
> This results in failures when subsequent devfreq operations need to
> switch to other frequencies. So remove univpll from the parent list.
> 
> This solution is taken from commit 72d38ed720e9 ("clk: mediatek:
> clk-mt8195-topckgen: Drop univplls from mfg mux parents")
> 
> Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---

Applied to clk-next

[PATCH v2 3/6] nvmem: mtk-efuse: Enable postprocess for mt8188 GPU speed binning

[Pablo Sun]

Similar to mt8186, the efuse data for mt8188's GPU speed binning
requires post-process to convert the bit field format expected
by the OPP table.

Since mt8188 efuse is not compatible to mt8186, add a new compatible
entry for mt8188 and enable postprocess.

Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
---
 drivers/nvmem/mtk-efuse.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
index 9caf04667341..38d26e5c097a 100644
--- a/drivers/nvmem/mtk-efuse.c
+++ b/drivers/nvmem/mtk-efuse.c
@@ -112,6 +112,7 @@ static const struct mtk_efuse_pdata mtk_efuse_pdata = {
 static const struct of_device_id mtk_efuse_of_match[] = {
 	{ .compatible = "mediatek,mt8173-efuse", .data = &mtk_efuse_pdata },
 	{ .compatible = "mediatek,mt8186-efuse", .data = &mtk_mt8186_efuse_pdata },
+	{ .compatible = "mediatek,mt8188-efuse", .data = &mtk_mt8186_efuse_pdata },
 	{ .compatible = "mediatek,efuse", .data = &mtk_efuse_pdata },
 	{/* sentinel */},
 };
-- 
2.45.2

Re: [PATCH v2 3/6] nvmem: mtk-efuse: Enable postprocess for mt8188 GPU speed binning

[AngeloGioacchino Del Regno]

Il 27/09/24 12:30, Pablo Sun ha scritto:
> Similar to mt8186, the efuse data for mt8188's GPU speed binning
> requires post-process to convert the bit field format expected
> by the OPP table.
> 
> Since mt8188 efuse is not compatible to mt8186, add a new compatible
> entry for mt8188 and enable postprocess.
> 
> Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>

I know I told you to just reuse the pdata from 8186, but there's something else
that came to mind, here...

...actually, the efuse block from 8188 is indeed compatible with 8186, meaning
that the register r/w, etc, are all the same (bar the addresses, yes)

So, I wonder if it's not just a better idea to not even add mt8188-efuse in this
driver's of_device_id array, and just add that to the binding so that we permit
using
		efuse: efuse@11f20000 {
			compatible = "mediatek,mt8188-efuse",
				     "mediatek,mt8186-efuse", "mediatek,efuse";
			[etc]
		}

Means that in mediatek,efuse.yaml you'll have to add...

       - items:
           - enum:
               - mediatek,mt8188-efuse
           - const: mediatek,mt8186-efuse
           - const: mediatek,efuse <---- or without this, even.

In the end, the "mediatek,efuse" property is somewhat deprecated, so that'd
also be a good time to start the dropping process, as I imagine that future SoCs
would also need the same speedbin transformations - which means that they'll all
be compatible with 8186....

Cheers,
Angelo

> ---
>   drivers/nvmem/mtk-efuse.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index 9caf04667341..38d26e5c097a 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -112,6 +112,7 @@ static const struct mtk_efuse_pdata mtk_efuse_pdata = {
>   static const struct of_device_id mtk_efuse_of_match[] = {
>   	{ .compatible = "mediatek,mt8173-efuse", .data = &mtk_efuse_pdata },
>   	{ .compatible = "mediatek,mt8186-efuse", .data = &mtk_mt8186_efuse_pdata },
> +	{ .compatible = "mediatek,mt8188-efuse", .data = &mtk_mt8186_efuse_pdata },
>   	{ .compatible = "mediatek,efuse", .data = &mtk_efuse_pdata },
>   	{/* sentinel */},
>   };

Re: [PATCH v2 3/6] nvmem: mtk-efuse: Enable postprocess for mt8188 GPU speed binning

[Pablo Sun]

Hi Angelo,


On 9/30/24 17:40, AngeloGioacchino Del Regno wrote:
> Il 27/09/24 12:30, Pablo Sun ha scritto:
>> Similar to mt8186, the efuse data for mt8188's GPU speed binning
>> requires post-process to convert the bit field format expected
>> by the OPP table.
>>
>> Since mt8188 efuse is not compatible to mt8186, add a new compatible
>> entry for mt8188 and enable postprocess.
>>
>> Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
> 
> I know I told you to just reuse the pdata from 8186, but there's something else
> that came to mind, here...
> 
> ...actually, the efuse block from 8188 is indeed compatible with 8186, meaning
> that the register r/w, etc, are all the same (bar the addresses, yes)
> 
> So, I wonder if it's not just a better idea to not even add mt8188-efuse in this
> driver's of_device_id array, and just add that to the binding so that we permit
> using
>          efuse: efuse@11f20000 {
>              compatible = "mediatek,mt8188-efuse",
>                       "mediatek,mt8186-efuse", "mediatek,efuse";
>              [etc]
>          }

Thanks for proposing this. I agree that in the case of Mali GPU speed binning
info, mt8188 behaves exactly the same as mt8186, only the cell addresses are
different.

I wrote "mt8188 efuse is not compatible to mt8186" because I thought
different eFuse cell layout leads to incompatibility, but it is correct that
the cell layout differences can be expressed by the device tree nodes,
so they are actually compatible in terms of hardware interface.

I'll drop this patch ("nvmem: mtk-efuse: Enable postprocess for mt8188 GPU speed binning")
in v3 and update dt-binding "mediatek,efuse.yaml" instead.

> Means that in mediatek,efuse.yaml you'll have to add...
> 
>        - items:
>            - enum:
>                - mediatek,mt8188-efuse
>            - const: mediatek,mt8186-efuse
>            - const: mediatek,efuse <---- or without this, even.
> 
> In the end, the "mediatek,efuse" property is somewhat deprecated, so that'd
> also be a good time to start the dropping process, as I imagine that future SoCs
> would also need the same speedbin transformations - which means that they'll all
> be compatible with 8186....
[snip]

But I am not sure if we should now drop "mediatek,efuse". The post-process for
GPU speed binning info is only applicable to ARM Mali. Since there are MediaTek
SoCs that are not using ARM Mali, or not having GPU at all, would it make more sense
to keep the "mediatek,efuse" fallback compatible for those cases?


Best regards,
Pablo

Re: [PATCH v2 3/6] nvmem: mtk-efuse: Enable postprocess for mt8188 GPU speed binning

[AngeloGioacchino Del Regno]

Il 01/10/24 05:38, Pablo Sun ha scritto:
> Hi Angelo,
> 
> 
> On 9/30/24 17:40, AngeloGioacchino Del Regno wrote:
>> Il 27/09/24 12:30, Pablo Sun ha scritto:
>>> Similar to mt8186, the efuse data for mt8188's GPU speed binning
>>> requires post-process to convert the bit field format expected
>>> by the OPP table.
>>>
>>> Since mt8188 efuse is not compatible to mt8186, add a new compatible
>>> entry for mt8188 and enable postprocess.
>>>
>>> Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
>>
>> I know I told you to just reuse the pdata from 8186, but there's something else
>> that came to mind, here...
>>
>> ...actually, the efuse block from 8188 is indeed compatible with 8186, meaning
>> that the register r/w, etc, are all the same (bar the addresses, yes)
>>
>> So, I wonder if it's not just a better idea to not even add mt8188-efuse in this
>> driver's of_device_id array, and just add that to the binding so that we permit
>> using
>>          efuse: efuse@11f20000 {
>>              compatible = "mediatek,mt8188-efuse",
>>                       "mediatek,mt8186-efuse", "mediatek,efuse";
>>              [etc]
>>          }
> 
> Thanks for proposing this. I agree that in the case of Mali GPU speed binning
> info, mt8188 behaves exactly the same as mt8186, only the cell addresses are
> different.
> 
> I wrote "mt8188 efuse is not compatible to mt8186" because I thought
> different eFuse cell layout leads to incompatibility, but it is correct that
> the cell layout differences can be expressed by the device tree nodes,
> so they are actually compatible in terms of hardware interface.
> 
> I'll drop this patch ("nvmem: mtk-efuse: Enable postprocess for mt8188 GPU speed 
> binning")
> in v3 and update dt-binding "mediatek,efuse.yaml" instead.
> 
>> Means that in mediatek,efuse.yaml you'll have to add...
>>
>>        - items:
>>            - enum:
>>                - mediatek,mt8188-efuse
>>            - const: mediatek,mt8186-efuse
>>            - const: mediatek,efuse <---- or without this, even.
>>
>> In the end, the "mediatek,efuse" property is somewhat deprecated, so that'd
>> also be a good time to start the dropping process, as I imagine that future SoCs
>> would also need the same speedbin transformations - which means that they'll all
>> be compatible with 8186....
> [snip]
> 
> But I am not sure if we should now drop "mediatek,efuse". The post-process for
> GPU speed binning info is only applicable to ARM Mali. Since there are MediaTek
> SoCs that are not using ARM Mali, or not having GPU at all, would it make more sense
> to keep the "mediatek,efuse" fallback compatible for those cases?
> 
> 

No, not really... because a specific SoC may *either* have Mali *or* PowerVR...

Counting that every SoC will, in any case, need a model-specific compatible (as in,
you can't ever have `compatible = "mediatek,efuse"`, but you will always have
`compatible = "mediatek,mt(model)", "mediatek,mt(othermodel)"` or similar), you
will still have to add that new SoC to the binding.

In case, that SoC can be still added to the list in the driver if there's any
incompatibility with the others (such as different register layout or binning
interpreter).

But then, keep in mind that the code that interprets the binning data in the fuses
is converting it from MediaTek format (1-2-3-4..etc) to the "generic" format that
is required by the OPP framework, which is *not* specific to ARM Mali.

Just to say - if the (MediaTek) format of the fuse data for binning is the same
for both PVR and Mali (so, it's still always 1,2,3,4,etc), then there wouldn't be
any incompatibility between the two, as PVR anyway uses OPP tables as much as Mali.

Cheers,
Angelo

[PATCH v2 4/6] arm64: dts: mediatek: mt8188: Add efuse for GPU speed binning

[Pablo Sun]

The OPP table of mt8188 GPU contains duplicated frequencies
for different speed bins.

In order to support OPP table, we need to provide the speed bin info
in the efuse data so the GPU driver could properly set the
supported hardware speed bin.

Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8188.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8188.dtsi b/arch/arm64/boot/dts/mediatek/mt8188.dtsi
index 02a5bb4dbd1f..129edaf33704 100644
--- a/arch/arm64/boot/dts/mediatek/mt8188.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8188.dtsi
@@ -1752,6 +1752,11 @@ efuse: efuse@11f20000 {
 			lvts_efuse_data1: lvts1-calib@1ac {
 				reg = <0x1ac 0x40>;
 			};
+
+			gpu_speedbin: gpu-speedbin@580 {
+				reg = <0x581 0x1>;
+				bits = <0 3>;
+			};
 		};
 
 		gpu: gpu@13000000 {
@@ -1763,6 +1768,8 @@ gpu: gpu@13000000 {
 				     <GIC_SPI 382 IRQ_TYPE_LEVEL_HIGH 0>,
 				     <GIC_SPI 381 IRQ_TYPE_LEVEL_HIGH 0>;
 			interrupt-names = "job", "mmu", "gpu";
+			nvmem-cells = <&gpu_speedbin>;
+			nvmem-cell-names = "speed-bin";
 			operating-points-v2 = <&gpu_opp_table>;
 			power-domains = <&spm MT8188_POWER_DOMAIN_MFG2>,
 					<&spm MT8188_POWER_DOMAIN_MFG3>,
-- 
2.45.2

[PATCH v2 5/6] soc: mediatek: mediatek-regulator-coupler: Support mt8188

[Pablo Sun]

The Mali GPU in mt8188 also requires coupled power supplies,
that is, the "vsram" voltage should follow the "vgpu" voltage.
Therefore add the compatible to enable this coupling behavior.

Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
---
 drivers/soc/mediatek/mtk-regulator-coupler.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/mediatek/mtk-regulator-coupler.c b/drivers/soc/mediatek/mtk-regulator-coupler.c
index ad2ed42aa697..0b6a2884145e 100644
--- a/drivers/soc/mediatek/mtk-regulator-coupler.c
+++ b/drivers/soc/mediatek/mtk-regulator-coupler.c
@@ -147,6 +147,7 @@ static int mediatek_regulator_coupler_init(void)
 {
 	if (!of_machine_is_compatible("mediatek,mt8183") &&
 	    !of_machine_is_compatible("mediatek,mt8186") &&
+	    !of_machine_is_compatible("mediatek,mt8188") &&
 	    !of_machine_is_compatible("mediatek,mt8192"))
 		return 0;
 
-- 
2.45.2

Re: [PATCH v2 5/6] soc: mediatek: mediatek-regulator-coupler: Support mt8188

[AngeloGioacchino Del Regno]

Il 27/09/24 12:30, Pablo Sun ha scritto:
> The Mali GPU in mt8188 also requires coupled power supplies,
> that is, the "vsram" voltage should follow the "vgpu" voltage.
> Therefore add the compatible to enable this coupling behavior.
> 
> Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

[PATCH v2 6/6] arm64: dts: mediatek: mt8390-genio-700-evk: Enable Mali GPU

[Pablo Sun]

Configure GPU regulator supplies and enable GPU for GENIO 700 EVK.

The GPU in MT8390 & MT8188 has two power inputs: "DVDD_GPU" and
"DVDD_SRAM_GPU". In Genio 700 EVK, DVDD_GPU is supplied by
mt6359_vproc2_buck_reg, and DVDD_SRAM_GPU is supplied by
mt6359_vsram_others_ldo_reg.

According to section 5.2 "Recommended Operating Conditions" in
MT8390 IoT Application Processor Datasheet v1.9, The recommended
operating voltage ranges are:

- DVDD_GPU: min 0.55V, max 0.86V, typical 0.75V
- DVDD_SRAM_GPU: min 0.71V, max 0.92V, typical 0.85V

To further optimize power saving, we couple DVDD_SRAM_GPU to
DVDD_GPU according to the following relation:

- For opp-880000000 or lower frequency, keep 0.75V
- For opp-915000000 and higher, DVDD_SRAM_GPU should follow
  DVDD_GPU. The exact voltage for DVDD_GPU should be decided by
  speed binning.

This rule is derived from the OPP table in the link.

In addition, set the voltage spread to 6250 uV, the step size of
'ldo_vsram_others' regulator of mt6359, otherwise the regulator
set_voltage operation fails.

Link: https://gitlab.com/mediatek/aiot/rity/meta-mediatek-bsp/-/blob/eedd6aedd4b0cfc0ee79b9c9b9650dfa73cf87f6/recipes-kernel/dtbo/mt8390/gpu-mali.dts
Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 .../dts/mediatek/mt8390-genio-700-evk.dts     | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8390-genio-700-evk.dts b/arch/arm64/boot/dts/mediatek/mt8390-genio-700-evk.dts
index 1474bef7e754..0a6c9871b41e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8390-genio-700-evk.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8390-genio-700-evk.dts
@@ -190,6 +190,11 @@ usb_p2_vbus: regulator-10 {
 	};
 };
 
+&gpu {
+	mali-supply = <&mt6359_vproc2_buck_reg>;
+	status = "okay";
+};
+
 &i2c0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c0_pins>;
@@ -253,6 +258,14 @@ &i2c6 {
 	status = "okay";
 };
 
+&mfg0 {
+	domain-supply = <&mt6359_vproc2_buck_reg>;
+};
+
+&mfg1 {
+	domain-supply = <&mt6359_vsram_others_ldo_reg>;
+};
+
 &mmc0 {
 	status = "okay";
 	pinctrl-names = "default", "state_uhs";
@@ -314,6 +327,15 @@ &mt6359_vpa_buck_reg {
 	regulator-max-microvolt = <3100000>;
 };
 
+&mt6359_vproc2_buck_reg {
+	/* The name "vgpu" is required by mtk-regulator-coupler */
+	regulator-name = "vgpu";
+	regulator-min-microvolt = <550000>;
+	regulator-max-microvolt = <800000>;
+	regulator-coupled-with = <&mt6359_vsram_others_ldo_reg>;
+	regulator-coupled-max-spread = <6250>;
+};
+
 &mt6359_vpu_buck_reg {
 	regulator-always-on;
 };
@@ -326,6 +348,15 @@ &mt6359_vsim1_ldo_reg {
 	regulator-enable-ramp-delay = <480>;
 };
 
+&mt6359_vsram_others_ldo_reg {
+	/* The name "vsram_gpu" is required by mtk-regulator-coupler */
+	regulator-name = "vsram_gpu";
+	regulator-min-microvolt = <750000>;
+	regulator-max-microvolt = <800000>;
+	regulator-coupled-with = <&mt6359_vproc2_buck_reg>;
+	regulator-coupled-max-spread = <6250>;
+};
+
 &mt6359_vufs_ldo_reg {
 	regulator-always-on;
 };
-- 
2.45.2

Re: [PATCH v2 6/6] arm64: dts: mediatek: mt8390-genio-700-evk: Enable Mali GPU

[AngeloGioacchino Del Regno]

Il 27/09/24 12:30, Pablo Sun ha scritto:
> Configure GPU regulator supplies and enable GPU for GENIO 700 EVK.
> 
> The GPU in MT8390 & MT8188 has two power inputs: "DVDD_GPU" and
> "DVDD_SRAM_GPU". In Genio 700 EVK, DVDD_GPU is supplied by
> mt6359_vproc2_buck_reg, and DVDD_SRAM_GPU is supplied by
> mt6359_vsram_others_ldo_reg.
> 
> According to section 5.2 "Recommended Operating Conditions" in
> MT8390 IoT Application Processor Datasheet v1.9, The recommended
> operating voltage ranges are:
> 
> - DVDD_GPU: min 0.55V, max 0.86V, typical 0.75V
> - DVDD_SRAM_GPU: min 0.71V, max 0.92V, typical 0.85V
> 
> To further optimize power saving, we couple DVDD_SRAM_GPU to
> DVDD_GPU according to the following relation:
> 
> - For opp-880000000 or lower frequency, keep 0.75V
> - For opp-915000000 and higher, DVDD_SRAM_GPU should follow
>    DVDD_GPU. The exact voltage for DVDD_GPU should be decided by
>    speed binning.
> 
> This rule is derived from the OPP table in the link.
> 
> In addition, set the voltage spread to 6250 uV, the step size of
> 'ldo_vsram_others' regulator of mt6359, otherwise the regulator
> set_voltage operation fails.
> 
> Link: https://gitlab.com/mediatek/aiot/rity/meta-mediatek-bsp/-/blob/eedd6aedd4b0cfc0ee79b9c9b9650dfa73cf87f6/recipes-kernel/dtbo/mt8390/gpu-mali.dts
> Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
> Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>