All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yong Wu <yong.wu@mediatek.com>
To: Joerg Roedel <joro@8bytes.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>,
	Evan Green <evgreen@chromium.org>, Tomasz Figa <tfiga@google.com>,
	<linux-mediatek@lists.infradead.org>,
	<srv_heupstream@mediatek.com>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<iommu@lists.linux-foundation.org>, <yong.wu@mediatek.com>,
	<youlin.pei@mediatek.com>,
	Nicolas Boichat <drinkcat@chromium.org>, <anan.sun@mediatek.com>,
	Matthias Kaehlcke <mka@chromium.org>, <cui.zhang@mediatek.com>,
	<chao.hao@mediatek.com>, <ming-fan.chen@mediatek.com>
Subject: [PATCH v11 05/23] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
Date: Sat, 24 Aug 2019 11:01:50 +0800	[thread overview]
Message-ID: <1566615728-26388-6-git-send-email-yong.wu@mediatek.com> (raw)
In-Reply-To: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>

In M4U 4GB mode, the physical address is remapped as below:

CPU Physical address:

====================

0      1G       2G     3G       4G     5G
|---A---|---B---|---C---|---D---|---E---|
+--I/O--+------------Memory-------------+

IOMMU output physical address:
 =============================

                                4G      5G     6G      7G      8G
                                |---E---|---B---|---C---|---D---|
                                +------------Memory-------------+

The Region 'A'(I/O) can not be mapped by M4U; For Region 'B'/'C'/'D', the
bit32 of the CPU physical address always is needed to set, and for Region
'E', the CPU physical address keep as is. something looks like this:
CPU PA         ->    M4U OUTPUT PA
0x4000_0000          0x1_4000_0000 (Add bit32)
0x8000_0000          0x1_8000_0000 ...
0xc000_0000          0x1_c000_0000 ...
0x1_0000_0000        0x1_0000_0000 (No change)

Additionally, the iommu consumers always use the CPU phyiscal address.

The PA in the iova_to_phys that is got from v7s always is u32, But
from the CPU point of view, PA only need add BIT(32) when PA < 0x4000_0000.

Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
 drivers/iommu/mtk_iommu.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c6e6dc3..9ba2706 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -107,6 +107,30 @@ struct mtk_iommu_domain {
 
 static const struct iommu_ops mtk_iommu_ops;
 
+/*
+ * In M4U 4GB mode, the physical address is remapped as below:
+ *
+ * CPU Physical address:
+ * ====================
+ *
+ * 0      1G       2G     3G       4G     5G
+ * |---A---|---B---|---C---|---D---|---E---|
+ * +--I/O--+------------Memory-------------+
+ *
+ * IOMMU output physical address:
+ *  =============================
+ *
+ *                                 4G      5G     6G      7G      8G
+ *                                 |---E---|---B---|---C---|---D---|
+ *                                 +------------Memory-------------+
+ *
+ * The Region 'A'(I/O) can NOT be mapped by M4U; For Region 'B'/'C'/'D', the
+ * bit32 of the CPU physical address always is needed to set, and for Region
+ * 'E', the CPU physical address keep as is.
+ * Additionally, The iommu consumers always use the CPU phyiscal address.
+ */
+#define MTK_IOMMU_4GB_MODE_REMAP_BASE	 0x40000000
+
 static LIST_HEAD(m4ulist);	/* List all the M4U HWs */
 
 #define for_each_m4u(data)	list_for_each_entry(data, &m4ulist, list)
@@ -401,7 +425,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
 	pa = dom->iop->iova_to_phys(dom->iop, iova);
 	spin_unlock_irqrestore(&dom->pgtlock, flags);
 
-	if (data->enable_4GB)
+	if (data->enable_4GB && pa < MTK_IOMMU_4GB_MODE_REMAP_BASE)
 		pa |= BIT_ULL(32);
 
 	return pa;
-- 
1.9.1


WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu@mediatek.com>
To: Joerg Roedel <joro@8bytes.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>
Cc: youlin.pei@mediatek.com, devicetree@vger.kernel.org,
	Nicolas Boichat <drinkcat@chromium.org>,
	cui.zhang@mediatek.com, srv_heupstream@mediatek.com,
	chao.hao@mediatek.com, linux-kernel@vger.kernel.org,
	Evan Green <evgreen@chromium.org>, Tomasz Figa <tfiga@google.com>,
	iommu@lists.linux-foundation.org,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org, yong.wu@mediatek.com,
	ming-fan.chen@mediatek.com, anan.sun@mediatek.com,
	Matthias Kaehlcke <mka@chromium.org>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH v11 05/23] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
