[PATCH 0/2] MT8173 IOMMU 4GB MODE SUPPORT

[PATCH 0/2] MT8173 IOMMU 4GB MODE SUPPORT

[Yong Wu]

  This patch-set add MTK 4GB mode support on the Short-Descriptor.
MTK extend the bit9 of the standard pgtable descriptor as the 4GB mode.
We add a special quirk for this.
  This two patches are based on Robin's Short-decriptor v3[1], MTK
IOMMU v10[2] and Robin's "Rationalise quirk handling"[3].

[1]: http://lists.linuxfoundation.org/pipermail/iommu/2016-January/015463.html
[2]: http://lists.linuxfoundation.org/pipermail/iommu/2016-February/015795.html
[3]: http://lists.linuxfoundation.org/pipermail/iommu/2016-February/015663.html

Yong Wu (2):
  iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor
  iommu/mediatek: Add 4GB mode support

 drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
 drivers/iommu/io-pgtable.h         |  6 ++++++
 drivers/iommu/mtk_iommu.c          | 14 +++++++++++---
 3 files changed, 30 insertions(+), 4 deletions(-)

-- 
1.8.1.1.dirty 

[PATCH 0/2] MT8173 IOMMU 4GB MODE SUPPORT

[Yong Wu]

  This patch-set add MTK 4GB mode support on the Short-Descriptor.
MTK extend the bit9 of the standard pgtable descriptor as the 4GB mode.
We add a special quirk for this.
  This two patches are based on Robin's Short-decriptor v3[1], MTK
IOMMU v10[2] and Robin's "Rationalise quirk handling"[3].

[1]: http://lists.linuxfoundation.org/pipermail/iommu/2016-January/015463.html
[2]: http://lists.linuxfoundation.org/pipermail/iommu/2016-February/015795.html
[3]: http://lists.linuxfoundation.org/pipermail/iommu/2016-February/015663.html

Yong Wu (2):
  iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor
  iommu/mediatek: Add 4GB mode support

 drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
 drivers/iommu/io-pgtable.h         |  6 ++++++
 drivers/iommu/mtk_iommu.c          | 14 +++++++++++---
 3 files changed, 30 insertions(+), 4 deletions(-)

-- 
1.8.1.1.dirty 

[PATCH 0/2] MT8173 IOMMU 4GB MODE SUPPORT

[Yong Wu]

  This patch-set add MTK 4GB mode support on the Short-Descriptor.
MTK extend the bit9 of the standard pgtable descriptor as the 4GB mode.
We add a special quirk for this.
  This two patches are based on Robin's Short-decriptor v3[1], MTK
IOMMU v10[2] and Robin's "Rationalise quirk handling"[3].

[1]: http://lists.linuxfoundation.org/pipermail/iommu/2016-January/015463.html
[2]: http://lists.linuxfoundation.org/pipermail/iommu/2016-February/015795.html
[3]: http://lists.linuxfoundation.org/pipermail/iommu/2016-February/015663.html

Yong Wu (2):
  iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor
  iommu/mediatek: Add 4GB mode support

 drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
 drivers/iommu/io-pgtable.h         |  6 ++++++
 drivers/iommu/mtk_iommu.c          | 14 +++++++++++---
 3 files changed, 30 insertions(+), 4 deletions(-)

-- 
1.8.1.1.dirty 

[PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Yong Wu]

Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
Short-descriptor as the 4GB mode in which the dram size will be
over 4GB.

We add a special quirk for this MTK-4GB mode, And in the standard
spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
expected.

Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
In arm_v7s_init_pte, We add bit9 if the 4GB mode is enabled no matter
the current pa is over 4GB or not.

 drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
 drivers/iommu/io-pgtable.h         |  6 ++++++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 9fcceb1..bf6a6f0 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -121,6 +121,8 @@
 #define ARM_V7S_TEX_MASK		0x7
 #define ARM_V7S_ATTR_TEX(val)		(((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
 
+#define ARM_V7S_ATTR_MTK_4GB		BIT(9) /* MTK extend it for 4GB mode */
+
 /* *well, except for TEX on level 2 large pages, of course :( */
 #define ARM_V7S_CONT_PAGE_TEX_SHIFT	6
 #define ARM_V7S_CONT_PAGE_TEX_MASK	(ARM_V7S_TEX_MASK << ARM_V7S_CONT_PAGE_TEX_SHIFT)
@@ -364,6 +366,9 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
 	if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
 		pte |= ARM_V7S_ATTR_NS_SECTION;
 
+	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT)
+		pte |= ARM_V7S_ATTR_MTK_4GB;
+
 	if (num_entries > 1)
 		pte = arm_v7s_pte_to_cont(pte, lvl);
 
@@ -625,9 +630,16 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
 
 	if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
 			    IO_PGTABLE_QUIRK_NO_PERMS |
-			    IO_PGTABLE_QUIRK_TLBI_ON_MAP))
+			    IO_PGTABLE_QUIRK_TLBI_ON_MAP |
+			    IO_PGTABLE_QUIRK_MTK_4GB_EXT))
 		return NULL;
 
