[PATCH 0/2] MediaTek Helio X10 MT6795 - M4U/IOMMU Support

[PATCH 0/2] MediaTek Helio X10 MT6795 - M4U/IOMMU Support

[AngeloGioacchino Del Regno]

In an effort to give some love to the apparently forgotten MT6795 SoC,
I am upstreaming more components that are necessary to support platforms
powered by this one apart from a simple boot to serial console.

This series introduces support for the IOMMUs found on this SoC.

Tested on a MT6795 Sony Xperia M5 (codename "Holly") smartphone.

AngeloGioacchino Del Regno (2):
  dt-bindings: mediatek: Add bindings for MT6795 M4U
  iommu: mtk_iommu: Add support for MT6795 Helio X10 M4Us

 .../bindings/iommu/mediatek,iommu.yaml        |  3 +
 drivers/iommu/mtk_iommu.c                     | 20 +++-
 include/dt-bindings/memory/mt6795-larb-port.h | 96 +++++++++++++++++++
 3 files changed, 118 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/memory/mt6795-larb-port.h

-- 
2.35.1

[PATCH 1/2] dt-bindings: mediatek: Add bindings for MT6795 M4U

[AngeloGioacchino Del Regno]

Add bindings for the MediaTek Helio X10 (MT6795) IOMMU/M4U.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 .../bindings/iommu/mediatek,iommu.yaml        |  3 +
 include/dt-bindings/memory/mt6795-larb-port.h | 96 +++++++++++++++++++
 2 files changed, 99 insertions(+)
 create mode 100644 include/dt-bindings/memory/mt6795-larb-port.h

diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
index 2ae3bbad7f1a..59c5fb122061 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
@@ -73,6 +73,7 @@ properties:
           - mediatek,mt2701-m4u  # generation one
           - mediatek,mt2712-m4u  # generation two
           - mediatek,mt6779-m4u  # generation two
+          - mediatek,mt6795-m4u  # generation two
           - mediatek,mt8167-m4u  # generation two
           - mediatek,mt8173-m4u  # generation two
           - mediatek,mt8183-m4u  # generation two
@@ -120,6 +121,7 @@ properties:
       dt-binding/memory/mt2701-larb-port.h for mt2701 and mt7623,
       dt-binding/memory/mt2712-larb-port.h for mt2712,
       dt-binding/memory/mt6779-larb-port.h for mt6779,
+      dt-binding/memory/mt6795-larb-port.h for mt6795,
       dt-binding/memory/mt8167-larb-port.h for mt8167,
       dt-binding/memory/mt8173-larb-port.h for mt8173,
       dt-binding/memory/mt8183-larb-port.h for mt8183,
@@ -144,6 +146,7 @@ allOf:
             enum:
               - mediatek,mt2701-m4u
               - mediatek,mt2712-m4u
+              - mediatek,mt6795-m4u
               - mediatek,mt8173-m4u
               - mediatek,mt8186-iommu-mm
               - mediatek,mt8192-m4u