Date: Sat, 24 Aug 2019 11:01:50 +0800	[thread overview]
Message-ID: <1566615728-26388-6-git-send-email-yong.wu@mediatek.com> (raw)
In-Reply-To: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>

In M4U 4GB mode, the physical address is remapped as below:

CPU Physical address:

====================

0      1G       2G     3G       4G     5G
|---A---|---B---|---C---|---D---|---E---|
+--I/O--+------------Memory-------------+

IOMMU output physical address:
 =============================

                                4G      5G     6G      7G      8G
                                |---E---|---B---|---C---|---D---|
                                +------------Memory-------------+

The Region 'A'(I/O) can not be mapped by M4U; For Region 'B'/'C'/'D', the
bit32 of the CPU physical address always is needed to set, and for Region
'E', the CPU physical address keep as is. something looks like this:
CPU PA         ->    M4U OUTPUT PA
0x4000_0000          0x1_4000_0000 (Add bit32)
0x8000_0000          0x1_8000_0000 ...
0xc000_0000          0x1_c000_0000 ...
0x1_0000_0000        0x1_0000_0000 (No change)

Additionally, the iommu consumers always use the CPU phyiscal address.

The PA in the iova_to_phys that is got from v7s always is u32, But
from the CPU point of view, PA only need add BIT(32) when PA < 0x4000_0000.

Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
 drivers/iommu/mtk_iommu.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c6e6dc3..9ba2706 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -107,6 +107,30 @@ struct mtk_iommu_domain {
 
 static const struct iommu_ops mtk_iommu_ops;
 
+/*
+ * In M4U 4GB mode, the physical address is remapped as below:
+ *
+ * CPU Physical address:
+ * ====================
+ *
+ * 0      1G       2G     3G       4G     5G
+ * |---A---|---B---|---C---|---D---|---E---|
+ * +--I/O--+------------Memory-------------+
+ *
+ * IOMMU output physical address:
+ *  =============================
+ *
+ *                                 4G      5G     6G      7G      8G
+ *                                 |---E---|---B---|---C---|---D---|
+ *                                 +------------Memory-------------+
+ *
+ * The Region 'A'(I/O) can NOT be mapped by M4U; For Region 'B'/'C'/'D', the
+ * bit32 of the CPU physical address always is needed to set, and for Region
+ * 'E', the CPU physical address keep as is.
+ * Additionally, The iommu consumers always use the CPU phyiscal address.
+ */
+#define MTK_IOMMU_4GB_MODE_REMAP_BASE	 0x40000000
+
 static LIST_HEAD(m4ulist);	/* List all the M4U HWs */
 
 #define for_each_m4u(data)	list_for_each_entry(data, &m4ulist, list)
@@ -401,7 +425,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
 	pa = dom->iop->iova_to_phys(dom->iop, iova);
 	spin_unlock_irqrestore(&dom->pgtlock, flags);
 
-	if (data->enable_4GB)
+	if (data->enable_4GB && pa < MTK_IOMMU_4GB_MODE_REMAP_BASE)
 		pa |= BIT_ULL(32);
 
 	return pa;
-- 
1.9.1

WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu@mediatek.com>
To: Joerg Roedel <joro@8bytes.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	 Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>
Cc: youlin.pei@mediatek.com, devicetree@vger.kernel.org,
	Nicolas Boichat <drinkcat@chromium.org>,
	cui.zhang@mediatek.com, srv_heupstream@mediatek.com,
	chao.hao@mediatek.com, linux-kernel@vger.kernel.org,
	Evan Green <evgreen@chromium.org>, Tomasz Figa <tfiga@google.com>,
	iommu@lists.linux-foundation.org,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org, ming-fan.chen@mediatek.com,
	anan.sun@mediatek.com, Matthias Kaehlcke <mka@chromium.org>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH v11 05/23] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
Date: Sat, 24 Aug 2019 11:01:50 +0800	[thread overview]
Message-ID: <1566615728-26388-6-git-send-email-yong.wu@mediatek.com> (raw)
In-Reply-To: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>

In M4U 4GB mode, the physical address is remapped as below:

CPU Physical address:

====================

0      1G       2G     3G       4G     5G
|---A---|---B---|---C---|---D---|---E---|
+--I/O--+------------Memory-------------+

IOMMU output physical address:
 =============================

                                4G      5G     6G      7G      8G
                                |---E---|---B---|---C---|---D---|
                                +------------Memory-------------+