+	/* If MTK_4GB_EXT is enabled, the NO_PERMS is also expected. */
+	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT) {
+		if (!(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS))
+			return NULL;
+	}
+
 	data = kmalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return NULL;
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index d4f5027..a84a60a 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -60,10 +60,16 @@ struct io_pgtable_cfg {
 	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
 	 *	(unmapped) entries but the hardware might do so anyway, perform
 	 *	TLB maintenance when mapping as well as when unmapping.
+	 *
+	 * IO_PGTABLE_QUIRK_MTK_4GB_EXT: Mediatek extend bit9 in the lvl1 and
+	 *	lvl2 descriptor of the Short-descriptor as the 4GB mode.
+	 *	Note that: Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while
+	 *	it is AP[2] in the lvl2.
 	 */
 	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
 	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
 	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
+	#define IO_PGTABLE_QUIRK_MTK_4GB_EXT	BIT(3)
 	unsigned long			quirks;
 	unsigned long			pgsize_bitmap;
 	unsigned int			ias;
-- 
1.8.1.1.dirty

[PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Yong Wu]

Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
Short-descriptor as the 4GB mode in which the dram size will be
over 4GB.

We add a special quirk for this MTK-4GB mode, And in the standard
spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
expected.

Signed-off-by: Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
In arm_v7s_init_pte, We add bit9 if the 4GB mode is enabled no matter
the current pa is over 4GB or not.

 drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
 drivers/iommu/io-pgtable.h         |  6 ++++++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 9fcceb1..bf6a6f0 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -121,6 +121,8 @@
 #define ARM_V7S_TEX_MASK		0x7
 #define ARM_V7S_ATTR_TEX(val)		(((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
 
+#define ARM_V7S_ATTR_MTK_4GB		BIT(9) /* MTK extend it for 4GB mode */
+
 /* *well, except for TEX on level 2 large pages, of course :( */
 #define ARM_V7S_CONT_PAGE_TEX_SHIFT	6
 #define ARM_V7S_CONT_PAGE_TEX_MASK	(ARM_V7S_TEX_MASK << ARM_V7S_CONT_PAGE_TEX_SHIFT)
@@ -364,6 +366,9 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
 	if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
 		pte |= ARM_V7S_ATTR_NS_SECTION;
 
+	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT)
+		pte |= ARM_V7S_ATTR_MTK_4GB;
+
 	if (num_entries > 1)
 		pte = arm_v7s_pte_to_cont(pte, lvl);
 
@@ -625,9 +630,16 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
 
 	if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
 			    IO_PGTABLE_QUIRK_NO_PERMS |
-			    IO_PGTABLE_QUIRK_TLBI_ON_MAP))
+			    IO_PGTABLE_QUIRK_TLBI_ON_MAP |
+			    IO_PGTABLE_QUIRK_MTK_4GB_EXT))
 		return NULL;
 
+	/* If MTK_4GB_EXT is enabled, the NO_PERMS is also expected. */
+	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT) {
+		if (!(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS))
+			return NULL;
+	}
+
 	data = kmalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return NULL;
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index d4f5027..a84a60a 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -60,10 +60,16 @@ struct io_pgtable_cfg {
 	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
 	 *	(unmapped) entries but the hardware might do so anyway, perform
 	 *	TLB maintenance when mapping as well as when unmapping.
+	 *
+	 * IO_PGTABLE_QUIRK_MTK_4GB_EXT: Mediatek extend bit9 in the lvl1 and
+	 *	lvl2 descriptor of the Short-descriptor as the 4GB mode.
+	 *	Note that: Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while
+	 *	it is AP[2] in the lvl2.
 	 */
 	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
 	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
 	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
+	#define IO_PGTABLE_QUIRK_MTK_4GB_EXT	BIT(3)
 	unsigned long			quirks;
 	unsigned long			pgsize_bitmap;
 	unsigned int			ias;
-- 
1.8.1.1.dirty

[PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Yong Wu]

Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
Short-descriptor as the 4GB mode in which the dram size will be
over 4GB.

We add a special quirk for this MTK-4GB mode, And in the standard
spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
expected.

Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
In arm_v7s_init_pte, We add bit9 if the 4GB mode is enabled no matter
the current pa is over 4GB or not.

 drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
 drivers/iommu/io-pgtable.h         |  6 ++++++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 9fcceb1..bf6a6f0 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -121,6 +121,8 @@
 #define ARM_V7S_TEX_MASK		0x7
 #define ARM_V7S_ATTR_TEX(val)		(((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
 
+#define ARM_V7S_ATTR_MTK_4GB		BIT(9) /* MTK extend it for 4GB mode */
+
 /* *well, except for TEX on level 2 large pages, of course :( */
 #define ARM_V7S_CONT_PAGE_TEX_SHIFT	6
 #define ARM_V7S_CONT_PAGE_TEX_MASK	(ARM_V7S_TEX_MASK << ARM_V7S_CONT_PAGE_TEX_SHIFT)
@@ -364,6 +366,9 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
 	if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
 		pte |= ARM_V7S_ATTR_NS_SECTION;
 
+	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT)
+		pte |= ARM_V7S_ATTR_MTK_4GB;
+
 	if (num_entries > 1)
 		pte = arm_v7s_pte_to_cont(pte, lvl);
 
@@ -625,9 +630,16 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
 
 	if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
 			    IO_PGTABLE_QUIRK_NO_PERMS |
-			    IO_PGTABLE_QUIRK_TLBI_ON_MAP))
+			    IO_PGTABLE_QUIRK_TLBI_ON_MAP |
+			    IO_PGTABLE_QUIRK_MTK_4GB_EXT))
 		return NULL;
 