diff --git a/include/dt-bindings/memory/mt6795-larb-port.h b/include/dt-bindings/memory/mt6795-larb-port.h
new file mode 100644
index 000000000000..2243bb6414f3
--- /dev/null
+++ b/include/dt-bindings/memory/mt6795-larb-port.h
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) */
+/*
+ * Copyright (c) 2022 Collabora Ltd.
+ * Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ */
+
+#ifndef _DT_BINDINGS_MEMORY_MT6795_LARB_PORT_H_
+#define _DT_BINDINGS_MEMORY_MT6795_LARB_PORT_H_
+
+#include <dt-bindings/memory/mtk-memory-port.h>
+
+#define M4U_LARB0_ID			0
+#define M4U_LARB1_ID			1
+#define M4U_LARB2_ID			2
+#define M4U_LARB3_ID			3
+#define M4U_LARB4_ID			4
+#define M4U_LARB5_ID			5
+
+/* larb0 */
+#define M4U_PORT_DISP_OVL0		MTK_M4U_ID(M4U_LARB0_ID, 0)
+#define M4U_PORT_DISP_RDMA0		MTK_M4U_ID(M4U_LARB0_ID, 1)
+#define M4U_PORT_DISP_RDMA1		MTK_M4U_ID(M4U_LARB0_ID, 2)
+#define M4U_PORT_DISP_WDMA0		MTK_M4U_ID(M4U_LARB0_ID, 3)
+#define M4U_PORT_DISP_OVL1		MTK_M4U_ID(M4U_LARB0_ID, 4)
+#define M4U_PORT_DISP_RDMA2		MTK_M4U_ID(M4U_LARB0_ID, 5)
+#define M4U_PORT_DISP_WDMA1		MTK_M4U_ID(M4U_LARB0_ID, 6)
+#define M4U_PORT_DISP_OD_R		MTK_M4U_ID(M4U_LARB0_ID, 7)
+#define M4U_PORT_DISP_OD_W		MTK_M4U_ID(M4U_LARB0_ID, 8)
+#define M4U_PORT_MDP_RDMA0		MTK_M4U_ID(M4U_LARB0_ID, 9)
+#define M4U_PORT_MDP_RDMA1		MTK_M4U_ID(M4U_LARB0_ID, 10)
+#define M4U_PORT_MDP_WDMA		MTK_M4U_ID(M4U_LARB0_ID, 11)
+#define M4U_PORT_MDP_WROT0		MTK_M4U_ID(M4U_LARB0_ID, 12)
+#define M4U_PORT_MDP_WROT1		MTK_M4U_ID(M4U_LARB0_ID, 13)
+
+/* larb1 */
+#define M4U_PORT_VDEC_MC		MTK_M4U_ID(M4U_LARB1_ID, 0)
+#define M4U_PORT_VDEC_PP		MTK_M4U_ID(M4U_LARB1_ID, 1)
+#define M4U_PORT_VDEC_UFO		MTK_M4U_ID(M4U_LARB1_ID, 2)
+#define M4U_PORT_VDEC_VLD		MTK_M4U_ID(M4U_LARB1_ID, 3)
+#define M4U_PORT_VDEC_VLD2		MTK_M4U_ID(M4U_LARB1_ID, 4)
+#define M4U_PORT_VDEC_AVC_MV		MTK_M4U_ID(M4U_LARB1_ID, 5)
+#define M4U_PORT_VDEC_PRED_RD		MTK_M4U_ID(M4U_LARB1_ID, 6)
+#define M4U_PORT_VDEC_PRED_WR		MTK_M4U_ID(M4U_LARB1_ID, 7)
+#define M4U_PORT_VDEC_PPWRAP		MTK_M4U_ID(M4U_LARB1_ID, 8)
+
+/* larb2 */
+#define M4U_PORT_CAM_IMGO		MTK_M4U_ID(M4U_LARB2_ID, 0)
+#define M4U_PORT_CAM_RRZO		MTK_M4U_ID(M4U_LARB2_ID, 1)
+#define M4U_PORT_CAM_AAO		MTK_M4U_ID(M4U_LARB2_ID, 2)
+#define M4U_PORT_CAM_LCSO		MTK_M4U_ID(M4U_LARB2_ID, 3)
+#define M4U_PORT_CAM_ESFKO		MTK_M4U_ID(M4U_LARB2_ID, 4)
+#define M4U_PORT_CAM_IMGO_S		MTK_M4U_ID(M4U_LARB2_ID, 5)
+#define M4U_PORT_CAM_LSCI		MTK_M4U_ID(M4U_LARB2_ID, 6)
+#define M4U_PORT_CAM_LSCI_D		MTK_M4U_ID(M4U_LARB2_ID, 7)
+#define M4U_PORT_CAM_BPCI		MTK_M4U_ID(M4U_LARB2_ID, 8)
+#define M4U_PORT_CAM_BPCI_D		MTK_M4U_ID(M4U_LARB2_ID, 9)
+#define M4U_PORT_CAM_UFDI		MTK_M4U_ID(M4U_LARB2_ID, 10)
+#define M4U_PORT_CAM_IMGI		MTK_M4U_ID(M4U_LARB2_ID, 11)
+#define M4U_PORT_CAM_IMG2O		MTK_M4U_ID(M4U_LARB2_ID, 12)
+#define M4U_PORT_CAM_IMG3O		MTK_M4U_ID(M4U_LARB2_ID, 13)
+#define M4U_PORT_CAM_VIPI		MTK_M4U_ID(M4U_LARB2_ID, 14)
+#define M4U_PORT_CAM_VIP2I		MTK_M4U_ID(M4U_LARB2_ID, 15)
+#define M4U_PORT_CAM_VIP3I		MTK_M4U_ID(M4U_LARB2_ID, 16)
+#define M4U_PORT_CAM_LCEI		MTK_M4U_ID(M4U_LARB2_ID, 17)
+#define M4U_PORT_CAM_RB			MTK_M4U_ID(M4U_LARB2_ID, 18)
+#define M4U_PORT_CAM_RP			MTK_M4U_ID(M4U_LARB2_ID, 19)
+#define M4U_PORT_CAM_WR			MTK_M4U_ID(M4U_LARB2_ID, 20)
+
+/* larb3 */
+#define M4U_PORT_VENC_RCPU		MTK_M4U_ID(M4U_LARB3_ID, 0)
+#define M4U_PORT_VENC_REC		MTK_M4U_ID(M4U_LARB3_ID, 1)
+#define M4U_PORT_VENC_BSDMA		MTK_M4U_ID(M4U_LARB3_ID, 2)
+#define M4U_PORT_VENC_SV_COMV		MTK_M4U_ID(M4U_LARB3_ID, 3)
+#define M4U_PORT_VENC_RD_COMV		MTK_M4U_ID(M4U_LARB3_ID, 4)
+#define M4U_PORT_JPGENC_BSDMA		MTK_M4U_ID(M4U_LARB3_ID, 5)
+#define M4U_PORT_REMDC_SDMA		MTK_M4U_ID(M4U_LARB3_ID, 6)
+#define M4U_PORT_REMDC_BSDMA		MTK_M4U_ID(M4U_LARB3_ID, 7)
+#define M4U_PORT_JPGENC_RDMA		MTK_M4U_ID(M4U_LARB3_ID, 8)
+#define M4U_PORT_JPGENC_SDMA		MTK_M4U_ID(M4U_LARB3_ID, 9)
+#define M4U_PORT_JPGDEC_WDMA		MTK_M4U_ID(M4U_LARB3_ID, 10)
+#define M4U_PORT_JPGDEC_BSDMA		MTK_M4U_ID(M4U_LARB3_ID, 11)
+#define M4U_PORT_VENC_CUR_LUMA		MTK_M4U_ID(M4U_LARB3_ID, 12)
+#define M4U_PORT_VENC_CUR_CHROMA	MTK_M4U_ID(M4U_LARB3_ID, 13)
+#define M4U_PORT_VENC_REF_LUMA		MTK_M4U_ID(M4U_LARB3_ID, 14)
+#define M4U_PORT_VENC_REF_CHROMA	MTK_M4U_ID(M4U_LARB3_ID, 15)
+#define M4U_PORT_REMDC_WDMA		MTK_M4U_ID(M4U_LARB3_ID, 16)
+#define M4U_PORT_VENC_NBM_RDMA		MTK_M4U_ID(M4U_LARB3_ID, 17)
+#define M4U_PORT_VENC_NBM_WDMA		MTK_M4U_ID(M4U_LARB3_ID, 18)
+
+/* larb4 */
+#define M4U_PORT_MJC_MV_RD		MTK_M4U_ID(M4U_LARB4_ID, 0)
+#define M4U_PORT_MJC_MV_WR		MTK_M4U_ID(M4U_LARB4_ID, 1)
+#define M4U_PORT_MJC_DMA_RD		MTK_M4U_ID(M4U_LARB4_ID, 2)
+#define M4U_PORT_MJC_DMA_WR		MTK_M4U_ID(M4U_LARB4_ID, 3)
+
+#endif
-- 
2.35.1