The Region 'A'(I/O) can not be mapped by M4U; For Region 'B'/'C'/'D', the
bit32 of the CPU physical address always is needed to set, and for Region
'E', the CPU physical address keep as is. something looks like this:
CPU PA         ->    M4U OUTPUT PA
0x4000_0000          0x1_4000_0000 (Add bit32)
0x8000_0000          0x1_8000_0000 ...
0xc000_0000          0x1_c000_0000 ...
0x1_0000_0000        0x1_0000_0000 (No change)

Additionally, the iommu consumers always use the CPU phyiscal address.

The PA in the iova_to_phys that is got from v7s always is u32, But
from the CPU point of view, PA only need add BIT(32) when PA < 0x4000_0000.

Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
 drivers/iommu/mtk_iommu.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c6e6dc3..9ba2706 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -107,6 +107,30 @@ struct mtk_iommu_domain {
 
 static const struct iommu_ops mtk_iommu_ops;
 
+/*
+ * In M4U 4GB mode, the physical address is remapped as below:
+ *
+ * CPU Physical address:
+ * ====================
+ *
+ * 0      1G       2G     3G       4G     5G
+ * |---A---|---B---|---C---|---D---|---E---|
+ * +--I/O--+------------Memory-------------+
+ *
+ * IOMMU output physical address:
+ *  =============================
+ *
+ *                                 4G      5G     6G      7G      8G
+ *                                 |---E---|---B---|---C---|---D---|
+ *                                 +------------Memory-------------+
+ *
+ * The Region 'A'(I/O) can NOT be mapped by M4U; For Region 'B'/'C'/'D', the
+ * bit32 of the CPU physical address always is needed to set, and for Region
+ * 'E', the CPU physical address keep as is.
+ * Additionally, The iommu consumers always use the CPU phyiscal address.
+ */
+#define MTK_IOMMU_4GB_MODE_REMAP_BASE	 0x40000000
+
 static LIST_HEAD(m4ulist);	/* List all the M4U HWs */
 
 #define for_each_m4u(data)	list_for_each_entry(data, &m4ulist, list)
@@ -401,7 +425,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
 	pa = dom->iop->iova_to_phys(dom->iop, iova);
 	spin_unlock_irqrestore(&dom->pgtlock, flags);
 
-	if (data->enable_4GB)
+	if (data->enable_4GB && pa < MTK_IOMMU_4GB_MODE_REMAP_BASE)
 		pa |= BIT_ULL(32);
 
 	return pa;
-- 
1.9.1

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu@mediatek.com>
To: Joerg Roedel <joro@8bytes.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	 Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>
Cc: youlin.pei@mediatek.com, devicetree@vger.kernel.org,
	Nicolas Boichat <drinkcat@chromium.org>,
	cui.zhang@mediatek.com, srv_heupstream@mediatek.com,
	chao.hao@mediatek.com, linux-kernel@vger.kernel.org,
	Evan Green <evgreen@chromium.org>, Tomasz Figa <tfiga@google.com>,
	iommu@lists.linux-foundation.org,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org, yong.wu@mediatek.com,
	ming-fan.chen@mediatek.com, anan.sun@mediatek.com,
	Matthias Kaehlcke <mka@chromium.org>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH v11 05/23] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
Date: Sat, 24 Aug 2019 11:01:50 +0800	[thread overview]
Message-ID: <1566615728-26388-6-git-send-email-yong.wu@mediatek.com> (raw)
In-Reply-To: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>

In M4U 4GB mode, the physical address is remapped as below:

CPU Physical address:

====================

0      1G       2G     3G       4G     5G
|---A---|---B---|---C---|---D---|---E---|
+--I/O--+------------Memory-------------+

IOMMU output physical address:
 =============================

                                4G      5G     6G      7G      8G
                                |---E---|---B---|---C---|---D---|
                                +------------Memory-------------+

The Region 'A'(I/O) can not be mapped by M4U; For Region 'B'/'C'/'D', the
bit32 of the CPU physical address always is needed to set, and for Region
'E', the CPU physical address keep as is. something looks like this:
CPU PA         ->    M4U OUTPUT PA
0x4000_0000          0x1_4000_0000 (Add bit32)
0x8000_0000          0x1_8000_0000 ...
0xc000_0000          0x1_c000_0000 ...
0x1_0000_0000        0x1_0000_0000 (No change)

Additionally, the iommu consumers always use the CPU phyiscal address.