+	/* If MTK_4GB_EXT is enabled, the NO_PERMS is also expected. */
+	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT) {
+		if (!(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS))
+			return NULL;
+	}
+
 	data = kmalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return NULL;
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index d4f5027..a84a60a 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -60,10 +60,16 @@ struct io_pgtable_cfg {
 	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
 	 *	(unmapped) entries but the hardware might do so anyway, perform
 	 *	TLB maintenance when mapping as well as when unmapping.
+	 *
+	 * IO_PGTABLE_QUIRK_MTK_4GB_EXT: Mediatek extend bit9 in the lvl1 and
+	 *	lvl2 descriptor of the Short-descriptor as the 4GB mode.
+	 *	Note that: Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while
+	 *	it is AP[2] in the lvl2.
 	 */
 	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
 	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
 	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
+	#define IO_PGTABLE_QUIRK_MTK_4GB_EXT	BIT(3)
 	unsigned long			quirks;
 	unsigned long			pgsize_bitmap;
 	unsigned int			ias;
-- 
1.8.1.1.dirty

[PATCH 2/2] iommu/mediatek: Add 4GB mode support

[Yong Wu]

This patch add 4GB mode support for m4u.

Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
In this patch I use the global "max_pfn" to check whether the current
dram size is over 4GB, I am not sure this is proper.

If there is any other suggestions, please let me know.
Thanks.

 drivers/iommu/mtk_iommu.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 721ffdb..5b1ddb5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -11,6 +11,7 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
+#include <linux/bootmem.h>
 #include <linux/bug.h>
 #include <linux/clk.h>
 #include <linux/component.h>
@@ -56,7 +57,7 @@
 #define F_MMU_TF_PROTECT_SEL(prot)		(((prot) & 0x3) << 5)
 
 #define REG_MMU_IVRP_PADDR			0x114
-#define F_MMU_IVRP_PA_SET(pa)			((pa) >> 1)
+#define F_MMU_IVRP_PA_SET(pa, ext)		(((pa) >> 1) | ((!!(ext)) << 31))
 
 #define REG_MMU_INT_CONTROL0			0x120
 #define F_L2_MULIT_HIT_EN			BIT(0)
@@ -125,6 +126,7 @@ struct mtk_iommu_data {
 	struct mtk_iommu_domain		*m4u_dom;
 	struct iommu_group		*m4u_group;
 	struct mtk_smi_iommu		smi_imu;      /* SMI larb iommu info */
+	bool                            enable_4GB;
 };
 
 static struct iommu_ops mtk_iommu_ops;
@@ -257,6 +259,9 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_data *data)
 		.iommu_dev = data->dev,
 	};
 
+	if (data->enable_4GB)
+		dom->cfg.quirks |= IO_PGTABLE_QUIRK_MTK_4GB_EXT;
+
 	dom->iop = alloc_io_pgtable_ops(ARM_V7S, &dom->cfg, data);
 	if (!dom->iop) {
 		dev_err(data->dev, "Failed to alloc io pgtable\n");
@@ -530,7 +535,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
 		F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
 	writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
 
-	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
 		       data->base + REG_MMU_IVRP_PADDR);
 
 	writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
@@ -592,6 +597,9 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
 
+	/* Whether the current dram size is over 4GB */
+	data->enable_4GB = !!(max_pfn > (0xffffffffUL >> PAGE_SHIFT));
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	data->base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(data->base))
@@ -691,7 +699,7 @@ static int mtk_iommu_resume(struct device *dev)
 	writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
 	writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
 	writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
-	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
 		       base + REG_MMU_IVRP_PADDR);
 	return 0;
 }
-- 
1.8.1.1.dirty

[PATCH 2/2] iommu/mediatek: Add 4GB mode support

[Yong Wu]

This patch add 4GB mode support for m4u.

Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
In this patch I use the global "max_pfn" to check whether the current
dram size is over 4GB, I am not sure this is proper.

If there is any other suggestions, please let me know.
Thanks.

 drivers/iommu/mtk_iommu.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 721ffdb..5b1ddb5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -11,6 +11,7 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
+#include <linux/bootmem.h>
 #include <linux/bug.h>
 #include <linux/clk.h>
 #include <linux/component.h>
@@ -56,7 +57,7 @@
 #define F_MMU_TF_PROTECT_SEL(prot)		(((prot) & 0x3) << 5)
 
 #define REG_MMU_IVRP_PADDR			0x114
-#define F_MMU_IVRP_PA_SET(pa)			((pa) >> 1)
+#define F_MMU_IVRP_PA_SET(pa, ext)		(((pa) >> 1) | ((!!(ext)) << 31))
 
 #define REG_MMU_INT_CONTROL0			0x120
 #define F_L2_MULIT_HIT_EN			BIT(0)
@@ -125,6 +126,7 @@ struct mtk_iommu_data {
 	struct mtk_iommu_domain		*m4u_dom;
 	struct iommu_group		*m4u_group;
 	struct mtk_smi_iommu		smi_imu;      /* SMI larb iommu info */
+	bool                            enable_4GB;
 };
 
 static struct iommu_ops mtk_iommu_ops;
@@ -257,6 +259,9 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_data *data)
 		.iommu_dev = data->dev,
 	};
 
+	if (data->enable_4GB)
+		dom->cfg.quirks |= IO_PGTABLE_QUIRK_MTK_4GB_EXT;
+
 	dom->iop = alloc_io_pgtable_ops(ARM_V7S, &dom->cfg, data);
 	if (!dom->iop) {
 		dev_err(data->dev, "Failed to alloc io pgtable\n");
@@ -530,7 +535,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
 		F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
 	writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
 
-	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
 		       data->base + REG_MMU_IVRP_PADDR);
 
 	writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
@@ -592,6 +597,9 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
 
+	/* Whether the current dram size is over 4GB */
+	data->enable_4GB = !!(max_pfn > (0xffffffffUL >> PAGE_SHIFT));
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	data->base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(data->base))
@@ -691,7 +699,7 @@ static int mtk_iommu_resume(struct device *dev)
 	writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
 	writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
 	writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
-	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
 		       base + REG_MMU_IVRP_PADDR);
 	return 0;
 }
-- 
1.8.1.1.dirty