[PATCH 2/2] iommu: mtk_iommu: Add support for MT6795 Helio X10 M4Us

[AngeloGioacchino Del Regno]

Add support for the M4Us found in the MT6795 Helio X10 SoC.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/iommu/mtk_iommu.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 71b2ace74cd6..3d802dd3f377 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -157,6 +157,7 @@
 enum mtk_iommu_plat {
 	M4U_MT2712,
 	M4U_MT6779,
+	M4U_MT6795,
 	M4U_MT8167,
 	M4U_MT8173,
 	M4U_MT8183,
@@ -953,7 +954,8 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data, unsigned int ban
 	 * Global control settings are in bank0. May re-init these global registers
 	 * since no sure if there is bank0 consumers.
 	 */
-	if (data->plat_data->m4u_plat == M4U_MT8173) {
+	if (data->plat_data->m4u_plat == M4U_MT6795 ||
+	    data->plat_data->m4u_plat == M4U_MT8173) {
 		regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
 			 F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
 	} else {
@@ -1138,6 +1140,9 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 		case M4U_MT2712:
 			p = "mediatek,mt2712-infracfg";
 			break;
+		case M4U_MT6795:
+			p = "mediatek,mt6795-infracfg";
+			break;
 		case M4U_MT8173:
 			p = "mediatek,mt8173-infracfg";
 			break;
@@ -1404,6 +1409,18 @@ static const struct mtk_iommu_plat_data mt6779_data = {
 	.larbid_remap  = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
 };
 
+static const struct mtk_iommu_plat_data mt6795_data = {
+	.m4u_plat     = M4U_MT6795,
+	.flags	      = HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
+			HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM,
+	.inv_sel_reg  = REG_MMU_INV_SEL_GEN1,
+	.banks_num    = 1,
+	.banks_enable = {true},
+	.iova_region  = single_domain,
+	.iova_region_nr = ARRAY_SIZE(single_domain),
+	.larbid_remap = {{0}, {1}, {2}, {3}, {4}}, /* Linear mapping. */
+};
+
 static const struct mtk_iommu_plat_data mt8167_data = {
 	.m4u_plat     = M4U_MT8167,
 	.flags        = RESET_AXI | HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM,
@@ -1515,6 +1532,7 @@ static const struct mtk_iommu_plat_data mt8195_data_vpp = {
 static const struct of_device_id mtk_iommu_of_ids[] = {
 	{ .compatible = "mediatek,mt2712-m4u", .data = &mt2712_data},
 	{ .compatible = "mediatek,mt6779-m4u", .data = &mt6779_data},
+	{ .compatible = "mediatek,mt6795-m4u", .data = &mt6795_data},
 	{ .compatible = "mediatek,mt8167-m4u", .data = &mt8167_data},
 	{ .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
 	{ .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
-- 
2.35.1

Re: [PATCH 1/2] dt-bindings: mediatek: Add bindings for MT6795 M4U

[Rob Herring]

On Fri, 13 May 2022 17:14:10 +0200, AngeloGioacchino Del Regno wrote:
> Add bindings for the MediaTek Helio X10 (MT6795) IOMMU/M4U.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  .../bindings/iommu/mediatek,iommu.yaml        |  3 +
>  include/dt-bindings/memory/mt6795-larb-port.h | 96 +++++++++++++++++++
>  2 files changed, 99 insertions(+)
>  create mode 100644 include/dt-bindings/memory/mt6795-larb-port.h
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH 2/2] iommu: mtk_iommu: Add support for MT6795 Helio X10 M4Us

[Yong Wu]

On Fri, 2022-05-13 at 17:14 +0200, AngeloGioacchino Del Regno wrote:
> Add support for the M4Us found in the MT6795 Helio X10 SoC.
> 
> Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delregno@collabora.com>
> ---
>  drivers/iommu/mtk_iommu.c | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 71b2ace74cd6..3d802dd3f377 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -157,6 +157,7 @@
>  enum mtk_iommu_plat {
>  	M4U_MT2712,
>  	M4U_MT6779,
> +	M4U_MT6795,
>  	M4U_MT8167,
>  	M4U_MT8173,
>  	M4U_MT8183,
> @@ -953,7 +954,8 @@ static int mtk_iommu_hw_init(const struct
> mtk_iommu_data *data, unsigned int ban
>  	 * Global control settings are in bank0. May re-init these
> global registers
>  	 * since no sure if there is bank0 consumers.
>  	 */
> -	if (data->plat_data->m4u_plat == M4U_MT8173) {
> +	if (data->plat_data->m4u_plat == M4U_MT6795 ||
> +	    data->plat_data->m4u_plat == M4U_MT8173) {
>  		regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
>  			 F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
>  	} else {
> @@ -1138,6 +1140,9 @@ static int mtk_iommu_probe(struct
> platform_device *pdev)
>  		case M4U_MT2712:
>  			p = "mediatek,mt2712-infracfg";
>  			break;
> +		case M4U_MT6795:
> +			p = "mediatek,mt6795-infracfg";
> +			break;
>  		case M4U_MT8173:
>  			p = "mediatek,mt8173-infracfg";
>  			break;
> @@ -1404,6 +1409,18 @@ static const struct mtk_iommu_plat_data
> mt6779_data = {
>  	.larbid_remap  = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
>  };
>  
> +static const struct mtk_iommu_plat_data mt6795_data = {
> +	.m4u_plat     = M4U_MT6795,
> +	.flags	      = HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
> +			HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM,
> +	.inv_sel_reg  = REG_MMU_INV_SEL_GEN1,
> +	.banks_num    = 1,
> +	.banks_enable = {true},
> +	.iova_region  = single_domain,
> +	.iova_region_nr = ARRAY_SIZE(single_domain),
> +	.larbid_remap = {{0}, {1}, {2}, {3}, {4}}, /* Linear mapping.
> */
> +};

This is nearly same with mt8173_data. mt8173 has one more larb than
mt6795, its larbid_remap is also ok for mt6795.

thus it looks we could use mt8173 as the backward compatible.
    compatible = "mediatek,mt6795-m4u",
                 "mediatek,mt8173-m4u";

After this, the only thing is about "mediatek,mt6795-infracfg". we have
to try again with mediatek,mt6795-infracfg after mediatek,mt8173-
infracfg fail. I think we should allow the backward case in 4GB mode
judgment if we have.

What's your opinion? or some other suggestion?
Thanks.

> +
>  static const struct mtk_iommu_plat_data mt8167_data = {
>  	.m4u_plat     = M4U_MT8167,
>  	.flags        = RESET_AXI | HAS_LEGACY_IVRP_PADDR |
> MTK_IOMMU_TYPE_MM,
> @@ -1515,6 +1532,7 @@ static const struct mtk_iommu_plat_data
> mt8195_data_vpp = {
>  static const struct of_device_id mtk_iommu_of_ids[] = {
>  	{ .compatible = "mediatek,mt2712-m4u", .data = &mt2712_data},
>  	{ .compatible = "mediatek,mt6779-m4u", .data = &mt6779_data},
> +	{ .compatible = "mediatek,mt6795-m4u", .data = &mt6795_data},
>  	{ .compatible = "mediatek,mt8167-m4u", .data = &mt8167_data},
>  	{ .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
>  	{ .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},

Re: [PATCH 2/2] iommu: mtk_iommu: Add support for MT6795 Helio X10 M4Us

[AngeloGioacchino Del Regno]

Il 17/05/22 11:08, Yong Wu ha scritto:
> On Fri, 2022-05-13 at 17:14 +0200, AngeloGioacchino Del Regno wrote:
>> Add support for the M4Us found in the MT6795 Helio X10 SoC.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <
>> angelogioacchino.delregno@collabora.com>
>> ---
>>   drivers/iommu/mtk_iommu.c | 20 +++++++++++++++++++-
>>   1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>> index 71b2ace74cd6..3d802dd3f377 100644
>> --- a/drivers/iommu/mtk_iommu.c
>> +++ b/drivers/iommu/mtk_iommu.c
>> @@ -157,6 +157,7 @@
>>   enum mtk_iommu_plat {
>>   	M4U_MT2712,
>>   	M4U_MT6779,
>> +	M4U_MT6795,
>>   	M4U_MT8167,
>>   	M4U_MT8173,
>>   	M4U_MT8183,
>> @@ -953,7 +954,8 @@ static int mtk_iommu_hw_init(const struct
>> mtk_iommu_data *data, unsigned int ban
>>   	 * Global control settings are in bank0. May re-init these
>> global registers
>>   	 * since no sure if there is bank0 consumers.
>>   	 */
>> -	if (data->plat_data->m4u_plat == M4U_MT8173) {
>> +	if (data->plat_data->m4u_plat == M4U_MT6795 ||
>> +	    data->plat_data->m4u_plat == M4U_MT8173) {
>>   		regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
>>   			 F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
>>   	} else {
>> @@ -1138,6 +1140,9 @@ static int mtk_iommu_probe(struct
>> platform_device *pdev)
>>   		case M4U_MT2712:
>>   			p = "mediatek,mt2712-infracfg";
>>   			break;
>> +		case M4U_MT6795:
>> +			p = "mediatek,mt6795-infracfg";
>> +			break;
>>   		case M4U_MT8173:
>>   			p = "mediatek,mt8173-infracfg";
>>   			break;
>> @@ -1404,6 +1409,18 @@ static const struct mtk_iommu_plat_data
>> mt6779_data = {
>>   	.larbid_remap  = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
>>   };
>>   
>> +static const struct mtk_iommu_plat_data mt6795_data = {
>> +	.m4u_plat     = M4U_MT6795,
>> +	.flags	      = HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
>> +			HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM,
>> +	.inv_sel_reg  = REG_MMU_INV_SEL_GEN1,
>> +	.banks_num    = 1,
>> +	.banks_enable = {true},
>> +	.iova_region  = single_domain,
>> +	.iova_region_nr = ARRAY_SIZE(single_domain),
>> +	.larbid_remap = {{0}, {1}, {2}, {3}, {4}}, /* Linear mapping.
>> */
>> +};
> 
> This is nearly same with mt8173_data. mt8173 has one more larb than
> mt6795, its larbid_remap is also ok for mt6795.
> 

I think that we should be explicit about the larbid_remap property,
since mt6795 has one less larb, we should explicitly say that like
I did there... that's only for human readability I admit ... but,
still, I wouldn't want to see people thinking that MT6795 has 6 LARBs
because they've read that larbid_remap having 6 entries.

> thus it looks we could use mt8173 as the backward compatible.
>      compatible = "mediatek,mt6795-m4u",
>                   "mediatek,mt8173-m4u";
> 
> After this, the only thing is about "mediatek,mt6795-infracfg". we have
> to try again with mediatek,mt6795-infracfg after mediatek,mt8173-
> infracfg fail. I think we should allow the backward case in 4GB mode
> judgment if we have.
> 
> What's your opinion? or some other suggestion?
> Thanks.

I know, I may have a plan for that, but I wanted to have a good reason to
propose such a thing, as if it's just about two SoCs needing that, there
would be no good reason to get things done differently.

...so, in order to provide a good cleanup, we have two possible roads to
follow here: either we add a generic "mediatek,infracfg" compatible to the
infra node (but I don't like that), or we can do it like it was previously
done in mtk-pm-domains.c (I prefer that approach):

iommu: iommu@somewhere {
	... something ...
	mediatek,infracfg = <&infracfg>;
};

infracfg = syscon_regmap_lookup_by_compatible(node, "mediatek,infracfg");
if (IS_ERR(infracfg)) {
	/* try with the older way */
	switch (...) {
	case .... p = "mediatek,mt2712-infracfg";
	... blah blah ...
	}
	/* legacy also failed, ouch! */
	if (IS_ERR(infracfg))
		return PTR_ERR(infracfg);
}

ret = regmap_read ... etc etc etc

Cheers,
Angelo

Re: [PATCH 2/2] iommu: mtk_iommu: Add support for MT6795 Helio X10 M4Us

[Matthias Brugger]

On 17/05/2022 11:26, AngeloGioacchino Del Regno wrote:
> Il 17/05/22 11:08, Yong Wu ha scritto:
>> On Fri, 2022-05-13 at 17:14 +0200, AngeloGioacchino Del Regno wrote:
>>> Add support for the M4Us found in the MT6795 Helio X10 SoC.
>>>
>>> Signed-off-by: AngeloGioacchino Del Regno <
>>> angelogioacchino.delregno@collabora.com>
>>> ---
>>>   drivers/iommu/mtk_iommu.c | 20 +++++++++++++++++++-
>>>   1 file changed, 19 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index 71b2ace74cd6..3d802dd3f377 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -157,6 +157,7 @@
>>>   enum mtk_iommu_plat {
>>>       M4U_MT2712,
>>>       M4U_MT6779,
>>> +    M4U_MT6795,
>>>       M4U_MT8167,
>>>       M4U_MT8173,
>>>       M4U_MT8183,
>>> @@ -953,7 +954,8 @@ static int mtk_iommu_hw_init(const struct
>>> mtk_iommu_data *data, unsigned int ban
>>>        * Global control settings are in bank0. May re-init these
>>> global registers
>>>        * since no sure if there is bank0 consumers.
>>>        */
>>> -    if (data->plat_data->m4u_plat == M4U_MT8173) {
>>> +    if (data->plat_data->m4u_plat == M4U_MT6795 ||
>>> +        data->plat_data->m4u_plat == M4U_MT8173) {
>>>           regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
>>>                F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
>>>       } else {
>>> @@ -1138,6 +1140,9 @@ static int mtk_iommu_probe(struct
>>> platform_device *pdev)
>>>           case M4U_MT2712:
>>>               p = "mediatek,mt2712-infracfg";
>>>               break;
>>> +        case M4U_MT6795:
>>> +            p = "mediatek,mt6795-infracfg";
>>> +            break;
>>>           case M4U_MT8173:
>>>               p = "mediatek,mt8173-infracfg";
>>>               break;
>>> @@ -1404,6 +1409,18 @@ static const struct mtk_iommu_plat_data
>>> mt6779_data = {
>>>       .larbid_remap  = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
>>>   };
>>> +static const struct mtk_iommu_plat_data mt6795_data = {
>>> +    .m4u_plat     = M4U_MT6795,
>>> +    .flags          = HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
>>> +            HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM,
>>> +    .inv_sel_reg  = REG_MMU_INV_SEL_GEN1,
>>> +    .banks_num    = 1,
>>> +    .banks_enable = {true},
>>> +    .iova_region  = single_domain,
>>> +    .iova_region_nr = ARRAY_SIZE(single_domain),
>>> +    .larbid_remap = {{0}, {1}, {2}, {3}, {4}}, /* Linear mapping.
>>> */
>>> +};
>>
>> This is nearly same with mt8173_data. mt8173 has one more larb than
>> mt6795, its larbid_remap is also ok for mt6795.
>>
> 
> I think that we should be explicit about the larbid_remap property,
> since mt6795 has one less larb, we should explicitly say that like
> I did there... that's only for human readability I admit ... but,
> still, I wouldn't want to see people thinking that MT6795 has 6 LARBs
> because they've read that larbid_remap having 6 entries.
> 
>> thus it looks we could use mt8173 as the backward compatible.
>>      compatible = "mediatek,mt6795-m4u",
>>                   "mediatek,mt8173-m4u";
>>
>> After this, the only thing is about "mediatek,mt6795-infracfg". we have
>> to try again with mediatek,mt6795-infracfg after mediatek,mt8173-
>> infracfg fail. I think we should allow the backward case in 4GB mode
>> judgment if we have.
>>
>> What's your opinion? or some other suggestion?
>> Thanks.
> 
> I know, I may have a plan for that, but I wanted to have a good reason to
> propose such a thing, as if it's just about two SoCs needing that, there
> would be no good reason to get things done differently.
> 
> ...so, in order to provide a good cleanup, we have two possible roads to
> follow here: either we add a generic "mediatek,infracfg" compatible to the
> infra node (but I don't like that), or we can do it like it was previously
> done in mtk-pm-domains.c (I prefer that approach):
> 
> iommu: iommu@somewhere {
>      ... something ...
>      mediatek,infracfg = <&infracfg>;
> };
> 
> infracfg = syscon_regmap_lookup_by_compatible(node, "mediatek,infracfg");
> if (IS_ERR(infracfg)) {
>      /* try with the older way */
>      switch (...) {
>      case .... p = "mediatek,mt2712-infracfg";
>      ... blah blah ...
>      }
>      /* legacy also failed, ouch! */
>      if (IS_ERR(infracfg))
>          return PTR_ERR(infracfg);
> }
> 
> ret = regmap_read ... etc etc etc
> 

I prefer that approach as well.

Regards,
Matthias

> Cheers,
> Angelo

Re: [PATCH 1/2] dt-bindings: mediatek: Add bindings for MT6795 M4U

[AngeloGioacchino Del Regno]

Il 16/05/22 18:03, Rob Herring ha scritto:
> On Fri, 13 May 2022 17:14:10 +0200, AngeloGioacchino Del Regno wrote:
>> Add bindings for the MediaTek Helio X10 (MT6795) IOMMU/M4U.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> ---
>>   .../bindings/iommu/mediatek,iommu.yaml        |  3 +
>>   include/dt-bindings/memory/mt6795-larb-port.h | 96 +++++++++++++++++++
>>   2 files changed, 99 insertions(+)
>>   create mode 100644 include/dt-bindings/memory/mt6795-larb-port.h
>>
> 
> Acked-by: Rob Herring <robh@kernel.org>


Hello Rob,

I'm sad to say that, but I have to send a new version of this patch even though
you have acked it already... and I will have to drop your ack, as the changes to
the yaml patch will be a bit different, as we're adding support for a phandle
to mediatek,infracfg after some discussion about it on patch 2/2 of this series.

The mediatek,infracfg phandle addition will come as a different series, and this
patch (on v2) will add a conditional for:

   - if:

       properties:

         compatible:

           contains:

             enum:

               - mediatek,mt6795-m4u

     then:

       required:

         - mediatek,infracfg

Sorry about wasting your time on this v1.

Regards,
Angelo

Re: [PATCH 2/2] iommu: mtk_iommu: Add support for MT6795 Helio X10 M4Us

[Yong Wu]

On Tue, 2022-05-17 at 11:26 +0200, AngeloGioacchino Del Regno wrote:
> Il 17/05/22 11:08, Yong Wu ha scritto:
> > On Fri, 2022-05-13 at 17:14 +0200, AngeloGioacchino Del Regno
> > wrote:
> > > Add support for the M4Us found in the MT6795 Helio X10 SoC.
> > > 
> > > Signed-off-by: AngeloGioacchino Del Regno <
> > > angelogioacchino.delregno@collabora.com>
> > > ---
> > >   drivers/iommu/mtk_iommu.c | 20 +++++++++++++++++++-
> > >   1 file changed, 19 insertions(+), 1 deletion(-)

[...]

> > > +static const struct mtk_iommu_plat_data mt6795_data = {
> > > +	.m4u_plat     = M4U_MT6795,
> > > +	.flags	      = HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
> > > +			HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM,
> > > +	.inv_sel_reg  = REG_MMU_INV_SEL_GEN1,
> > > +	.banks_num    = 1,
> > > +	.banks_enable = {true},
> > > +	.iova_region  = single_domain,
> > > +	.iova_region_nr = ARRAY_SIZE(single_domain),
> > > +	.larbid_remap = {{0}, {1}, {2}, {3}, {4}}, /* Linear mapping.
> > > */
> > > +};
> > 
> > This is nearly same with mt8173_data. mt8173 has one more larb than
> > mt6795, its larbid_remap is also ok for mt6795.
> > 
> 
> I think that we should be explicit about the larbid_remap property,
> since mt6795 has one less larb, we should explicitly say that like
> I did there... that's only for human readability I admit ... but,
> still, I wouldn't want to see people thinking that MT6795 has 6 LARBs
> because they've read that larbid_remap having 6 entries.

In the linear mapping case, It does help. Strictly larbid_remap is two-
dimensional array now, It doesn't indicate how many larbs this SoC
has. If someone would like to know this, he could read the mtxxx-larb-
port.h. We also could document the larb numbers in the binding
for readability.

Anyway, It is not a big problem. A new structure is ok for me. I just
complain there are too many structures, specially in the internal
branch which contains many non-upstream SoCs, and there may be several
IOMMU HWs in one SoC. thus I'd like to group it personally.

> 
> > thus it looks we could use mt8173 as the backward compatible.
> >      compatible = "mediatek,mt6795-m4u",
> >                   "mediatek,mt8173-m4u";
> > 
> > After this, the only thing is about "mediatek,mt6795-infracfg". we
> > have
> > to try again with mediatek,mt6795-infracfg after mediatek,mt8173-
> > infracfg fail. I think we should allow the backward case in 4GB
> > mode
> > judgment if we have.
> > 
> > What's your opinion? or some other suggestion?
> > Thanks.
> 
> I know, I may have a plan for that, but I wanted to have a good
> reason to
> propose such a thing, as if it's just about two SoCs needing that,
> there
> would be no good reason to get things done differently.
> 
> ...so, in order to provide a good cleanup, we have two possible roads
> to
> follow here: either we add a generic "mediatek,infracfg" compatible
> to the
> infra node (but I don't like that), or we can do it like it was
> previously
> done in mtk-pm-domains.c (I prefer that approach):
> 
> iommu: iommu@somewhere {
> 	... something ...
> 	mediatek,infracfg = <&infracfg>;

We like this too. But this was not suggested from Rob long before.

https://lore.kernel.org/linux-mediatek/20200715205120.GA778876@bogus/

> };
> 
> infracfg = syscon_regmap_lookup_by_compatible(node,
> "mediatek,infracfg");
> if (IS_ERR(infracfg)) {
> 	/* try with the older way */
> 	switch (...) {
> 	case .... p = "mediatek,mt2712-infracfg";
> 	... blah blah ...
> 	}
> 	/* legacy also failed, ouch! */
> 	if (IS_ERR(infracfg))
> 		return PTR_ERR(infracfg);
> }
> 
> ret = regmap_read ... etc etc etc
> 
> Cheers,
> Angelo