The PA in the iova_to_phys that is got from v7s always is u32, But
from the CPU point of view, PA only need add BIT(32) when PA < 0x4000_0000.

Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
 drivers/iommu/mtk_iommu.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c6e6dc3..9ba2706 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -107,6 +107,30 @@ struct mtk_iommu_domain {
 
 static const struct iommu_ops mtk_iommu_ops;
 
+/*
+ * In M4U 4GB mode, the physical address is remapped as below:
+ *
+ * CPU Physical address:
+ * ====================
+ *
+ * 0      1G       2G     3G       4G     5G
+ * |---A---|---B---|---C---|---D---|---E---|
+ * +--I/O--+------------Memory-------------+
+ *
+ * IOMMU output physical address:
+ *  =============================
+ *
+ *                                 4G      5G     6G      7G      8G
+ *                                 |---E---|---B---|---C---|---D---|
+ *                                 +------------Memory-------------+
+ *
+ * The Region 'A'(I/O) can NOT be mapped by M4U; For Region 'B'/'C'/'D', the
+ * bit32 of the CPU physical address always is needed to set, and for Region
+ * 'E', the CPU physical address keep as is.
+ * Additionally, The iommu consumers always use the CPU phyiscal address.
+ */
+#define MTK_IOMMU_4GB_MODE_REMAP_BASE	 0x40000000
+
 static LIST_HEAD(m4ulist);	/* List all the M4U HWs */
 
 #define for_each_m4u(data)	list_for_each_entry(data, &m4ulist, list)
@@ -401,7 +425,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
 	pa = dom->iop->iova_to_phys(dom->iop, iova);
 	spin_unlock_irqrestore(&dom->pgtlock, flags);
 
-	if (data->enable_4GB)
+	if (data->enable_4GB && pa < MTK_IOMMU_4GB_MODE_REMAP_BASE)
 		pa |= BIT_ULL(32);
 
 	return pa;
-- 
1.9.1


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

  parent reply	other threads:[~2019-08-24  3:20 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-24  3:01 [PATCH v11 00/23] MT8183 IOMMU SUPPORT Yong Wu
2019-08-24  3:01 ` Yong Wu
2019-08-24  3:01 ` Yong Wu
2019-08-24  3:01 ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 01/23] dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 02/23] iommu/mediatek: Use a struct as the platform data Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 03/23] memory: mtk-smi: Use a general config_port interface Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 04/23] memory: mtk-smi: Use a struct for the platform data for smi-common Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` Yong Wu [this message]
2019-08-24  3:01   ` [PATCH v11 05/23] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 06/23] iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr helpers Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 07/23] iommu/io-pgtable-arm-v7s: Use ias/oas to check the valid iova/pa Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 08/23] iommu/io-pgtable-arm-v7s: Rename the quirk from MTK_4GB to MTK_EXT Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 09/23] iommu/io-pgtable-arm-v7s: Extend to support PA[33:32] for MediaTek Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 10/23] iommu/mediatek: Adjust the PA for the 4GB Mode Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 11/23] iommu/mediatek: Add bclk can be supported optionally Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 12/23] iommu/mediatek: Add larb-id remapped support Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 13/23] iommu/mediatek: Refine protect memory definition Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01 ` [PATCH v11 14/23] iommu/mediatek: Move reset_axi into plat_data Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:01   ` Yong Wu
2019-08-24  3:02 ` [PATCH v11 15/23] iommu/mediatek: Move vld_pa_rng " Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02 ` [PATCH v11 16/23] memory: mtk-smi: Add gals support Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02 ` [PATCH v11 17/23] iommu/mediatek: Add mt8183 IOMMU support Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02 ` [PATCH v11 18/23] iommu/mediatek: Add mmu1 support Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02 ` [PATCH v11 19/23] memory: mtk-smi: Invoke pm runtime_callback to enable clocks Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02 ` [PATCH v11 20/23] memory: mtk-smi: Add bus_sel for mt8183 Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02 ` [PATCH v11 21/23] iommu/mediatek: Fix VLD_PA_RNG register backup when suspend Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02 ` [PATCH v11 22/23] memory: mtk-smi: Get rid of need_larbid Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02 ` [PATCH v11 23/23] iommu/mediatek: Clean up struct mtk_smi_iommu Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24  3:02   ` Yong Wu
2019-08-24 11:57 ` [PATCH v11 00/23] MT8183 IOMMU SUPPORT Will Deacon
2019-08-24 11:57   ` Will Deacon
2019-08-24 11:57   ` Will Deacon
2019-08-24 11:57   ` Will Deacon
2019-08-30 14:21 ` Joerg Roedel
2019-08-30 14:21   ` Joerg Roedel
2019-08-30 14:21   ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1566615728-26388-6-git-send-email-yong.wu@mediatek.com \
    --to=yong.wu@mediatek.com \
    --cc=anan.sun@mediatek.com \
    --cc=chao.hao@mediatek.com \
    --cc=cui.zhang@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=evgreen@chromium.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=ming-fan.chen@mediatek.com \
    --cc=mka@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=tfiga@google.com \
    --cc=will@kernel.org \
    --cc=youlin.pei@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.