[PATCH 2/2] iommu/mediatek: Add 4GB mode support

[Yong Wu]

This patch add 4GB mode support for m4u.

Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
In this patch I use the global "max_pfn" to check whether the current
dram size is over 4GB, I am not sure this is proper.

If there is any other suggestions, please let me know.
Thanks.

 drivers/iommu/mtk_iommu.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 721ffdb..5b1ddb5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -11,6 +11,7 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
+#include <linux/bootmem.h>
 #include <linux/bug.h>
 #include <linux/clk.h>
 #include <linux/component.h>
@@ -56,7 +57,7 @@
 #define F_MMU_TF_PROTECT_SEL(prot)		(((prot) & 0x3) << 5)
 
 #define REG_MMU_IVRP_PADDR			0x114
-#define F_MMU_IVRP_PA_SET(pa)			((pa) >> 1)
+#define F_MMU_IVRP_PA_SET(pa, ext)		(((pa) >> 1) | ((!!(ext)) << 31))
 
 #define REG_MMU_INT_CONTROL0			0x120
 #define F_L2_MULIT_HIT_EN			BIT(0)
@@ -125,6 +126,7 @@ struct mtk_iommu_data {
 	struct mtk_iommu_domain		*m4u_dom;
 	struct iommu_group		*m4u_group;
 	struct mtk_smi_iommu		smi_imu;      /* SMI larb iommu info */
+	bool                            enable_4GB;
 };
 
 static struct iommu_ops mtk_iommu_ops;
@@ -257,6 +259,9 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_data *data)
 		.iommu_dev = data->dev,
 	};
 
+	if (data->enable_4GB)
+		dom->cfg.quirks |= IO_PGTABLE_QUIRK_MTK_4GB_EXT;
+
 	dom->iop = alloc_io_pgtable_ops(ARM_V7S, &dom->cfg, data);
 	if (!dom->iop) {
 		dev_err(data->dev, "Failed to alloc io pgtable\n");
@@ -530,7 +535,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
 		F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
 	writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
 
-	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
 		       data->base + REG_MMU_IVRP_PADDR);
 
 	writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
@@ -592,6 +597,9 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
 
+	/* Whether the current dram size is over 4GB */
+	data->enable_4GB = !!(max_pfn > (0xffffffffUL >> PAGE_SHIFT));
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	data->base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(data->base))
@@ -691,7 +699,7 @@ static int mtk_iommu_resume(struct device *dev)
 	writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
 	writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
 	writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
-	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
 		       base + REG_MMU_IVRP_PADDR);
 	return 0;
 }
-- 
1.8.1.1.dirty

Re: [PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Robin Murphy]

Hi Yong,

On 23/02/16 23:02, Yong Wu wrote:
> Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
> Short-descriptor as the 4GB mode in which the dram size will be
> over 4GB.
>
> We add a special quirk for this MTK-4GB mode, And in the standard
> spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
> in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
> expected.

Would you be able to explain exactly what this "4GB mode" actually is? 
I've been trying to make sense of it from the original M4U patches and 
the patch for the I2C driver, but it has me completely baffled.

Is it simply used as an extra physical address bit (although surely that 
would make it "8GB mode"?), or does it do something crazier like 
toggling an interconnect remap that shifts the output addresses up by 
1GB to be relative to the base of DRAM, like a dma_pfn_offset?

I guess from the look of these patches that it doesn't change anything 
between the masters and the M4U, so input addresses are still 32 bits 
and we don't need extended tables, right? Furthermore, what about the 
TTBRs? Does the level 1 table still have to be below 4GB?

> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> In arm_v7s_init_pte, We add bit9 if the 4GB mode is enabled no matter
> the current pa is over 4GB or not.

Either way I can't comprehend how it could be fine to just enable 
unconditionally without doing _something_ with the actual addresses.

>   drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
>   drivers/iommu/io-pgtable.h         |  6 ++++++
>   2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> index 9fcceb1..bf6a6f0 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -121,6 +121,8 @@
>   #define ARM_V7S_TEX_MASK		0x7
>   #define ARM_V7S_ATTR_TEX(val)		(((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
>
> +#define ARM_V7S_ATTR_MTK_4GB		BIT(9) /* MTK extend it for 4GB mode */
> +
>   /* *well, except for TEX on level 2 large pages, of course :( */
>   #define ARM_V7S_CONT_PAGE_TEX_SHIFT	6
>   #define ARM_V7S_CONT_PAGE_TEX_MASK	(ARM_V7S_TEX_MASK << ARM_V7S_CONT_PAGE_TEX_SHIFT)
> @@ -364,6 +366,9 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
>   	if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
>   		pte |= ARM_V7S_ATTR_NS_SECTION;
>
> +	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT)
> +		pte |= ARM_V7S_ATTR_MTK_4GB;
> +
>   	if (num_entries > 1)
>   		pte = arm_v7s_pte_to_cont(pte, lvl);
>
> @@ -625,9 +630,16 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
>
>   	if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
>   			    IO_PGTABLE_QUIRK_NO_PERMS |
> -			    IO_PGTABLE_QUIRK_TLBI_ON_MAP))
> +			    IO_PGTABLE_QUIRK_TLBI_ON_MAP |
> +			    IO_PGTABLE_QUIRK_MTK_4GB_EXT))
>   		return NULL;
>
> +	/* If MTK_4GB_EXT is enabled, the NO_PERMS is also expected. */
> +	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT) {
> +		if (!(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS))

Ha, I wasn't expecting to see Will's argument against generic 
quirk-checking be vindicated quite so soon :)

Anyway, no need for braces and nested ifs:

	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT &&
	    !(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS))

> +			return NULL;
> +	}
> +
>   	data = kmalloc(sizeof(*data), GFP_KERNEL);
>   	if (!data)
>   		return NULL;
> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
> index d4f5027..a84a60a 100644
> --- a/drivers/iommu/io-pgtable.h
> +++ b/drivers/iommu/io-pgtable.h
> @@ -60,10 +60,16 @@ struct io_pgtable_cfg {
>   	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
>   	 *	(unmapped) entries but the hardware might do so anyway, perform
>   	 *	TLB maintenance when mapping as well as when unmapping.
> +	 *
> +	 * IO_PGTABLE_QUIRK_MTK_4GB_EXT: Mediatek extend bit9 in the lvl1 and
> +	 *	lvl2 descriptor of the Short-descriptor as the 4GB mode.
> +	 *	Note that: Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while
> +	 *	it is AP[2] in the lvl2.

Unfortunately that comment doesn't really explain anything - I'd be 
happy to suggest a more helpful wording, If only I understood what it 
actually did.

Robin.

>   	 */
>   	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
>   	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
>   	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
> +	#define IO_PGTABLE_QUIRK_MTK_4GB_EXT	BIT(3)
>   	unsigned long			quirks;
>   	unsigned long			pgsize_bitmap;
>   	unsigned int			ias;
>

Re: [PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Robin Murphy]

Hi Yong,

On 23/02/16 23:02, Yong Wu wrote:
> Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
> Short-descriptor as the 4GB mode in which the dram size will be
> over 4GB.
>
> We add a special quirk for this MTK-4GB mode, And in the standard
> spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
> in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
> expected.

Would you be able to explain exactly what this "4GB mode" actually is? 
I've been trying to make sense of it from the original M4U patches and 
the patch for the I2C driver, but it has me completely baffled.

Is it simply used as an extra physical address bit (although surely that 
would make it "8GB mode"?), or does it do something crazier like 
toggling an interconnect remap that shifts the output addresses up by 
1GB to be relative to the base of DRAM, like a dma_pfn_offset?

I guess from the look of these patches that it doesn't change anything 
between the masters and the M4U, so input addresses are still 32 bits 
and we don't need extended tables, right? Furthermore, what about the 
TTBRs? Does the level 1 table still have to be below 4GB?

> Signed-off-by: Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> In arm_v7s_init_pte, We add bit9 if the 4GB mode is enabled no matter
> the current pa is over 4GB or not.

Either way I can't comprehend how it could be fine to just enable 
unconditionally without doing _something_ with the actual addresses.

>   drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
>   drivers/iommu/io-pgtable.h         |  6 ++++++
>   2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> index 9fcceb1..bf6a6f0 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -121,6 +121,8 @@
>   #define ARM_V7S_TEX_MASK		0x7
>   #define ARM_V7S_ATTR_TEX(val)		(((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
>
> +#define ARM_V7S_ATTR_MTK_4GB		BIT(9) /* MTK extend it for 4GB mode */
> +
>   /* *well, except for TEX on level 2 large pages, of course :( */
>   #define ARM_V7S_CONT_PAGE_TEX_SHIFT	6
>   #define ARM_V7S_CONT_PAGE_TEX_MASK	(ARM_V7S_TEX_MASK << ARM_V7S_CONT_PAGE_TEX_SHIFT)
> @@ -364,6 +366,9 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
>   	if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
>   		pte |= ARM_V7S_ATTR_NS_SECTION;
>
> +	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT)
> +		pte |= ARM_V7S_ATTR_MTK_4GB;
> +
>   	if (num_entries > 1)
>   		pte = arm_v7s_pte_to_cont(pte, lvl);
>
> @@ -625,9 +630,16 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
>
>   	if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
>   			    IO_PGTABLE_QUIRK_NO_PERMS |
> -			    IO_PGTABLE_QUIRK_TLBI_ON_MAP))
> +			    IO_PGTABLE_QUIRK_TLBI_ON_MAP |
> +			    IO_PGTABLE_QUIRK_MTK_4GB_EXT))
>   		return NULL;
>
> +	/* If MTK_4GB_EXT is enabled, the NO_PERMS is also expected. */
> +	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT) {
> +		if (!(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS))

Ha, I wasn't expecting to see Will's argument against generic 
quirk-checking be vindicated quite so soon :)

Anyway, no need for braces and nested ifs:

	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT &&
	    !(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS))

> +			return NULL;
> +	}
> +
>   	data = kmalloc(sizeof(*data), GFP_KERNEL);
>   	if (!data)
>   		return NULL;
> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
> index d4f5027..a84a60a 100644
> --- a/drivers/iommu/io-pgtable.h
> +++ b/drivers/iommu/io-pgtable.h
> @@ -60,10 +60,16 @@ struct io_pgtable_cfg {
>   	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
>   	 *	(unmapped) entries but the hardware might do so anyway, perform
>   	 *	TLB maintenance when mapping as well as when unmapping.
> +	 *
> +	 * IO_PGTABLE_QUIRK_MTK_4GB_EXT: Mediatek extend bit9 in the lvl1 and
> +	 *	lvl2 descriptor of the Short-descriptor as the 4GB mode.
> +	 *	Note that: Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while
> +	 *	it is AP[2] in the lvl2.

Unfortunately that comment doesn't really explain anything - I'd be 
happy to suggest a more helpful wording, If only I understood what it 
actually did.

Robin.

>   	 */
>   	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
>   	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
>   	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
> +	#define IO_PGTABLE_QUIRK_MTK_4GB_EXT	BIT(3)
>   	unsigned long			quirks;
>   	unsigned long			pgsize_bitmap;
>   	unsigned int			ias;
>

[PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Robin Murphy]

Hi Yong,

On 23/02/16 23:02, Yong Wu wrote:
> Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
> Short-descriptor as the 4GB mode in which the dram size will be
> over 4GB.
>
> We add a special quirk for this MTK-4GB mode, And in the standard
> spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
> in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
> expected.

Would you be able to explain exactly what this "4GB mode" actually is? 
I've been trying to make sense of it from the original M4U patches and 
the patch for the I2C driver, but it has me completely baffled.

Is it simply used as an extra physical address bit (although surely that 
would make it "8GB mode"?), or does it do something crazier like 
toggling an interconnect remap that shifts the output addresses up by 
1GB to be relative to the base of DRAM, like a dma_pfn_offset?

I guess from the look of these patches that it doesn't change anything 
between the masters and the M4U, so input addresses are still 32 bits 
and we don't need extended tables, right? Furthermore, what about the 
TTBRs? Does the level 1 table still have to be below 4GB?

> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> In arm_v7s_init_pte, We add bit9 if the 4GB mode is enabled no matter
> the current pa is over 4GB or not.

Either way I can't comprehend how it could be fine to just enable 
unconditionally without doing _something_ with the actual addresses.

>   drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
>   drivers/iommu/io-pgtable.h         |  6 ++++++
>   2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> index 9fcceb1..bf6a6f0 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -121,6 +121,8 @@
>   #define ARM_V7S_TEX_MASK		0x7
>   #define ARM_V7S_ATTR_TEX(val)		(((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
>
> +#define ARM_V7S_ATTR_MTK_4GB		BIT(9) /* MTK extend it for 4GB mode */
> +
>   /* *well, except for TEX on level 2 large pages, of course :( */
>   #define ARM_V7S_CONT_PAGE_TEX_SHIFT	6
>   #define ARM_V7S_CONT_PAGE_TEX_MASK	(ARM_V7S_TEX_MASK << ARM_V7S_CONT_PAGE_TEX_SHIFT)
> @@ -364,6 +366,9 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
>   	if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
>   		pte |= ARM_V7S_ATTR_NS_SECTION;
>
> +	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT)
> +		pte |= ARM_V7S_ATTR_MTK_4GB;
> +
>   	if (num_entries > 1)
>   		pte = arm_v7s_pte_to_cont(pte, lvl);
>
> @@ -625,9 +630,16 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
>
>   	if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
>   			    IO_PGTABLE_QUIRK_NO_PERMS |
> -			    IO_PGTABLE_QUIRK_TLBI_ON_MAP))
> +			    IO_PGTABLE_QUIRK_TLBI_ON_MAP |
> +			    IO_PGTABLE_QUIRK_MTK_4GB_EXT))
>   		return NULL;
>
> +	/* If MTK_4GB_EXT is enabled, the NO_PERMS is also expected. */
> +	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT) {
> +		if (!(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS))

Ha, I wasn't expecting to see Will's argument against generic 
quirk-checking be vindicated quite so soon :)

Anyway, no need for braces and nested ifs:

	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT &&
	    !(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS))

> +			return NULL;
> +	}
> +
>   	data = kmalloc(sizeof(*data), GFP_KERNEL);
>   	if (!data)
>   		return NULL;
> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
> index d4f5027..a84a60a 100644
> --- a/drivers/iommu/io-pgtable.h
> +++ b/drivers/iommu/io-pgtable.h
> @@ -60,10 +60,16 @@ struct io_pgtable_cfg {
>   	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
>   	 *	(unmapped) entries but the hardware might do so anyway, perform
>   	 *	TLB maintenance when mapping as well as when unmapping.
> +	 *
> +	 * IO_PGTABLE_QUIRK_MTK_4GB_EXT: Mediatek extend bit9 in the lvl1 and
> +	 *	lvl2 descriptor of the Short-descriptor as the 4GB mode.
> +	 *	Note that: Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while
> +	 *	it is AP[2] in the lvl2.

Unfortunately that comment doesn't really explain anything - I'd be 
happy to suggest a more helpful wording, If only I understood what it 
actually did.

Robin.

>   	 */
>   	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
>   	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
>   	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
> +	#define IO_PGTABLE_QUIRK_MTK_4GB_EXT	BIT(3)
>   	unsigned long			quirks;
>   	unsigned long			pgsize_bitmap;
>   	unsigned int			ias;
>

Re: [PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Yingjoe Chen]

On Wed, 2016-03-02 at 12:31 +0000, Robin Murphy wrote:
> Hi Yong,
> 
> On 23/02/16 23:02, Yong Wu wrote:
> > Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
> > Short-descriptor as the 4GB mode in which the dram size will be
> > over 4GB.
> >
> > We add a special quirk for this MTK-4GB mode, And in the standard
> > spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
> > in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
> > expected.
> 
> Would you be able to explain exactly what this "4GB mode" actually is? 
> I've been trying to make sense of it from the original M4U patches and 
> the patch for the I2C driver, but it has me completely baffled.
> 
> Is it simply used as an extra physical address bit (although surely that 
> would make it "8GB mode"?), or does it do something crazier like 
> toggling an interconnect remap that shifts the output addresses up by 
> 1GB to be relative to the base of DRAM, like a dma_pfn_offset?

Unfortunately, it is somewhat more crazier than that. Let me have a
short brief on what we got.

Normally, mt8173 memory map looks like this:

Physical addr
---------
| 1st GB |    ->  HW SRAM and Regs
|--------
| 2nd GB |    ->  DRAM 1st GB
|--------
| 3rd GB |    ->  DRAM 2nd GB
|--------
| 4th GB |    ->  DRAM 3rd GB
|--------

On mt8173, we have a "DRAM 4GB mode" toggle bit. If it is enabled, from
CPU's point of view, the dram will be shifted to start from PA
0x1_00000000. The PA 0x40000000~0xffffffff will become an alias to
0x1_40000000~0x1_ffffffff.

Many HW only support 32bits physical address, the 33bit will be added to
PA when 4GB mode is enabled. This looks like dma_pfn_offset you
mentioned.

Some others, like i2c or audio, support 33bits physical address, mostly
because they support DMA to/from SRAM with the same SW interface. When
4GB mode is enabled, these HW can still access DRAM with aliased dram
address (0x40000000 ~ 0xffffffff)

The MTK M4U(iommu) is another case. It did add 33 bits to page table
entries and registers. Unfortunately, when 4GB mode is enabled, 33bit
must be 1. It treats all PA < 0x1_0000_0000 as invalid address. That's
why we always set the 33bit when 4GB mode is enabled in this patch.

And there are other HWs with even crazier remap rule, but that's another
story...

Joe.C

Re: [PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Yingjoe Chen]

On Wed, 2016-03-02 at 12:31 +0000, Robin Murphy wrote:
> Hi Yong,
> 
> On 23/02/16 23:02, Yong Wu wrote:
> > Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
> > Short-descriptor as the 4GB mode in which the dram size will be
> > over 4GB.
> >
> > We add a special quirk for this MTK-4GB mode, And in the standard
> > spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
> > in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
> > expected.
> 
> Would you be able to explain exactly what this "4GB mode" actually is? 
> I've been trying to make sense of it from the original M4U patches and 
> the patch for the I2C driver, but it has me completely baffled.
> 
> Is it simply used as an extra physical address bit (although surely that 
> would make it "8GB mode"?), or does it do something crazier like 
> toggling an interconnect remap that shifts the output addresses up by 
> 1GB to be relative to the base of DRAM, like a dma_pfn_offset?

Unfortunately, it is somewhat more crazier than that. Let me have a
short brief on what we got.

Normally, mt8173 memory map looks like this:

Physical addr
---------
| 1st GB |    ->  HW SRAM and Regs
|--------
| 2nd GB |    ->  DRAM 1st GB
|--------
| 3rd GB |    ->  DRAM 2nd GB
|--------
| 4th GB |    ->  DRAM 3rd GB
|--------

On mt8173, we have a "DRAM 4GB mode" toggle bit. If it is enabled, from
CPU's point of view, the dram will be shifted to start from PA
0x1_00000000. The PA 0x40000000~0xffffffff will become an alias to
0x1_40000000~0x1_ffffffff.

Many HW only support 32bits physical address, the 33bit will be added to
PA when 4GB mode is enabled. This looks like dma_pfn_offset you
mentioned.

Some others, like i2c or audio, support 33bits physical address, mostly
because they support DMA to/from SRAM with the same SW interface. When
4GB mode is enabled, these HW can still access DRAM with aliased dram
address (0x40000000 ~ 0xffffffff)

The MTK M4U(iommu) is another case. It did add 33 bits to page table
entries and registers. Unfortunately, when 4GB mode is enabled, 33bit
must be 1. It treats all PA < 0x1_0000_0000 as invalid address. That's
why we always set the 33bit when 4GB mode is enabled in this patch.

And there are other HWs with even crazier remap rule, but that's another
story...

Joe.C

[PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Yingjoe Chen]

On Wed, 2016-03-02 at 12:31 +0000, Robin Murphy wrote:
> Hi Yong,
> 
> On 23/02/16 23:02, Yong Wu wrote:
> > Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
> > Short-descriptor as the 4GB mode in which the dram size will be
> > over 4GB.
> >
> > We add a special quirk for this MTK-4GB mode, And in the standard
> > spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
> > in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
> > expected.
> 
> Would you be able to explain exactly what this "4GB mode" actually is? 
> I've been trying to make sense of it from the original M4U patches and 
> the patch for the I2C driver, but it has me completely baffled.
> 
> Is it simply used as an extra physical address bit (although surely that 
> would make it "8GB mode"?), or does it do something crazier like 
> toggling an interconnect remap that shifts the output addresses up by 
> 1GB to be relative to the base of DRAM, like a dma_pfn_offset?

Unfortunately, it is somewhat more crazier than that. Let me have a
short brief on what we got.

Normally, mt8173 memory map looks like this:

Physical addr
---------
| 1st GB |    ->  HW SRAM and Regs
|--------
| 2nd GB |    ->  DRAM 1st GB
|--------
| 3rd GB |    ->  DRAM 2nd GB
|--------
| 4th GB |    ->  DRAM 3rd GB
|--------

On mt8173, we have a "DRAM 4GB mode" toggle bit. If it is enabled, from
CPU's point of view, the dram will be shifted to start from PA
0x1_00000000. The PA 0x40000000~0xffffffff will become an alias to
0x1_40000000~0x1_ffffffff.

Many HW only support 32bits physical address, the 33bit will be added to
PA when 4GB mode is enabled. This looks like dma_pfn_offset you
mentioned.

Some others, like i2c or audio, support 33bits physical address, mostly
because they support DMA to/from SRAM with the same SW interface. When
4GB mode is enabled, these HW can still access DRAM with aliased dram
address (0x40000000 ~ 0xffffffff)

The MTK M4U(iommu) is another case. It did add 33 bits to page table
entries and registers. Unfortunately, when 4GB mode is enabled, 33bit
must be 1. It treats all PA < 0x1_0000_0000 as invalid address. That's
why we always set the 33bit when 4GB mode is enabled in this patch.

And there are other HWs with even crazier remap rule, but that's another
story...

Joe.C

Re: [PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Robin Murphy]

On 02/03/16 12:31, Robin Murphy wrote:
> Hi Yong,
>
> On 23/02/16 23:02, Yong Wu wrote:
>> Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
>> Short-descriptor as the 4GB mode in which the dram size will be
>> over 4GB.
>>
>> We add a special quirk for this MTK-4GB mode, And in the standard
>> spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
>> in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
>> expected.
>
> Would you be able to explain exactly what this "4GB mode" actually is?
> I've been trying to make sense of it from the original M4U patches and
> the patch for the I2C driver, but it has me completely baffled.

Many thanks to Joe for the explanation!

[...]
>> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
>> index d4f5027..a84a60a 100644
>> --- a/drivers/iommu/io-pgtable.h
>> +++ b/drivers/iommu/io-pgtable.h
>> @@ -60,10 +60,16 @@ struct io_pgtable_cfg {
>>        * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching
>> invalid
>>        *    (unmapped) entries but the hardware might do so anyway,
>> perform
>>        *    TLB maintenance when mapping as well as when unmapping.
>> +     *
>> +     * IO_PGTABLE_QUIRK_MTK_4GB_EXT: Mediatek extend bit9 in the lvl1
>> and
>> +     *    lvl2 descriptor of the Short-descriptor as the 4GB mode.
>> +     *    Note that: Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while
>> +     *    it is AP[2] in the lvl2.
>
> Unfortunately that comment doesn't really explain anything - I'd be
> happy to suggest a more helpful wording, If only I understood what it
> actually did.

OK, now that I think I've got it, how about this?

    IO_PGTABLE_QUIRK_ARM_MTK_4GB: (ARM v7s format) Set bit 9 in all
	PTEs, for Mediatek IOMMUs which treat it as a 33rd address bit
	when the SoC is in "4GB mode" and they can only access the high
	remap of DRAM (0x1_00000000 to 0x1_ffffffff).

Robin.

Re: [PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Robin Murphy]

On 02/03/16 12:31, Robin Murphy wrote:
> Hi Yong,
>
> On 23/02/16 23:02, Yong Wu wrote:
>> Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
>> Short-descriptor as the 4GB mode in which the dram size will be
>> over 4GB.
>>
>> We add a special quirk for this MTK-4GB mode, And in the standard
>> spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
>> in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
>> expected.
>
> Would you be able to explain exactly what this "4GB mode" actually is?
> I've been trying to make sense of it from the original M4U patches and
> the patch for the I2C driver, but it has me completely baffled.

Many thanks to Joe for the explanation!

[...]
>> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
>> index d4f5027..a84a60a 100644
>> --- a/drivers/iommu/io-pgtable.h
>> +++ b/drivers/iommu/io-pgtable.h
>> @@ -60,10 +60,16 @@ struct io_pgtable_cfg {
>>        * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching
>> invalid
>>        *    (unmapped) entries but the hardware might do so anyway,
>> perform
>>        *    TLB maintenance when mapping as well as when unmapping.
>> +     *
>> +     * IO_PGTABLE_QUIRK_MTK_4GB_EXT: Mediatek extend bit9 in the lvl1
>> and
>> +     *    lvl2 descriptor of the Short-descriptor as the 4GB mode.
>> +     *    Note that: Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while
>> +     *    it is AP[2] in the lvl2.
>
> Unfortunately that comment doesn't really explain anything - I'd be
> happy to suggest a more helpful wording, If only I understood what it
> actually did.

OK, now that I think I've got it, how about this?

    IO_PGTABLE_QUIRK_ARM_MTK_4GB: (ARM v7s format) Set bit 9 in all
	PTEs, for Mediatek IOMMUs which treat it as a 33rd address bit
	when the SoC is in "4GB mode" and they can only access the high
	remap of DRAM (0x1_00000000 to 0x1_ffffffff).

Robin.

[PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor

[Robin Murphy]

On 02/03/16 12:31, Robin Murphy wrote:
> Hi Yong,
>
> On 23/02/16 23:02, Yong Wu wrote:
>> Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
>> Short-descriptor as the 4GB mode in which the dram size will be
>> over 4GB.
>>
>> We add a special quirk for this MTK-4GB mode, And in the standard
>> spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
>> in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
>> expected.
>
> Would you be able to explain exactly what this "4GB mode" actually is?
> I've been trying to make sense of it from the original M4U patches and
> the patch for the I2C driver, but it has me completely baffled.

Many thanks to Joe for the explanation!

[...]
>> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
>> index d4f5027..a84a60a 100644
>> --- a/drivers/iommu/io-pgtable.h
>> +++ b/drivers/iommu/io-pgtable.h
>> @@ -60,10 +60,16 @@ struct io_pgtable_cfg {
>>        * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching
>> invalid
>>        *    (unmapped) entries but the hardware might do so anyway,
>> perform
>>        *    TLB maintenance when mapping as well as when unmapping.
>> +     *
>> +     * IO_PGTABLE_QUIRK_MTK_4GB_EXT: Mediatek extend bit9 in the lvl1
>> and
>> +     *    lvl2 descriptor of the Short-descriptor as the 4GB mode.
>> +     *    Note that: Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while
>> +     *    it is AP[2] in the lvl2.
>
> Unfortunately that comment doesn't really explain anything - I'd be
> happy to suggest a more helpful wording, If only I understood what it
> actually did.

OK, now that I think I've got it, how about this?

    IO_PGTABLE_QUIRK_ARM_MTK_4GB: (ARM v7s format) Set bit 9 in all
	PTEs, for Mediatek IOMMUs which treat it as a 33rd address bit
	when the SoC is in "4GB mode" and they can only access the high
	remap of DRAM (0x1_00000000 to 0x1_ffffffff).

Robin.