* [PATCH v5 01/27] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 02/27] dt-bindings: memory: mediatek: Add a common larb-port header file Yong Wu
` (25 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Convert MediaTek IOMMU to DT schema.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/iommu/mediatek,iommu.txt | 105 -----------
.../bindings/iommu/mediatek,iommu.yaml | 167 ++++++++++++++++++
2 files changed, 167 insertions(+), 105 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
deleted file mode 100644
index ac949f7fe3d4..000000000000
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+++ /dev/null
@@ -1,105 +0,0 @@
-* Mediatek IOMMU Architecture Implementation
-
- Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U), and
-this M4U have two generations of HW architecture. Generation one uses flat
-pagetable, and only supports 4K size page mapping. Generation two uses the
-ARM Short-Descriptor translation table format for address translation.
-
- About the M4U Hardware Block Diagram, please check below:
-
- EMI (External Memory Interface)
- |
- m4u (Multimedia Memory Management Unit)
- |
- +--------+
- | |
- gals0-rx gals1-rx (Global Async Local Sync rx)
- | |
- | |
- gals0-tx gals1-tx (Global Async Local Sync tx)
- | | Some SoCs may have GALS.
- +--------+
- |
- SMI Common(Smart Multimedia Interface Common)
- |
- +----------------+-------
- | |
- | gals-rx There may be GALS in some larbs.
- | |
- | |
- | gals-tx
- | |
- SMI larb0 SMI larb1 ... SoCs have several SMI local arbiter(larb).
- (display) (vdec)
- | |
- | |
- +-----+-----+ +----+----+
- | | | | | |
- | | |... | | | ... There are different ports in each larb.
- | | | | | |
-OVL0 RDMA0 WDMA0 MC PP VLD
-
- As above, The Multimedia HW will go through SMI and M4U while it
-access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
-smi local arbiter and smi common. It will control whether the Multimedia
-HW should go though the m4u for translation or bypass it and talk
-directly with EMI. And also SMI help control the power domain and clocks for
-each local arbiter.
- Normally we specify a local arbiter(larb) for each multimedia HW
-like display, video decode, and camera. And there are different ports
-in each larb. Take a example, There are many ports like MC, PP, VLD in the
-video decode local arbiter, all these ports are according to the video HW.
- In some SoCs, there may be a GALS(Global Async Local Sync) module between
-smi-common and m4u, and additional GALS module between smi-larb and
-smi-common. GALS can been seen as a "asynchronous fifo" which could help
-synchronize for the modules in different clock frequency.
-
-Required properties:
-- compatible : must be one of the following string:
- "mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW.
- "mediatek,mt2712-m4u" for mt2712 which uses generation two m4u HW.
- "mediatek,mt6779-m4u" for mt6779 which uses generation two m4u HW.
- "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses
- generation one m4u HW.
- "mediatek,mt8167-m4u" for mt8167 which uses generation two m4u HW.
- "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
- "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW.
-- reg : m4u register base and size.
-- interrupts : the interrupt of m4u.
-- clocks : must contain one entry for each clock-names.
-- clock-names : Only 1 optional clock:
- - "bclk": the block clock of m4u.
- Here is the list which require this "bclk":
- - mt2701, mt2712, mt7623 and mt8173.
- Note that m4u use the EMI clock which always has been enabled before kernel
- if there is no this "bclk".
-- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
- Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
- according to the local arbiter index, like larb0, larb1, larb2...
-- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
- Specifies the mtk_m4u_id as defined in
- dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623
- dt-binding/memory/mt2712-larb-port.h for mt2712,
- dt-binding/memory/mt6779-larb-port.h for mt6779,
- dt-binding/memory/mt8167-larb-port.h for mt8167,
- dt-binding/memory/mt8173-larb-port.h for mt8173, and
- dt-binding/memory/mt8183-larb-port.h for mt8183.
-
-Example:
- iommu: iommu@10205000 {
- compatible = "mediatek,mt8173-m4u";
- reg = <0 0x10205000 0 0x1000>;
- interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&infracfg CLK_INFRA_M4U>;
- clock-names = "bclk";
- mediatek,larbs = <&larb0 &larb1 &larb2 &larb3 &larb4 &larb5>;
- #iommu-cells = <1>;
- };
-
-Example for a client device:
- display {
- compatible = "mediatek,mt8173-disp";
- iommus = <&iommu M4U_PORT_DISP_OVL0>,
- <&iommu M4U_PORT_DISP_RDMA0>;
- ...
- };
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
new file mode 100644
index 000000000000..b9946809fc2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/mediatek,iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek IOMMU Architecture Implementation
+
+maintainers:
+ - Yong Wu <yong.wu@mediatek.com>
+
+description: |+
+ Some MediaTek SOCs contain a Multimedia Memory Management Unit (M4U), and
+ this M4U have two generations of HW architecture. Generation one uses flat
+ pagetable, and only supports 4K size page mapping. Generation two uses the
+ ARM Short-Descriptor translation table format for address translation.
+
+ About the M4U Hardware Block Diagram, please check below:
+
+ EMI (External Memory Interface)
+ |
+ m4u (Multimedia Memory Management Unit)
+ |
+ +--------+
+ | |
+ gals0-rx gals1-rx (Global Async Local Sync rx)
+ | |
+ | |
+ gals0-tx gals1-tx (Global Async Local Sync tx)
+ | | Some SoCs may have GALS.
+ +--------+
+ |
+ SMI Common(Smart Multimedia Interface Common)
+ |
+ +----------------+-------
+ | |
+ | gals-rx There may be GALS in some larbs.
+ | |
+ | |
+ | gals-tx
+ | |
+ SMI larb0 SMI larb1 ... SoCs have several SMI local arbiter(larb).
+ (display) (vdec)
+ | |
+ | |
+ +-----+-----+ +----+----+
+ | | | | | |
+ | | |... | | | ... There are different ports in each larb.
+ | | | | | |
+ OVL0 RDMA0 WDMA0 MC PP VLD
+
+ As above, The Multimedia HW will go through SMI and M4U while it
+ access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
+ smi local arbiter and smi common. It will control whether the Multimedia
+ HW should go though the m4u for translation or bypass it and talk
+ directly with EMI. And also SMI help control the power domain and clocks for
+ each local arbiter.
+
+ Normally we specify a local arbiter(larb) for each multimedia HW
+ like display, video decode, and camera. And there are different ports
+ in each larb. Take a example, There are many ports like MC, PP, VLD in the
+ video decode local arbiter, all these ports are according to the video HW.
+
+ In some SoCs, there may be a GALS(Global Async Local Sync) module between
+ smi-common and m4u, and additional GALS module between smi-larb and
+ smi-common. GALS can been seen as a "asynchronous fifo" which could help
+ synchronize for the modules in different clock frequency.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt2701-m4u # generation one
+ - mediatek,mt2712-m4u # generation two
+ - mediatek,mt6779-m4u # generation two
+ - mediatek,mt8167-m4u # generation two
+ - mediatek,mt8173-m4u # generation two
+ - mediatek,mt8183-m4u # generation two
+
+ - description: mt7623 generation one
+ items:
+ - const: mediatek,mt7623-m4u
+ - const: mediatek,mt2701-m4u
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: bclk is the block clock.
+
+ clock-names:
+ items:
+ - const: bclk
+
+ mediatek,larbs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 16
+ description: |
+ List of phandle to the local arbiters in the current Socs.
+ Refer to bindings/memory-controllers/mediatek,smi-larb.yaml. It must sort
+ according to the local arbiter index, like larb0, larb1, larb2...
+
+ '#iommu-cells':
+ const: 1
+ description: |
+ This is the mtk_m4u_id according to the HW. Specifies the mtk_m4u_id as
+ defined in
+ 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/mt8167-larb-port.h for mt8167,
+ dt-binding/memory/mt8173-larb-port.h for mt8173,
+ dt-binding/memory/mt8183-larb-port.h for mt8183.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - mediatek,larbs
+ - '#iommu-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt2701-m4u
+ - mediatek,mt2712-m4u
+ - mediatek,mt8173-m4u
+
+ then:
+ required:
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ iommu: iommu@10205000 {
+ compatible = "mediatek,mt8173-m4u";
+ reg = <0x10205000 0x1000>;
+ interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_M4U>;
+ clock-names = "bclk";
+ mediatek,larbs = <&larb0 &larb1 &larb2
+ &larb3 &larb4 &larb5>;
+ #iommu-cells = <1>;
+ };
+
+ - |
+ #include <dt-bindings/memory/mt8173-larb-port.h>
+
+ /* Example for a client device */
+ display {
+ compatible = "mediatek,mt8173-disp";
+ iommus = <&iommu M4U_PORT_DISP_OVL0>,
+ <&iommu M4U_PORT_DISP_RDMA0>;
+ };
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 02/27] dt-bindings: memory: mediatek: Add a common larb-port header file
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
2020-12-09 8:00 ` [PATCH v5 01/27] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 03/27] dt-bindings: memory: mediatek: Extend LARB_NR_MAX to 32 Yong Wu
` (24 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Put all the macros about smi larb/port togethers, this is a preparing
patch for extending LARB_NR and adding new dom-id support.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
include/dt-bindings/memory/mt2712-larb-port.h | 2 +-
include/dt-bindings/memory/mt6779-larb-port.h | 2 +-
include/dt-bindings/memory/mt8167-larb-port.h | 2 +-
include/dt-bindings/memory/mt8173-larb-port.h | 2 +-
include/dt-bindings/memory/mt8183-larb-port.h | 2 +-
include/dt-bindings/memory/mtk-smi-larb-port.h | 15 +++++++++++++++
6 files changed, 20 insertions(+), 5 deletions(-)
create mode 100644 include/dt-bindings/memory/mtk-smi-larb-port.h
diff --git a/include/dt-bindings/memory/mt2712-larb-port.h b/include/dt-bindings/memory/mt2712-larb-port.h
index 6f9aa7349cef..b6b2c6bf4459 100644
--- a/include/dt-bindings/memory/mt2712-larb-port.h
+++ b/include/dt-bindings/memory/mt2712-larb-port.h
@@ -6,7 +6,7 @@
#ifndef __DTS_IOMMU_PORT_MT2712_H
#define __DTS_IOMMU_PORT_MT2712_H
-#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+#include <dt-bindings/memory/mtk-smi-larb-port.h>
#define M4U_LARB0_ID 0
#define M4U_LARB1_ID 1
diff --git a/include/dt-bindings/memory/mt6779-larb-port.h b/include/dt-bindings/memory/mt6779-larb-port.h
index 2ad0899fbf2f..60f57f54393e 100644
--- a/include/dt-bindings/memory/mt6779-larb-port.h
+++ b/include/dt-bindings/memory/mt6779-larb-port.h
@@ -7,7 +7,7 @@
#ifndef _DTS_IOMMU_PORT_MT6779_H_
#define _DTS_IOMMU_PORT_MT6779_H_
-#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+#include <dt-bindings/memory/mtk-smi-larb-port.h>
#define M4U_LARB0_ID 0
#define M4U_LARB1_ID 1
diff --git a/include/dt-bindings/memory/mt8167-larb-port.h b/include/dt-bindings/memory/mt8167-larb-port.h
index 000fb299a408..fcb9a49ec60e 100644
--- a/include/dt-bindings/memory/mt8167-larb-port.h
+++ b/include/dt-bindings/memory/mt8167-larb-port.h
@@ -8,7 +8,7 @@
#ifndef __DTS_IOMMU_PORT_MT8167_H
#define __DTS_IOMMU_PORT_MT8167_H
-#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+#include <dt-bindings/memory/mtk-smi-larb-port.h>
#define M4U_LARB0_ID 0
#define M4U_LARB1_ID 1
diff --git a/include/dt-bindings/memory/mt8173-larb-port.h b/include/dt-bindings/memory/mt8173-larb-port.h
index 9f31ccfeca21..d8c99c946053 100644
--- a/include/dt-bindings/memory/mt8173-larb-port.h
+++ b/include/dt-bindings/memory/mt8173-larb-port.h
@@ -6,7 +6,7 @@
#ifndef __DTS_IOMMU_PORT_MT8173_H
#define __DTS_IOMMU_PORT_MT8173_H
-#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+#include <dt-bindings/memory/mtk-smi-larb-port.h>
#define M4U_LARB0_ID 0
#define M4U_LARB1_ID 1
diff --git a/include/dt-bindings/memory/mt8183-larb-port.h b/include/dt-bindings/memory/mt8183-larb-port.h
index 2c579f305162..275c095a6fd6 100644
--- a/include/dt-bindings/memory/mt8183-larb-port.h
+++ b/include/dt-bindings/memory/mt8183-larb-port.h
@@ -6,7 +6,7 @@
#ifndef __DTS_IOMMU_PORT_MT8183_H
#define __DTS_IOMMU_PORT_MT8183_H
-#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+#include <dt-bindings/memory/mtk-smi-larb-port.h>
#define M4U_LARB0_ID 0
#define M4U_LARB1_ID 1
diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h
new file mode 100644
index 000000000000..53354cf4f6e3
--- /dev/null
+++ b/include/dt-bindings/memory/mtk-smi-larb-port.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ * Author: Yong Wu <yong.wu@mediatek.com>
+ */
+#ifndef __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_
+#define __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_
+
+#define MTK_LARB_NR_MAX 16
+
+#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+#define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0xf)
+#define MTK_M4U_TO_PORT(id) ((id) & 0x1f)
+
+#endif
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 03/27] dt-bindings: memory: mediatek: Extend LARB_NR_MAX to 32
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
2020-12-09 8:00 ` [PATCH v5 01/27] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema Yong Wu
2020-12-09 8:00 ` [PATCH v5 02/27] dt-bindings: memory: mediatek: Add a common larb-port header file Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 04/27] dt-bindings: memory: mediatek: Add domain definition Yong Wu
` (23 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Extend the max larb number definition as mt8192 has larb_nr over 16.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml | 2 +-
include/dt-bindings/memory/mtk-smi-larb-port.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
index b9946809fc2b..ba6626347381 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
@@ -99,7 +99,7 @@ properties:
mediatek,larbs:
$ref: /schemas/types.yaml#/definitions/phandle-array
minItems: 1
- maxItems: 16
+ maxItems: 32
description: |
List of phandle to the local arbiters in the current Socs.
Refer to bindings/memory-controllers/mediatek,smi-larb.yaml. It must sort
diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h
index 53354cf4f6e3..7d64103209af 100644
--- a/include/dt-bindings/memory/mtk-smi-larb-port.h
+++ b/include/dt-bindings/memory/mtk-smi-larb-port.h
@@ -6,10 +6,10 @@
#ifndef __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_
#define __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_
-#define MTK_LARB_NR_MAX 16
+#define MTK_LARB_NR_MAX 32
#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
-#define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0xf)
+#define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0x1f)
#define MTK_M4U_TO_PORT(id) ((id) & 0x1f)
#endif
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 04/27] dt-bindings: memory: mediatek: Add domain definition
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (2 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 03/27] dt-bindings: memory: mediatek: Extend LARB_NR_MAX to 32 Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-23 8:15 ` Tomasz Figa
2020-12-09 8:00 ` [PATCH v5 05/27] dt-bindings: memory: mediatek: Rename header guard for SMI header file Yong Wu
` (22 subsequent siblings)
26 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
In the latest SoC, there are several HW IP require a sepecial iova
range, mainly CCU and VPU has this requirement. Take CCU as a example,
CCU require its iova locate in the range(0x4000_0000 ~ 0x43ff_ffff).
In this patch we add a domain definition for the special port. In the
example of CCU, If we preassign CCU port in domain1, then iommu driver
will prepare a independent iommu domain of the special iova range for it,
then the iova got from dma_alloc_attrs(ccu-dev) will locate in its special
range.
This is a preparing patch for multi-domain support.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
---
include/dt-bindings/memory/mtk-smi-larb-port.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h
index 7d64103209af..2d4c973c174f 100644
--- a/include/dt-bindings/memory/mtk-smi-larb-port.h
+++ b/include/dt-bindings/memory/mtk-smi-larb-port.h
@@ -7,9 +7,16 @@
#define __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_
#define MTK_LARB_NR_MAX 32
+#define MTK_M4U_DOM_NR_MAX 8
+
+#define MTK_M4U_DOM_ID(domid, larb, port) \
+ (((domid) & 0x7) << 16 | (((larb) & 0x1f) << 5) | ((port) & 0x1f))
+
+/* The default dom id is 0. */
+#define MTK_M4U_ID(larb, port) MTK_M4U_DOM_ID(0, larb, port)
-#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
#define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0x1f)
#define MTK_M4U_TO_PORT(id) ((id) & 0x1f)
+#define MTK_M4U_TO_DOM(id) (((id) >> 16) & 0x7)
#endif
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [PATCH v5 04/27] dt-bindings: memory: mediatek: Add domain definition
2020-12-09 8:00 ` [PATCH v5 04/27] dt-bindings: memory: mediatek: Add domain definition Yong Wu
@ 2020-12-23 8:15 ` Tomasz Figa
2020-12-24 11:26 ` Yong Wu
0 siblings, 1 reply; 56+ messages in thread
From: Tomasz Figa @ 2020-12-23 8:15 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
Hi Yong,
On Wed, Dec 09, 2020 at 04:00:39PM +0800, Yong Wu wrote:
> In the latest SoC, there are several HW IP require a sepecial iova
> range, mainly CCU and VPU has this requirement. Take CCU as a example,
> CCU require its iova locate in the range(0x4000_0000 ~ 0x43ff_ffff).
Is this really a domain? Does the address range come from the design of
the IOMMU?
Best regards,
Tomasz
>
> In this patch we add a domain definition for the special port. In the
> example of CCU, If we preassign CCU port in domain1, then iommu driver
> will prepare a independent iommu domain of the special iova range for it,
> then the iova got from dma_alloc_attrs(ccu-dev) will locate in its special
> range.
>
> This is a preparing patch for multi-domain support.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> include/dt-bindings/memory/mtk-smi-larb-port.h | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h
> index 7d64103209af..2d4c973c174f 100644
> --- a/include/dt-bindings/memory/mtk-smi-larb-port.h
> +++ b/include/dt-bindings/memory/mtk-smi-larb-port.h
> @@ -7,9 +7,16 @@
> #define __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_
>
> #define MTK_LARB_NR_MAX 32
> +#define MTK_M4U_DOM_NR_MAX 8
> +
> +#define MTK_M4U_DOM_ID(domid, larb, port) \
> + (((domid) & 0x7) << 16 | (((larb) & 0x1f) << 5) | ((port) & 0x1f))
> +
> +/* The default dom id is 0. */
> +#define MTK_M4U_ID(larb, port) MTK_M4U_DOM_ID(0, larb, port)
>
> -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
> #define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0x1f)
> #define MTK_M4U_TO_PORT(id) ((id) & 0x1f)
> +#define MTK_M4U_TO_DOM(id) (((id) >> 16) & 0x7)
>
> #endif
> --
> 2.18.0
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 04/27] dt-bindings: memory: mediatek: Add domain definition
2020-12-23 8:15 ` Tomasz Figa
@ 2020-12-24 11:26 ` Yong Wu
2021-01-13 5:22 ` Tomasz Figa
0 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2020-12-24 11:26 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, 2020-12-23 at 17:15 +0900, Tomasz Figa wrote:
> Hi Yong,
>
> On Wed, Dec 09, 2020 at 04:00:39PM +0800, Yong Wu wrote:
> > In the latest SoC, there are several HW IP require a sepecial iova
> > range, mainly CCU and VPU has this requirement. Take CCU as a example,
> > CCU require its iova locate in the range(0x4000_0000 ~ 0x43ff_ffff).
>
> Is this really a domain? Does the address range come from the design of
> the IOMMU?
It is not a really a domain. The address range comes from CCU HW
requirement. That HW can only access this iova range. thus I create a
special iommu domain for it.
>
> Best regards,
> Tomasz
>
> >
> > In this patch we add a domain definition for the special port. In the
> > example of CCU, If we preassign CCU port in domain1, then iommu driver
> > will prepare a independent iommu domain of the special iova range for it,
> > then the iova got from dma_alloc_attrs(ccu-dev) will locate in its special
> > range.
> >
> > This is a preparing patch for multi-domain support.
> >
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> > include/dt-bindings/memory/mtk-smi-larb-port.h | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h
> > index 7d64103209af..2d4c973c174f 100644
> > --- a/include/dt-bindings/memory/mtk-smi-larb-port.h
> > +++ b/include/dt-bindings/memory/mtk-smi-larb-port.h
> > @@ -7,9 +7,16 @@
> > #define __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_
> >
> > #define MTK_LARB_NR_MAX 32
> > +#define MTK_M4U_DOM_NR_MAX 8
> > +
> > +#define MTK_M4U_DOM_ID(domid, larb, port) \
> > + (((domid) & 0x7) << 16 | (((larb) & 0x1f) << 5) | ((port) & 0x1f))
> > +
> > +/* The default dom id is 0. */
> > +#define MTK_M4U_ID(larb, port) MTK_M4U_DOM_ID(0, larb, port)
> >
> > -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
> > #define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0x1f)
> > #define MTK_M4U_TO_PORT(id) ((id) & 0x1f)
> > +#define MTK_M4U_TO_DOM(id) (((id) >> 16) & 0x7)
> >
> > #endif
> > --
> > 2.18.0
> >
> > _______________________________________________
> > iommu mailing list
> > iommu@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 04/27] dt-bindings: memory: mediatek: Add domain definition
2020-12-24 11:26 ` Yong Wu
@ 2021-01-13 5:22 ` Tomasz Figa
0 siblings, 0 replies; 56+ messages in thread
From: Tomasz Figa @ 2021-01-13 5:22 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Will Deacon, Linux Kernel Mailing List, Evan Green, chao.hao,
open list:IOMMU DRIVERS, Rob Herring,
moderated list:ARM/Mediatek SoC support, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
On Thu, Dec 24, 2020 at 8:27 PM Yong Wu <yong.wu@mediatek.com> wrote:
>
> On Wed, 2020-12-23 at 17:15 +0900, Tomasz Figa wrote:
> > Hi Yong,
> >
> > On Wed, Dec 09, 2020 at 04:00:39PM +0800, Yong Wu wrote:
> > > In the latest SoC, there are several HW IP require a sepecial iova
> > > range, mainly CCU and VPU has this requirement. Take CCU as a example,
> > > CCU require its iova locate in the range(0x4000_0000 ~ 0x43ff_ffff).
> >
> > Is this really a domain? Does the address range come from the design of
> > the IOMMU?
>
> It is not a really a domain. The address range comes from CCU HW
> requirement. That HW can only access this iova range. thus I create a
> special iommu domain for it.
>
I guess it's the IOMMU/DT maintainers who have the last word here, but
shouldn't DT just specify the hardware characteristics and then the
kernel configure the hardware appropriately, possibly based on some
other configuration interface (e.g. command line parameters or sysfs)?
How I'd do this is rather than enforcing those arbitrary decisions
onto the DT bindings, I'd add properties to the master devices (e.g.
CCU) that specify which IOVA range they can operate on. Then, the
exact split of the complete address space would be done at runtime,
based on kernel configuration, command line parameters and possibly
sysfs attributes if things could be reconfigured dynamically.
Best regards,
Tomasz
> >
> > Best regards,
> > Tomasz
> >
> > >
> > > In this patch we add a domain definition for the special port. In the
> > > example of CCU, If we preassign CCU port in domain1, then iommu driver
> > > will prepare a independent iommu domain of the special iova range for it,
> > > then the iova got from dma_alloc_attrs(ccu-dev) will locate in its special
> > > range.
> > >
> > > This is a preparing patch for multi-domain support.
> > >
> > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > Acked-by: Rob Herring <robh@kernel.org>
> > > ---
> > > include/dt-bindings/memory/mtk-smi-larb-port.h | 9 ++++++++-
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h
> > > index 7d64103209af..2d4c973c174f 100644
> > > --- a/include/dt-bindings/memory/mtk-smi-larb-port.h
> > > +++ b/include/dt-bindings/memory/mtk-smi-larb-port.h
> > > @@ -7,9 +7,16 @@
> > > #define __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_
> > >
> > > #define MTK_LARB_NR_MAX 32
> > > +#define MTK_M4U_DOM_NR_MAX 8
> > > +
> > > +#define MTK_M4U_DOM_ID(domid, larb, port) \
> > > + (((domid) & 0x7) << 16 | (((larb) & 0x1f) << 5) | ((port) & 0x1f))
> > > +
> > > +/* The default dom id is 0. */
> > > +#define MTK_M4U_ID(larb, port) MTK_M4U_DOM_ID(0, larb, port)
> > >
> > > -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
> > > #define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0x1f)
> > > #define MTK_M4U_TO_PORT(id) ((id) & 0x1f)
> > > +#define MTK_M4U_TO_DOM(id) (((id) >> 16) & 0x7)
> > >
> > > #endif
> > > --
> > > 2.18.0
> > >
> > > _______________________________________________
> > > iommu mailing list
> > > iommu@lists.linux-foundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH v5 05/27] dt-bindings: memory: mediatek: Rename header guard for SMI header file
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (3 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 04/27] dt-bindings: memory: mediatek: Add domain definition Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 12:12 ` Krzysztof Kozlowski
2020-12-11 3:26 ` Rob Herring
2020-12-09 8:00 ` [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU Yong Wu
` (21 subsequent siblings)
26 siblings, 2 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Only rename the header guard for all the SoC larb port header file.
No funtional change.
Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
include/dt-bindings/memory/mt2701-larb-port.h | 4 ++--
include/dt-bindings/memory/mt2712-larb-port.h | 4 ++--
include/dt-bindings/memory/mt6779-larb-port.h | 4 ++--
include/dt-bindings/memory/mt8167-larb-port.h | 4 ++--
include/dt-bindings/memory/mt8173-larb-port.h | 4 ++--
include/dt-bindings/memory/mt8183-larb-port.h | 4 ++--
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/dt-bindings/memory/mt2701-larb-port.h b/include/dt-bindings/memory/mt2701-larb-port.h
index 2d85c2ec6cfd..25d03526f142 100644
--- a/include/dt-bindings/memory/mt2701-larb-port.h
+++ b/include/dt-bindings/memory/mt2701-larb-port.h
@@ -4,8 +4,8 @@
* Author: Honghui Zhang <honghui.zhang@mediatek.com>
*/
-#ifndef _MT2701_LARB_PORT_H_
-#define _MT2701_LARB_PORT_H_
+#ifndef _DT_BINDINGS_MEMORY_MT2701_LARB_PORT_H_
+#define _DT_BINDINGS_MEMORY_MT2701_LARB_PORT_H_
/*
* Mediatek m4u generation 1 such as mt2701 has flat m4u port numbers,
diff --git a/include/dt-bindings/memory/mt2712-larb-port.h b/include/dt-bindings/memory/mt2712-larb-port.h
index b6b2c6bf4459..5c7f303f078c 100644
--- a/include/dt-bindings/memory/mt2712-larb-port.h
+++ b/include/dt-bindings/memory/mt2712-larb-port.h
@@ -3,8 +3,8 @@
* Copyright (c) 2017 MediaTek Inc.
* Author: Yong Wu <yong.wu@mediatek.com>
*/
-#ifndef __DTS_IOMMU_PORT_MT2712_H
-#define __DTS_IOMMU_PORT_MT2712_H
+#ifndef _DT_BINDINGS_MEMORY_MT2712_LARB_PORT_H_
+#define _DT_BINDINGS_MEMORY_MT2712_LARB_PORT_H_
#include <dt-bindings/memory/mtk-smi-larb-port.h>
diff --git a/include/dt-bindings/memory/mt6779-larb-port.h b/include/dt-bindings/memory/mt6779-larb-port.h
index 60f57f54393e..bc93757df2bf 100644
--- a/include/dt-bindings/memory/mt6779-larb-port.h
+++ b/include/dt-bindings/memory/mt6779-larb-port.h
@@ -4,8 +4,8 @@
* Author: Chao Hao <chao.hao@mediatek.com>
*/
-#ifndef _DTS_IOMMU_PORT_MT6779_H_
-#define _DTS_IOMMU_PORT_MT6779_H_
+#ifndef _DT_BINDINGS_MEMORY_MT6779_LARB_PORT_H_
+#define _DT_BINDINGS_MEMORY_MT6779_LARB_PORT_H_
#include <dt-bindings/memory/mtk-smi-larb-port.h>
diff --git a/include/dt-bindings/memory/mt8167-larb-port.h b/include/dt-bindings/memory/mt8167-larb-port.h
index fcb9a49ec60e..8570aab09db8 100644
--- a/include/dt-bindings/memory/mt8167-larb-port.h
+++ b/include/dt-bindings/memory/mt8167-larb-port.h
@@ -5,8 +5,8 @@
* Author: Honghui Zhang <honghui.zhang@mediatek.com>
* Author: Fabien Parent <fparent@baylibre.com>
*/
-#ifndef __DTS_IOMMU_PORT_MT8167_H
-#define __DTS_IOMMU_PORT_MT8167_H
+#ifndef _DT_BINDINGS_MEMORY_MT8167_LARB_PORT_H_
+#define _DT_BINDINGS_MEMORY_MT8167_LARB_PORT_H_
#include <dt-bindings/memory/mtk-smi-larb-port.h>
diff --git a/include/dt-bindings/memory/mt8173-larb-port.h b/include/dt-bindings/memory/mt8173-larb-port.h
index d8c99c946053..1b568973fc2d 100644
--- a/include/dt-bindings/memory/mt8173-larb-port.h
+++ b/include/dt-bindings/memory/mt8173-larb-port.h
@@ -3,8 +3,8 @@
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu <yong.wu@mediatek.com>
*/
-#ifndef __DTS_IOMMU_PORT_MT8173_H
-#define __DTS_IOMMU_PORT_MT8173_H
+#ifndef _DT_BINDINGS_MEMORY_MT8173_LARB_PORT_H_
+#define _DT_BINDINGS_MEMORY_MT8173_LARB_PORT_H_
#include <dt-bindings/memory/mtk-smi-larb-port.h>
diff --git a/include/dt-bindings/memory/mt8183-larb-port.h b/include/dt-bindings/memory/mt8183-larb-port.h
index 275c095a6fd6..3095630bb190 100644
--- a/include/dt-bindings/memory/mt8183-larb-port.h
+++ b/include/dt-bindings/memory/mt8183-larb-port.h
@@ -3,8 +3,8 @@
* Copyright (c) 2018 MediaTek Inc.
* Author: Yong Wu <yong.wu@mediatek.com>
*/
-#ifndef __DTS_IOMMU_PORT_MT8183_H
-#define __DTS_IOMMU_PORT_MT8183_H
+#ifndef _DT_BINDINGS_MEMORY_MT8183_LARB_PORT_H_
+#define _DT_BINDINGS_MEMORY_MT8183_LARB_PORT_H_
#include <dt-bindings/memory/mtk-smi-larb-port.h>
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [PATCH v5 05/27] dt-bindings: memory: mediatek: Rename header guard for SMI header file
2020-12-09 8:00 ` [PATCH v5 05/27] dt-bindings: memory: mediatek: Rename header guard for SMI header file Yong Wu
@ 2020-12-09 12:12 ` Krzysztof Kozlowski
2020-12-11 3:26 ` Rob Herring
1 sibling, 0 replies; 56+ messages in thread
From: Krzysztof Kozlowski @ 2020-12-09 12:12 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, Will Deacon, linux-kernel, Evan Green, Tomasz Figa,
iommu, Rob Herring, linux-mediatek, Matthias Brugger, anan.sun,
Robin Murphy, linux-arm-kernel
On Wed, Dec 09, 2020 at 04:00:40PM +0800, Yong Wu wrote:
> Only rename the header guard for all the SoC larb port header file.
> No funtional change.
>
> Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 05/27] dt-bindings: memory: mediatek: Rename header guard for SMI header file
2020-12-09 8:00 ` [PATCH v5 05/27] dt-bindings: memory: mediatek: Rename header guard for SMI header file Yong Wu
2020-12-09 12:12 ` Krzysztof Kozlowski
@ 2020-12-11 3:26 ` Rob Herring
1 sibling, 0 replies; 56+ messages in thread
From: Rob Herring @ 2020-12-11 3:26 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, anan.sun, Nicolas Boichat, srv_heupstream, chao.hao,
Will Deacon, linux-kernel, Krzysztof Kozlowski, iommu,
Tomasz Figa, devicetree, Rob Herring, linux-mediatek, Evan Green,
Matthias Brugger, Robin Murphy, linux-arm-kernel
On Wed, 09 Dec 2020 16:00:40 +0800, Yong Wu wrote:
> Only rename the header guard for all the SoC larb port header file.
> No funtional change.
>
> Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> include/dt-bindings/memory/mt2701-larb-port.h | 4 ++--
> include/dt-bindings/memory/mt2712-larb-port.h | 4 ++--
> include/dt-bindings/memory/mt6779-larb-port.h | 4 ++--
> include/dt-bindings/memory/mt8167-larb-port.h | 4 ++--
> include/dt-bindings/memory/mt8173-larb-port.h | 4 ++--
> include/dt-bindings/memory/mt8183-larb-port.h | 4 ++--
> 6 files changed, 12 insertions(+), 12 deletions(-)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (4 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 05/27] dt-bindings: memory: mediatek: Rename header guard for SMI header file Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 12:13 ` Krzysztof Kozlowski
2020-12-23 8:18 ` Tomasz Figa
2020-12-09 8:00 ` [PATCH v5 07/27] iommu/mediatek: Use the common mtk-smi-larb-port.h Yong Wu
` (20 subsequent siblings)
26 siblings, 2 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
This patch adds decriptions for mt8192 IOMMU and SMI.
mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
table format. The M4U-SMI HW diagram is as below:
EMI
|
M4U
|
------------
SMI Common
------------
|
+-------+------+------+----------------------+-------+
| | | | ...... | |
| | | | | |
larb0 larb1 larb2 larb4 ...... larb19 larb20
disp0 disp1 mdp vdec IPE IPE
All the connections are HW fixed, SW can NOT adjust it.
mt8192 M4U support 0~16GB iova range. we preassign different engines
into different iova ranges:
domain-id module iova-range larbs
0 disp 0 ~ 4G larb0/1
1 vcodec 4G ~ 8G larb4/5/7
2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
The iova range for CCU0/1(camera control unit) is HW requirement.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/iommu/mediatek,iommu.yaml | 18 +-
include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
2 files changed, 257 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
index ba6626347381..0f26fe14c8e2 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
@@ -76,6 +76,7 @@ properties:
- mediatek,mt8167-m4u # generation two
- mediatek,mt8173-m4u # generation two
- mediatek,mt8183-m4u # generation two
+ - mediatek,mt8192-m4u # generation two
- description: mt7623 generation one
items:
@@ -115,7 +116,11 @@ properties:
dt-binding/memory/mt6779-larb-port.h for mt6779,
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.
+ dt-binding/memory/mt8183-larb-port.h for mt8183,
+ dt-binding/memory/mt8192-larb-port.h for mt8192.
+
+ power-domains:
+ maxItems: 1
required:
- compatible
@@ -133,11 +138,22 @@ allOf:
- mediatek,mt2701-m4u
- mediatek,mt2712-m4u
- mediatek,mt8173-m4u
+ - mediatek,mt8192-m4u
then:
required:
- clocks
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8192-m4u
+
+ then:
+ required:
+ - power-domains
+
additionalProperties: false
examples:
diff --git a/include/dt-bindings/memory/mt8192-larb-port.h b/include/dt-bindings/memory/mt8192-larb-port.h
new file mode 100644
index 000000000000..ec1ac2ba7094
--- /dev/null
+++ b/include/dt-bindings/memory/mt8192-larb-port.h
@@ -0,0 +1,240 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ *
+ * Author: Chao Hao <chao.hao@mediatek.com>
+ * Author: Yong Wu <yong.wu@mediatek.com>
+ */
+#ifndef _DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_
+#define _DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_
+
+#include <dt-bindings/memory/mtk-smi-larb-port.h>
+
+/*
+ * MM IOMMU:
+ * domain 0: display: larb0, larb1.
+ * domain 1: vcodec: larb4, larb5, larb7.
+ * domain 2: CAM/MDP: larb2, larb9, larb11, larb13, larb14, larb16,
+ * larb17, larb18, larb19, larb20,
+ * domain 3: CCU0: larb13 - port9/10.
+ * domain 4: CCU1: larb14 - port4/5.
+ *
+ * larb3/6/8/10/12/15 is null.
+ */
+
+/* larb0 */
+#define M4U_PORT_L0_DISP_POSTMASK0 MTK_M4U_DOM_ID(0, 0, 0)
+#define M4U_PORT_L0_OVL_RDMA0_HDR MTK_M4U_DOM_ID(0, 0, 1)
+#define M4U_PORT_L0_OVL_RDMA0 MTK_M4U_DOM_ID(0, 0, 2)
+#define M4U_PORT_L0_DISP_RDMA0 MTK_M4U_DOM_ID(0, 0, 3)
+#define M4U_PORT_L0_DISP_WDMA0 MTK_M4U_DOM_ID(0, 0, 4)
+#define M4U_PORT_L0_DISP_FAKE0 MTK_M4U_DOM_ID(0, 0, 5)
+
+/* larb1 */
+#define M4U_PORT_L1_OVL_2L_RDMA0_HDR MTK_M4U_DOM_ID(0, 1, 0)
+#define M4U_PORT_L1_OVL_2L_RDMA2_HDR MTK_M4U_DOM_ID(0, 1, 1)
+#define M4U_PORT_L1_OVL_2L_RDMA0 MTK_M4U_DOM_ID(0, 1, 2)
+#define M4U_PORT_L1_OVL_2L_RDMA2 MTK_M4U_DOM_ID(0, 1, 3)
+#define M4U_PORT_L1_DISP_MDP_RDMA4 MTK_M4U_DOM_ID(0, 1, 4)
+#define M4U_PORT_L1_DISP_RDMA4 MTK_M4U_DOM_ID(0, 1, 5)
+#define M4U_PORT_L1_DISP_UFBC_WDMA0 MTK_M4U_DOM_ID(0, 1, 6)
+#define M4U_PORT_L1_DISP_FAKE1 MTK_M4U_DOM_ID(0, 1, 7)
+
+/* larb2 */
+#define M4U_PORT_L2_MDP_RDMA0 MTK_M4U_DOM_ID(2, 2, 0)
+#define M4U_PORT_L2_MDP_RDMA1 MTK_M4U_DOM_ID(2, 2, 1)
+#define M4U_PORT_L2_MDP_WROT0 MTK_M4U_DOM_ID(2, 2, 2)
+#define M4U_PORT_L2_MDP_WROT1 MTK_M4U_DOM_ID(2, 2, 3)
+#define M4U_PORT_L2_MDP_DISP_FAKE0 MTK_M4U_DOM_ID(2, 2, 4)
+
+/* larb3: null */
+
+/* larb4 */
+#define M4U_PORT_L4_VDEC_MC_EXT MTK_M4U_DOM_ID(1, 4, 0)
+#define M4U_PORT_L4_VDEC_UFO_EXT MTK_M4U_DOM_ID(1, 4, 1)
+#define M4U_PORT_L4_VDEC_PP_EXT MTK_M4U_DOM_ID(1, 4, 2)
+#define M4U_PORT_L4_VDEC_PRED_RD_EXT MTK_M4U_DOM_ID(1, 4, 3)
+#define M4U_PORT_L4_VDEC_PRED_WR_EXT MTK_M4U_DOM_ID(1, 4, 4)
+#define M4U_PORT_L4_VDEC_PPWRAP_EXT MTK_M4U_DOM_ID(1, 4, 5)
+#define M4U_PORT_L4_VDEC_TILE_EXT MTK_M4U_DOM_ID(1, 4, 6)
+#define M4U_PORT_L4_VDEC_VLD_EXT MTK_M4U_DOM_ID(1, 4, 7)
+#define M4U_PORT_L4_VDEC_VLD2_EXT MTK_M4U_DOM_ID(1, 4, 8)
+#define M4U_PORT_L4_VDEC_AVC_MV_EXT MTK_M4U_DOM_ID(1, 4, 9)
+#define M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT MTK_M4U_DOM_ID(1, 4, 10)
+
+/* larb5 */
+#define M4U_PORT_L5_VDEC_LAT0_VLD_EXT MTK_M4U_DOM_ID(1, 5, 0)
+#define M4U_PORT_L5_VDEC_LAT0_VLD2_EXT MTK_M4U_DOM_ID(1, 5, 1)
+#define M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT MTK_M4U_DOM_ID(1, 5, 2)
+#define M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT MTK_M4U_DOM_ID(1, 5, 3)
+#define M4U_PORT_L5_VDEC_LAT0_TILE_EXT MTK_M4U_DOM_ID(1, 5, 4)
+#define M4U_PORT_L5_VDEC_LAT0_WDMA_EXT MTK_M4U_DOM_ID(1, 5, 5)
+#define M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT MTK_M4U_DOM_ID(1, 5, 6)
+#define M4U_PORT_L5_VDEC_UFO_ENC_EXT MTK_M4U_DOM_ID(1, 5, 7)
+
+/* larb6: null */
+
+/* larb7 */
+#define M4U_PORT_L7_VENC_RCPU MTK_M4U_DOM_ID(1, 7, 0)
+#define M4U_PORT_L7_VENC_REC MTK_M4U_DOM_ID(1, 7, 1)
+#define M4U_PORT_L7_VENC_BSDMA MTK_M4U_DOM_ID(1, 7, 2)
+#define M4U_PORT_L7_VENC_SV_COMV MTK_M4U_DOM_ID(1, 7, 3)
+#define M4U_PORT_L7_VENC_RD_COMV MTK_M4U_DOM_ID(1, 7, 4)
+#define M4U_PORT_L7_VENC_CUR_LUMA MTK_M4U_DOM_ID(1, 7, 5)
+#define M4U_PORT_L7_VENC_CUR_CHROMA MTK_M4U_DOM_ID(1, 7, 6)
+#define M4U_PORT_L7_VENC_REF_LUMA MTK_M4U_DOM_ID(1, 7, 7)
+#define M4U_PORT_L7_VENC_REF_CHROMA MTK_M4U_DOM_ID(1, 7, 8)
+#define M4U_PORT_L7_JPGENC_Y_RDMA MTK_M4U_DOM_ID(1, 7, 9)
+#define M4U_PORT_L7_JPGENC_Q_RDMA MTK_M4U_DOM_ID(1, 7, 10)
+#define M4U_PORT_L7_JPGENC_C_TABLE MTK_M4U_DOM_ID(1, 7, 11)
+#define M4U_PORT_L7_JPGENC_BSDMA MTK_M4U_DOM_ID(1, 7, 12)
+#define M4U_PORT_L7_VENC_SUB_R_LUMA MTK_M4U_DOM_ID(1, 7, 13)
+#define M4U_PORT_L7_VENC_SUB_W_LUMA MTK_M4U_DOM_ID(1, 7, 14)
+
+/* larb8: null */
+
+/* larb9 */
+#define M4U_PORT_L9_IMG_IMGI_D1 MTK_M4U_DOM_ID(2, 9, 0)
+#define M4U_PORT_L9_IMG_IMGBI_D1 MTK_M4U_DOM_ID(2, 9, 1)
+#define M4U_PORT_L9_IMG_DMGI_D1 MTK_M4U_DOM_ID(2, 9, 2)
+#define M4U_PORT_L9_IMG_DEPI_D1 MTK_M4U_DOM_ID(2, 9, 3)
+#define M4U_PORT_L9_IMG_ICE_D1 MTK_M4U_DOM_ID(2, 9, 4)
+#define M4U_PORT_L9_IMG_SMTI_D1 MTK_M4U_DOM_ID(2, 9, 5)
+#define M4U_PORT_L9_IMG_SMTO_D2 MTK_M4U_DOM_ID(2, 9, 6)
+#define M4U_PORT_L9_IMG_SMTO_D1 MTK_M4U_DOM_ID(2, 9, 7)
+#define M4U_PORT_L9_IMG_CRZO_D1 MTK_M4U_DOM_ID(2, 9, 8)
+#define M4U_PORT_L9_IMG_IMG3O_D1 MTK_M4U_DOM_ID(2, 9, 9)
+#define M4U_PORT_L9_IMG_VIPI_D1 MTK_M4U_DOM_ID(2, 9, 10)
+#define M4U_PORT_L9_IMG_SMTI_D5 MTK_M4U_DOM_ID(2, 9, 11)
+#define M4U_PORT_L9_IMG_TIMGO_D1 MTK_M4U_DOM_ID(2, 9, 12)
+#define M4U_PORT_L9_IMG_UFBC_W0 MTK_M4U_DOM_ID(2, 9, 13)
+#define M4U_PORT_L9_IMG_UFBC_R0 MTK_M4U_DOM_ID(2, 9, 14)
+
+/* larb10: null */
+
+/* larb11 */
+#define M4U_PORT_L11_IMG_IMGI_D1 MTK_M4U_DOM_ID(2, 11, 0)
+#define M4U_PORT_L11_IMG_IMGBI_D1 MTK_M4U_DOM_ID(2, 11, 1)
+#define M4U_PORT_L11_IMG_DMGI_D1 MTK_M4U_DOM_ID(2, 11, 2)
+#define M4U_PORT_L11_IMG_DEPI_D1 MTK_M4U_DOM_ID(2, 11, 3)
+#define M4U_PORT_L11_IMG_ICE_D1 MTK_M4U_DOM_ID(2, 11, 4)
+#define M4U_PORT_L11_IMG_SMTI_D1 MTK_M4U_DOM_ID(2, 11, 5)
+#define M4U_PORT_L11_IMG_SMTO_D2 MTK_M4U_DOM_ID(2, 11, 6)
+#define M4U_PORT_L11_IMG_SMTO_D1 MTK_M4U_DOM_ID(2, 11, 7)
+#define M4U_PORT_L11_IMG_CRZO_D1 MTK_M4U_DOM_ID(2, 11, 8)
+#define M4U_PORT_L11_IMG_IMG3O_D1 MTK_M4U_DOM_ID(2, 11, 9)
+#define M4U_PORT_L11_IMG_VIPI_D1 MTK_M4U_DOM_ID(2, 11, 10)
+#define M4U_PORT_L11_IMG_SMTI_D5 MTK_M4U_DOM_ID(2, 11, 11)
+#define M4U_PORT_L11_IMG_TIMGO_D1 MTK_M4U_DOM_ID(2, 11, 12)
+#define M4U_PORT_L11_IMG_UFBC_W0 MTK_M4U_DOM_ID(2, 11, 13)
+#define M4U_PORT_L11_IMG_UFBC_R0 MTK_M4U_DOM_ID(2, 11, 14)
+#define M4U_PORT_L11_IMG_WPE_RDMA1 MTK_M4U_DOM_ID(2, 11, 15)
+#define M4U_PORT_L11_IMG_WPE_RDMA0 MTK_M4U_DOM_ID(2, 11, 16)
+#define M4U_PORT_L11_IMG_WPE_WDMA MTK_M4U_DOM_ID(2, 11, 17)
+#define M4U_PORT_L11_IMG_MFB_RDMA0 MTK_M4U_DOM_ID(2, 11, 18)
+#define M4U_PORT_L11_IMG_MFB_RDMA1 MTK_M4U_DOM_ID(2, 11, 19)
+#define M4U_PORT_L11_IMG_MFB_RDMA2 MTK_M4U_DOM_ID(2, 11, 20)
+#define M4U_PORT_L11_IMG_MFB_RDMA3 MTK_M4U_DOM_ID(2, 11, 21)
+#define M4U_PORT_L11_IMG_MFB_RDMA4 MTK_M4U_DOM_ID(2, 11, 22)
+#define M4U_PORT_L11_IMG_MFB_RDMA5 MTK_M4U_DOM_ID(2, 11, 23)
+#define M4U_PORT_L11_IMG_MFB_WDMA0 MTK_M4U_DOM_ID(2, 11, 24)
+#define M4U_PORT_L11_IMG_MFB_WDMA1 MTK_M4U_DOM_ID(2, 11, 25)
+
+/* larb12: null */
+
+/* larb13 */
+#define M4U_PORT_L13_CAM_MRAWI MTK_M4U_DOM_ID(2, 13, 0)
+#define M4U_PORT_L13_CAM_MRAWO0 MTK_M4U_DOM_ID(2, 13, 1)
+#define M4U_PORT_L13_CAM_MRAWO1 MTK_M4U_DOM_ID(2, 13, 2)
+#define M4U_PORT_L13_CAM_CAMSV1 MTK_M4U_DOM_ID(2, 13, 3)
+#define M4U_PORT_L13_CAM_CAMSV2 MTK_M4U_DOM_ID(2, 13, 4)
+#define M4U_PORT_L13_CAM_CAMSV3 MTK_M4U_DOM_ID(2, 13, 5)
+#define M4U_PORT_L13_CAM_CAMSV4 MTK_M4U_DOM_ID(2, 13, 6)
+#define M4U_PORT_L13_CAM_CAMSV5 MTK_M4U_DOM_ID(2, 13, 7)
+#define M4U_PORT_L13_CAM_CAMSV6 MTK_M4U_DOM_ID(2, 13, 8)
+#define M4U_PORT_L13_CAM_CCUI MTK_M4U_DOM_ID(3, 13, 9)
+#define M4U_PORT_L13_CAM_CCUO MTK_M4U_DOM_ID(3, 13, 10)
+#define M4U_PORT_L13_CAM_FAKE MTK_M4U_DOM_ID(2, 13, 11)
+
+/* larb14 */
+#define M4U_PORT_L14_CAM_RESERVE1 MTK_M4U_DOM_ID(2, 14, 0)
+#define M4U_PORT_L14_CAM_RESERVE2 MTK_M4U_DOM_ID(2, 14, 1)
+#define M4U_PORT_L14_CAM_RESERVE3 MTK_M4U_DOM_ID(2, 14, 2)
+#define M4U_PORT_L14_CAM_CAMSV0 MTK_M4U_DOM_ID(2, 14, 3)
+#define M4U_PORT_L14_CAM_CCUI MTK_M4U_DOM_ID(4, 14, 4)
+#define M4U_PORT_L14_CAM_CCUO MTK_M4U_DOM_ID(4, 14, 5)
+
+/* larb15: null */
+
+/* larb16 */
+#define M4U_PORT_L16_CAM_IMGO_R1_A MTK_M4U_DOM_ID(2, 16, 0)
+#define M4U_PORT_L16_CAM_RRZO_R1_A MTK_M4U_DOM_ID(2, 16, 1)
+#define M4U_PORT_L16_CAM_CQI_R1_A MTK_M4U_DOM_ID(2, 16, 2)
+#define M4U_PORT_L16_CAM_BPCI_R1_A MTK_M4U_DOM_ID(2, 16, 3)
+#define M4U_PORT_L16_CAM_YUVO_R1_A MTK_M4U_DOM_ID(2, 16, 4)
+#define M4U_PORT_L16_CAM_UFDI_R2_A MTK_M4U_DOM_ID(2, 16, 5)
+#define M4U_PORT_L16_CAM_RAWI_R2_A MTK_M4U_DOM_ID(2, 16, 6)
+#define M4U_PORT_L16_CAM_RAWI_R3_A MTK_M4U_DOM_ID(2, 16, 7)
+#define M4U_PORT_L16_CAM_AAO_R1_A MTK_M4U_DOM_ID(2, 16, 8)
+#define M4U_PORT_L16_CAM_AFO_R1_A MTK_M4U_DOM_ID(2, 16, 9)
+#define M4U_PORT_L16_CAM_FLKO_R1_A MTK_M4U_DOM_ID(2, 16, 10)
+#define M4U_PORT_L16_CAM_LCESO_R1_A MTK_M4U_DOM_ID(2, 16, 11)
+#define M4U_PORT_L16_CAM_CRZO_R1_A MTK_M4U_DOM_ID(2, 16, 12)
+#define M4U_PORT_L16_CAM_LTMSO_R1_A MTK_M4U_DOM_ID(2, 16, 13)
+#define M4U_PORT_L16_CAM_RSSO_R1_A MTK_M4U_DOM_ID(2, 16, 14)
+#define M4U_PORT_L16_CAM_AAHO_R1_A MTK_M4U_DOM_ID(2, 16, 15)
+#define M4U_PORT_L16_CAM_LSCI_R1_A MTK_M4U_DOM_ID(2, 16, 16)
+
+/* larb17 */
+#define M4U_PORT_L17_CAM_IMGO_R1_B MTK_M4U_DOM_ID(2, 17, 0)
+#define M4U_PORT_L17_CAM_RRZO_R1_B MTK_M4U_DOM_ID(2, 17, 1)
+#define M4U_PORT_L17_CAM_CQI_R1_B MTK_M4U_DOM_ID(2, 17, 2)
+#define M4U_PORT_L17_CAM_BPCI_R1_B MTK_M4U_DOM_ID(2, 17, 3)
+#define M4U_PORT_L17_CAM_YUVO_R1_B MTK_M4U_DOM_ID(2, 17, 4)
+#define M4U_PORT_L17_CAM_UFDI_R2_B MTK_M4U_DOM_ID(2, 17, 5)
+#define M4U_PORT_L17_CAM_RAWI_R2_B MTK_M4U_DOM_ID(2, 17, 6)
+#define M4U_PORT_L17_CAM_RAWI_R3_B MTK_M4U_DOM_ID(2, 17, 7)
+#define M4U_PORT_L17_CAM_AAO_R1_B MTK_M4U_DOM_ID(2, 17, 8)
+#define M4U_PORT_L17_CAM_AFO_R1_B MTK_M4U_DOM_ID(2, 17, 9)
+#define M4U_PORT_L17_CAM_FLKO_R1_B MTK_M4U_DOM_ID(2, 17, 10)
+#define M4U_PORT_L17_CAM_LCESO_R1_B MTK_M4U_DOM_ID(2, 17, 11)
+#define M4U_PORT_L17_CAM_CRZO_R1_B MTK_M4U_DOM_ID(2, 17, 12)
+#define M4U_PORT_L17_CAM_LTMSO_R1_B MTK_M4U_DOM_ID(2, 17, 13)
+#define M4U_PORT_L17_CAM_RSSO_R1_B MTK_M4U_DOM_ID(2, 17, 14)
+#define M4U_PORT_L17_CAM_AAHO_R1_B MTK_M4U_DOM_ID(2, 17, 15)
+#define M4U_PORT_L17_CAM_LSCI_R1_B MTK_M4U_DOM_ID(2, 17, 16)
+
+/* larb18 */
+#define M4U_PORT_L18_CAM_IMGO_R1_C MTK_M4U_DOM_ID(2, 18, 0)
+#define M4U_PORT_L18_CAM_RRZO_R1_C MTK_M4U_DOM_ID(2, 18, 1)
+#define M4U_PORT_L18_CAM_CQI_R1_C MTK_M4U_DOM_ID(2, 18, 2)
+#define M4U_PORT_L18_CAM_BPCI_R1_C MTK_M4U_DOM_ID(2, 18, 3)
+#define M4U_PORT_L18_CAM_YUVO_R1_C MTK_M4U_DOM_ID(2, 18, 4)
+#define M4U_PORT_L18_CAM_UFDI_R2_C MTK_M4U_DOM_ID(2, 18, 5)
+#define M4U_PORT_L18_CAM_RAWI_R2_C MTK_M4U_DOM_ID(2, 18, 6)
+#define M4U_PORT_L18_CAM_RAWI_R3_C MTK_M4U_DOM_ID(2, 18, 7)
+#define M4U_PORT_L18_CAM_AAO_R1_C MTK_M4U_DOM_ID(2, 18, 8)
+#define M4U_PORT_L18_CAM_AFO_R1_C MTK_M4U_DOM_ID(2, 18, 9)
+#define M4U_PORT_L18_CAM_FLKO_R1_C MTK_M4U_DOM_ID(2, 18, 10)
+#define M4U_PORT_L18_CAM_LCESO_R1_C MTK_M4U_DOM_ID(2, 18, 11)
+#define M4U_PORT_L18_CAM_CRZO_R1_C MTK_M4U_DOM_ID(2, 18, 12)
+#define M4U_PORT_L18_CAM_LTMSO_R1_C MTK_M4U_DOM_ID(2, 18, 13)
+#define M4U_PORT_L18_CAM_RSSO_R1_C MTK_M4U_DOM_ID(2, 18, 14)
+#define M4U_PORT_L18_CAM_AAHO_R1_C MTK_M4U_DOM_ID(2, 18, 15)
+#define M4U_PORT_L18_CAM_LSCI_R1_C MTK_M4U_DOM_ID(2, 18, 16)
+
+/* larb19 */
+#define M4U_PORT_L19_IPE_DVS_RDMA MTK_M4U_DOM_ID(2, 19, 0)
+#define M4U_PORT_L19_IPE_DVS_WDMA MTK_M4U_DOM_ID(2, 19, 1)
+#define M4U_PORT_L19_IPE_DVP_RDMA MTK_M4U_DOM_ID(2, 19, 2)
+#define M4U_PORT_L19_IPE_DVP_WDMA MTK_M4U_DOM_ID(2, 19, 3)
+
+/* larb20 */
+#define M4U_PORT_L20_IPE_FDVT_RDA MTK_M4U_DOM_ID(2, 20, 0)
+#define M4U_PORT_L20_IPE_FDVT_RDB MTK_M4U_DOM_ID(2, 20, 1)
+#define M4U_PORT_L20_IPE_FDVT_WRA MTK_M4U_DOM_ID(2, 20, 2)
+#define M4U_PORT_L20_IPE_FDVT_WRB MTK_M4U_DOM_ID(2, 20, 3)
+#define M4U_PORT_L20_IPE_RSC_RDMA0 MTK_M4U_DOM_ID(2, 20, 4)
+#define M4U_PORT_L20_IPE_RSC_WDMA MTK_M4U_DOM_ID(2, 20, 5)
+
+#endif
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2020-12-09 8:00 ` [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU Yong Wu
@ 2020-12-09 12:13 ` Krzysztof Kozlowski
2020-12-23 8:18 ` Tomasz Figa
1 sibling, 0 replies; 56+ messages in thread
From: Krzysztof Kozlowski @ 2020-12-09 12:13 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, Will Deacon, linux-kernel, Evan Green, Tomasz Figa,
iommu, Rob Herring, linux-mediatek, Matthias Brugger, anan.sun,
Robin Murphy, linux-arm-kernel
On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> This patch adds decriptions for mt8192 IOMMU and SMI.
>
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
>
> EMI
> |
> M4U
> |
> ------------
> SMI Common
> ------------
> |
> +-------+------+------+----------------------+-------+
> | | | | ...... | |
> | | | | | |
> larb0 larb1 larb2 larb4 ...... larb19 larb20
> disp0 disp1 mdp vdec IPE IPE
>
> All the connections are HW fixed, SW can NOT adjust it.
>
> mt8192 M4U support 0~16GB iova range. we preassign different engines
> into different iova ranges:
>
> domain-id module iova-range larbs
> 0 disp 0 ~ 4G larb0/1
> 1 vcodec 4G ~ 8G larb4/5/7
> 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
>
> The iova range for CCU0/1(camera control unit) is HW requirement.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> 2 files changed, 257 insertions(+), 1 deletion(-)
> create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2020-12-09 8:00 ` [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU Yong Wu
2020-12-09 12:13 ` Krzysztof Kozlowski
@ 2020-12-23 8:18 ` Tomasz Figa
2020-12-24 11:35 ` Yong Wu
1 sibling, 1 reply; 56+ messages in thread
From: Tomasz Figa @ 2020-12-23 8:18 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> This patch adds decriptions for mt8192 IOMMU and SMI.
>
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
>
> EMI
> |
> M4U
> |
> ------------
> SMI Common
> ------------
> |
> +-------+------+------+----------------------+-------+
> | | | | ...... | |
> | | | | | |
> larb0 larb1 larb2 larb4 ...... larb19 larb20
> disp0 disp1 mdp vdec IPE IPE
>
> All the connections are HW fixed, SW can NOT adjust it.
>
> mt8192 M4U support 0~16GB iova range. we preassign different engines
> into different iova ranges:
>
> domain-id module iova-range larbs
> 0 disp 0 ~ 4G larb0/1
> 1 vcodec 4G ~ 8G larb4/5/7
> 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
Why do we preassign these addresses in DT? Shouldn't it be a user's or
integrator's decision to split the 16 GB address range into sub-ranges
and define which larbs those sub-ranges are shared with?
Best regards,
Tomasz
> 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
>
> The iova range for CCU0/1(camera control unit) is HW requirement.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> 2 files changed, 257 insertions(+), 1 deletion(-)
> create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
>
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> index ba6626347381..0f26fe14c8e2 100644
> --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> @@ -76,6 +76,7 @@ properties:
> - mediatek,mt8167-m4u # generation two
> - mediatek,mt8173-m4u # generation two
> - mediatek,mt8183-m4u # generation two
> + - mediatek,mt8192-m4u # generation two
>
> - description: mt7623 generation one
> items:
> @@ -115,7 +116,11 @@ properties:
> dt-binding/memory/mt6779-larb-port.h for mt6779,
> 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.
> + dt-binding/memory/mt8183-larb-port.h for mt8183,
> + dt-binding/memory/mt8192-larb-port.h for mt8192.
> +
> + power-domains:
> + maxItems: 1
>
> required:
> - compatible
> @@ -133,11 +138,22 @@ allOf:
> - mediatek,mt2701-m4u
> - mediatek,mt2712-m4u
> - mediatek,mt8173-m4u
> + - mediatek,mt8192-m4u
>
> then:
> required:
> - clocks
>
> + - if:
> + properties:
> + compatible:
> + enum:
> + - mediatek,mt8192-m4u
> +
> + then:
> + required:
> + - power-domains
> +
> additionalProperties: false
>
> examples:
> diff --git a/include/dt-bindings/memory/mt8192-larb-port.h b/include/dt-bindings/memory/mt8192-larb-port.h
> new file mode 100644
> index 000000000000..ec1ac2ba7094
> --- /dev/null
> +++ b/include/dt-bindings/memory/mt8192-larb-port.h
> @@ -0,0 +1,240 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + *
> + * Author: Chao Hao <chao.hao@mediatek.com>
> + * Author: Yong Wu <yong.wu@mediatek.com>
> + */
> +#ifndef _DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_
> +#define _DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_
> +
> +#include <dt-bindings/memory/mtk-smi-larb-port.h>
> +
> +/*
> + * MM IOMMU:
> + * domain 0: display: larb0, larb1.
> + * domain 1: vcodec: larb4, larb5, larb7.
> + * domain 2: CAM/MDP: larb2, larb9, larb11, larb13, larb14, larb16,
> + * larb17, larb18, larb19, larb20,
> + * domain 3: CCU0: larb13 - port9/10.
> + * domain 4: CCU1: larb14 - port4/5.
> + *
> + * larb3/6/8/10/12/15 is null.
> + */
> +
> +/* larb0 */
> +#define M4U_PORT_L0_DISP_POSTMASK0 MTK_M4U_DOM_ID(0, 0, 0)
> +#define M4U_PORT_L0_OVL_RDMA0_HDR MTK_M4U_DOM_ID(0, 0, 1)
> +#define M4U_PORT_L0_OVL_RDMA0 MTK_M4U_DOM_ID(0, 0, 2)
> +#define M4U_PORT_L0_DISP_RDMA0 MTK_M4U_DOM_ID(0, 0, 3)
> +#define M4U_PORT_L0_DISP_WDMA0 MTK_M4U_DOM_ID(0, 0, 4)
> +#define M4U_PORT_L0_DISP_FAKE0 MTK_M4U_DOM_ID(0, 0, 5)
> +
> +/* larb1 */
> +#define M4U_PORT_L1_OVL_2L_RDMA0_HDR MTK_M4U_DOM_ID(0, 1, 0)
> +#define M4U_PORT_L1_OVL_2L_RDMA2_HDR MTK_M4U_DOM_ID(0, 1, 1)
> +#define M4U_PORT_L1_OVL_2L_RDMA0 MTK_M4U_DOM_ID(0, 1, 2)
> +#define M4U_PORT_L1_OVL_2L_RDMA2 MTK_M4U_DOM_ID(0, 1, 3)
> +#define M4U_PORT_L1_DISP_MDP_RDMA4 MTK_M4U_DOM_ID(0, 1, 4)
> +#define M4U_PORT_L1_DISP_RDMA4 MTK_M4U_DOM_ID(0, 1, 5)
> +#define M4U_PORT_L1_DISP_UFBC_WDMA0 MTK_M4U_DOM_ID(0, 1, 6)
> +#define M4U_PORT_L1_DISP_FAKE1 MTK_M4U_DOM_ID(0, 1, 7)
> +
> +/* larb2 */
> +#define M4U_PORT_L2_MDP_RDMA0 MTK_M4U_DOM_ID(2, 2, 0)
> +#define M4U_PORT_L2_MDP_RDMA1 MTK_M4U_DOM_ID(2, 2, 1)
> +#define M4U_PORT_L2_MDP_WROT0 MTK_M4U_DOM_ID(2, 2, 2)
> +#define M4U_PORT_L2_MDP_WROT1 MTK_M4U_DOM_ID(2, 2, 3)
> +#define M4U_PORT_L2_MDP_DISP_FAKE0 MTK_M4U_DOM_ID(2, 2, 4)
> +
> +/* larb3: null */
> +
> +/* larb4 */
> +#define M4U_PORT_L4_VDEC_MC_EXT MTK_M4U_DOM_ID(1, 4, 0)
> +#define M4U_PORT_L4_VDEC_UFO_EXT MTK_M4U_DOM_ID(1, 4, 1)
> +#define M4U_PORT_L4_VDEC_PP_EXT MTK_M4U_DOM_ID(1, 4, 2)
> +#define M4U_PORT_L4_VDEC_PRED_RD_EXT MTK_M4U_DOM_ID(1, 4, 3)
> +#define M4U_PORT_L4_VDEC_PRED_WR_EXT MTK_M4U_DOM_ID(1, 4, 4)
> +#define M4U_PORT_L4_VDEC_PPWRAP_EXT MTK_M4U_DOM_ID(1, 4, 5)
> +#define M4U_PORT_L4_VDEC_TILE_EXT MTK_M4U_DOM_ID(1, 4, 6)
> +#define M4U_PORT_L4_VDEC_VLD_EXT MTK_M4U_DOM_ID(1, 4, 7)
> +#define M4U_PORT_L4_VDEC_VLD2_EXT MTK_M4U_DOM_ID(1, 4, 8)
> +#define M4U_PORT_L4_VDEC_AVC_MV_EXT MTK_M4U_DOM_ID(1, 4, 9)
> +#define M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT MTK_M4U_DOM_ID(1, 4, 10)
> +
> +/* larb5 */
> +#define M4U_PORT_L5_VDEC_LAT0_VLD_EXT MTK_M4U_DOM_ID(1, 5, 0)
> +#define M4U_PORT_L5_VDEC_LAT0_VLD2_EXT MTK_M4U_DOM_ID(1, 5, 1)
> +#define M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT MTK_M4U_DOM_ID(1, 5, 2)
> +#define M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT MTK_M4U_DOM_ID(1, 5, 3)
> +#define M4U_PORT_L5_VDEC_LAT0_TILE_EXT MTK_M4U_DOM_ID(1, 5, 4)
> +#define M4U_PORT_L5_VDEC_LAT0_WDMA_EXT MTK_M4U_DOM_ID(1, 5, 5)
> +#define M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT MTK_M4U_DOM_ID(1, 5, 6)
> +#define M4U_PORT_L5_VDEC_UFO_ENC_EXT MTK_M4U_DOM_ID(1, 5, 7)
> +
> +/* larb6: null */
> +
> +/* larb7 */
> +#define M4U_PORT_L7_VENC_RCPU MTK_M4U_DOM_ID(1, 7, 0)
> +#define M4U_PORT_L7_VENC_REC MTK_M4U_DOM_ID(1, 7, 1)
> +#define M4U_PORT_L7_VENC_BSDMA MTK_M4U_DOM_ID(1, 7, 2)
> +#define M4U_PORT_L7_VENC_SV_COMV MTK_M4U_DOM_ID(1, 7, 3)
> +#define M4U_PORT_L7_VENC_RD_COMV MTK_M4U_DOM_ID(1, 7, 4)
> +#define M4U_PORT_L7_VENC_CUR_LUMA MTK_M4U_DOM_ID(1, 7, 5)
> +#define M4U_PORT_L7_VENC_CUR_CHROMA MTK_M4U_DOM_ID(1, 7, 6)
> +#define M4U_PORT_L7_VENC_REF_LUMA MTK_M4U_DOM_ID(1, 7, 7)
> +#define M4U_PORT_L7_VENC_REF_CHROMA MTK_M4U_DOM_ID(1, 7, 8)
> +#define M4U_PORT_L7_JPGENC_Y_RDMA MTK_M4U_DOM_ID(1, 7, 9)
> +#define M4U_PORT_L7_JPGENC_Q_RDMA MTK_M4U_DOM_ID(1, 7, 10)
> +#define M4U_PORT_L7_JPGENC_C_TABLE MTK_M4U_DOM_ID(1, 7, 11)
> +#define M4U_PORT_L7_JPGENC_BSDMA MTK_M4U_DOM_ID(1, 7, 12)
> +#define M4U_PORT_L7_VENC_SUB_R_LUMA MTK_M4U_DOM_ID(1, 7, 13)
> +#define M4U_PORT_L7_VENC_SUB_W_LUMA MTK_M4U_DOM_ID(1, 7, 14)
> +
> +/* larb8: null */
> +
> +/* larb9 */
> +#define M4U_PORT_L9_IMG_IMGI_D1 MTK_M4U_DOM_ID(2, 9, 0)
> +#define M4U_PORT_L9_IMG_IMGBI_D1 MTK_M4U_DOM_ID(2, 9, 1)
> +#define M4U_PORT_L9_IMG_DMGI_D1 MTK_M4U_DOM_ID(2, 9, 2)
> +#define M4U_PORT_L9_IMG_DEPI_D1 MTK_M4U_DOM_ID(2, 9, 3)
> +#define M4U_PORT_L9_IMG_ICE_D1 MTK_M4U_DOM_ID(2, 9, 4)
> +#define M4U_PORT_L9_IMG_SMTI_D1 MTK_M4U_DOM_ID(2, 9, 5)
> +#define M4U_PORT_L9_IMG_SMTO_D2 MTK_M4U_DOM_ID(2, 9, 6)
> +#define M4U_PORT_L9_IMG_SMTO_D1 MTK_M4U_DOM_ID(2, 9, 7)
> +#define M4U_PORT_L9_IMG_CRZO_D1 MTK_M4U_DOM_ID(2, 9, 8)
> +#define M4U_PORT_L9_IMG_IMG3O_D1 MTK_M4U_DOM_ID(2, 9, 9)
> +#define M4U_PORT_L9_IMG_VIPI_D1 MTK_M4U_DOM_ID(2, 9, 10)
> +#define M4U_PORT_L9_IMG_SMTI_D5 MTK_M4U_DOM_ID(2, 9, 11)
> +#define M4U_PORT_L9_IMG_TIMGO_D1 MTK_M4U_DOM_ID(2, 9, 12)
> +#define M4U_PORT_L9_IMG_UFBC_W0 MTK_M4U_DOM_ID(2, 9, 13)
> +#define M4U_PORT_L9_IMG_UFBC_R0 MTK_M4U_DOM_ID(2, 9, 14)
> +
> +/* larb10: null */
> +
> +/* larb11 */
> +#define M4U_PORT_L11_IMG_IMGI_D1 MTK_M4U_DOM_ID(2, 11, 0)
> +#define M4U_PORT_L11_IMG_IMGBI_D1 MTK_M4U_DOM_ID(2, 11, 1)
> +#define M4U_PORT_L11_IMG_DMGI_D1 MTK_M4U_DOM_ID(2, 11, 2)
> +#define M4U_PORT_L11_IMG_DEPI_D1 MTK_M4U_DOM_ID(2, 11, 3)
> +#define M4U_PORT_L11_IMG_ICE_D1 MTK_M4U_DOM_ID(2, 11, 4)
> +#define M4U_PORT_L11_IMG_SMTI_D1 MTK_M4U_DOM_ID(2, 11, 5)
> +#define M4U_PORT_L11_IMG_SMTO_D2 MTK_M4U_DOM_ID(2, 11, 6)
> +#define M4U_PORT_L11_IMG_SMTO_D1 MTK_M4U_DOM_ID(2, 11, 7)
> +#define M4U_PORT_L11_IMG_CRZO_D1 MTK_M4U_DOM_ID(2, 11, 8)
> +#define M4U_PORT_L11_IMG_IMG3O_D1 MTK_M4U_DOM_ID(2, 11, 9)
> +#define M4U_PORT_L11_IMG_VIPI_D1 MTK_M4U_DOM_ID(2, 11, 10)
> +#define M4U_PORT_L11_IMG_SMTI_D5 MTK_M4U_DOM_ID(2, 11, 11)
> +#define M4U_PORT_L11_IMG_TIMGO_D1 MTK_M4U_DOM_ID(2, 11, 12)
> +#define M4U_PORT_L11_IMG_UFBC_W0 MTK_M4U_DOM_ID(2, 11, 13)
> +#define M4U_PORT_L11_IMG_UFBC_R0 MTK_M4U_DOM_ID(2, 11, 14)
> +#define M4U_PORT_L11_IMG_WPE_RDMA1 MTK_M4U_DOM_ID(2, 11, 15)
> +#define M4U_PORT_L11_IMG_WPE_RDMA0 MTK_M4U_DOM_ID(2, 11, 16)
> +#define M4U_PORT_L11_IMG_WPE_WDMA MTK_M4U_DOM_ID(2, 11, 17)
> +#define M4U_PORT_L11_IMG_MFB_RDMA0 MTK_M4U_DOM_ID(2, 11, 18)
> +#define M4U_PORT_L11_IMG_MFB_RDMA1 MTK_M4U_DOM_ID(2, 11, 19)
> +#define M4U_PORT_L11_IMG_MFB_RDMA2 MTK_M4U_DOM_ID(2, 11, 20)
> +#define M4U_PORT_L11_IMG_MFB_RDMA3 MTK_M4U_DOM_ID(2, 11, 21)
> +#define M4U_PORT_L11_IMG_MFB_RDMA4 MTK_M4U_DOM_ID(2, 11, 22)
> +#define M4U_PORT_L11_IMG_MFB_RDMA5 MTK_M4U_DOM_ID(2, 11, 23)
> +#define M4U_PORT_L11_IMG_MFB_WDMA0 MTK_M4U_DOM_ID(2, 11, 24)
> +#define M4U_PORT_L11_IMG_MFB_WDMA1 MTK_M4U_DOM_ID(2, 11, 25)
> +
> +/* larb12: null */
> +
> +/* larb13 */
> +#define M4U_PORT_L13_CAM_MRAWI MTK_M4U_DOM_ID(2, 13, 0)
> +#define M4U_PORT_L13_CAM_MRAWO0 MTK_M4U_DOM_ID(2, 13, 1)
> +#define M4U_PORT_L13_CAM_MRAWO1 MTK_M4U_DOM_ID(2, 13, 2)
> +#define M4U_PORT_L13_CAM_CAMSV1 MTK_M4U_DOM_ID(2, 13, 3)
> +#define M4U_PORT_L13_CAM_CAMSV2 MTK_M4U_DOM_ID(2, 13, 4)
> +#define M4U_PORT_L13_CAM_CAMSV3 MTK_M4U_DOM_ID(2, 13, 5)
> +#define M4U_PORT_L13_CAM_CAMSV4 MTK_M4U_DOM_ID(2, 13, 6)
> +#define M4U_PORT_L13_CAM_CAMSV5 MTK_M4U_DOM_ID(2, 13, 7)
> +#define M4U_PORT_L13_CAM_CAMSV6 MTK_M4U_DOM_ID(2, 13, 8)
> +#define M4U_PORT_L13_CAM_CCUI MTK_M4U_DOM_ID(3, 13, 9)
> +#define M4U_PORT_L13_CAM_CCUO MTK_M4U_DOM_ID(3, 13, 10)
> +#define M4U_PORT_L13_CAM_FAKE MTK_M4U_DOM_ID(2, 13, 11)
> +
> +/* larb14 */
> +#define M4U_PORT_L14_CAM_RESERVE1 MTK_M4U_DOM_ID(2, 14, 0)
> +#define M4U_PORT_L14_CAM_RESERVE2 MTK_M4U_DOM_ID(2, 14, 1)
> +#define M4U_PORT_L14_CAM_RESERVE3 MTK_M4U_DOM_ID(2, 14, 2)
> +#define M4U_PORT_L14_CAM_CAMSV0 MTK_M4U_DOM_ID(2, 14, 3)
> +#define M4U_PORT_L14_CAM_CCUI MTK_M4U_DOM_ID(4, 14, 4)
> +#define M4U_PORT_L14_CAM_CCUO MTK_M4U_DOM_ID(4, 14, 5)
> +
> +/* larb15: null */
> +
> +/* larb16 */
> +#define M4U_PORT_L16_CAM_IMGO_R1_A MTK_M4U_DOM_ID(2, 16, 0)
> +#define M4U_PORT_L16_CAM_RRZO_R1_A MTK_M4U_DOM_ID(2, 16, 1)
> +#define M4U_PORT_L16_CAM_CQI_R1_A MTK_M4U_DOM_ID(2, 16, 2)
> +#define M4U_PORT_L16_CAM_BPCI_R1_A MTK_M4U_DOM_ID(2, 16, 3)
> +#define M4U_PORT_L16_CAM_YUVO_R1_A MTK_M4U_DOM_ID(2, 16, 4)
> +#define M4U_PORT_L16_CAM_UFDI_R2_A MTK_M4U_DOM_ID(2, 16, 5)
> +#define M4U_PORT_L16_CAM_RAWI_R2_A MTK_M4U_DOM_ID(2, 16, 6)
> +#define M4U_PORT_L16_CAM_RAWI_R3_A MTK_M4U_DOM_ID(2, 16, 7)
> +#define M4U_PORT_L16_CAM_AAO_R1_A MTK_M4U_DOM_ID(2, 16, 8)
> +#define M4U_PORT_L16_CAM_AFO_R1_A MTK_M4U_DOM_ID(2, 16, 9)
> +#define M4U_PORT_L16_CAM_FLKO_R1_A MTK_M4U_DOM_ID(2, 16, 10)
> +#define M4U_PORT_L16_CAM_LCESO_R1_A MTK_M4U_DOM_ID(2, 16, 11)
> +#define M4U_PORT_L16_CAM_CRZO_R1_A MTK_M4U_DOM_ID(2, 16, 12)
> +#define M4U_PORT_L16_CAM_LTMSO_R1_A MTK_M4U_DOM_ID(2, 16, 13)
> +#define M4U_PORT_L16_CAM_RSSO_R1_A MTK_M4U_DOM_ID(2, 16, 14)
> +#define M4U_PORT_L16_CAM_AAHO_R1_A MTK_M4U_DOM_ID(2, 16, 15)
> +#define M4U_PORT_L16_CAM_LSCI_R1_A MTK_M4U_DOM_ID(2, 16, 16)
> +
> +/* larb17 */
> +#define M4U_PORT_L17_CAM_IMGO_R1_B MTK_M4U_DOM_ID(2, 17, 0)
> +#define M4U_PORT_L17_CAM_RRZO_R1_B MTK_M4U_DOM_ID(2, 17, 1)
> +#define M4U_PORT_L17_CAM_CQI_R1_B MTK_M4U_DOM_ID(2, 17, 2)
> +#define M4U_PORT_L17_CAM_BPCI_R1_B MTK_M4U_DOM_ID(2, 17, 3)
> +#define M4U_PORT_L17_CAM_YUVO_R1_B MTK_M4U_DOM_ID(2, 17, 4)
> +#define M4U_PORT_L17_CAM_UFDI_R2_B MTK_M4U_DOM_ID(2, 17, 5)
> +#define M4U_PORT_L17_CAM_RAWI_R2_B MTK_M4U_DOM_ID(2, 17, 6)
> +#define M4U_PORT_L17_CAM_RAWI_R3_B MTK_M4U_DOM_ID(2, 17, 7)
> +#define M4U_PORT_L17_CAM_AAO_R1_B MTK_M4U_DOM_ID(2, 17, 8)
> +#define M4U_PORT_L17_CAM_AFO_R1_B MTK_M4U_DOM_ID(2, 17, 9)
> +#define M4U_PORT_L17_CAM_FLKO_R1_B MTK_M4U_DOM_ID(2, 17, 10)
> +#define M4U_PORT_L17_CAM_LCESO_R1_B MTK_M4U_DOM_ID(2, 17, 11)
> +#define M4U_PORT_L17_CAM_CRZO_R1_B MTK_M4U_DOM_ID(2, 17, 12)
> +#define M4U_PORT_L17_CAM_LTMSO_R1_B MTK_M4U_DOM_ID(2, 17, 13)
> +#define M4U_PORT_L17_CAM_RSSO_R1_B MTK_M4U_DOM_ID(2, 17, 14)
> +#define M4U_PORT_L17_CAM_AAHO_R1_B MTK_M4U_DOM_ID(2, 17, 15)
> +#define M4U_PORT_L17_CAM_LSCI_R1_B MTK_M4U_DOM_ID(2, 17, 16)
> +
> +/* larb18 */
> +#define M4U_PORT_L18_CAM_IMGO_R1_C MTK_M4U_DOM_ID(2, 18, 0)
> +#define M4U_PORT_L18_CAM_RRZO_R1_C MTK_M4U_DOM_ID(2, 18, 1)
> +#define M4U_PORT_L18_CAM_CQI_R1_C MTK_M4U_DOM_ID(2, 18, 2)
> +#define M4U_PORT_L18_CAM_BPCI_R1_C MTK_M4U_DOM_ID(2, 18, 3)
> +#define M4U_PORT_L18_CAM_YUVO_R1_C MTK_M4U_DOM_ID(2, 18, 4)
> +#define M4U_PORT_L18_CAM_UFDI_R2_C MTK_M4U_DOM_ID(2, 18, 5)
> +#define M4U_PORT_L18_CAM_RAWI_R2_C MTK_M4U_DOM_ID(2, 18, 6)
> +#define M4U_PORT_L18_CAM_RAWI_R3_C MTK_M4U_DOM_ID(2, 18, 7)
> +#define M4U_PORT_L18_CAM_AAO_R1_C MTK_M4U_DOM_ID(2, 18, 8)
> +#define M4U_PORT_L18_CAM_AFO_R1_C MTK_M4U_DOM_ID(2, 18, 9)
> +#define M4U_PORT_L18_CAM_FLKO_R1_C MTK_M4U_DOM_ID(2, 18, 10)
> +#define M4U_PORT_L18_CAM_LCESO_R1_C MTK_M4U_DOM_ID(2, 18, 11)
> +#define M4U_PORT_L18_CAM_CRZO_R1_C MTK_M4U_DOM_ID(2, 18, 12)
> +#define M4U_PORT_L18_CAM_LTMSO_R1_C MTK_M4U_DOM_ID(2, 18, 13)
> +#define M4U_PORT_L18_CAM_RSSO_R1_C MTK_M4U_DOM_ID(2, 18, 14)
> +#define M4U_PORT_L18_CAM_AAHO_R1_C MTK_M4U_DOM_ID(2, 18, 15)
> +#define M4U_PORT_L18_CAM_LSCI_R1_C MTK_M4U_DOM_ID(2, 18, 16)
> +
> +/* larb19 */
> +#define M4U_PORT_L19_IPE_DVS_RDMA MTK_M4U_DOM_ID(2, 19, 0)
> +#define M4U_PORT_L19_IPE_DVS_WDMA MTK_M4U_DOM_ID(2, 19, 1)
> +#define M4U_PORT_L19_IPE_DVP_RDMA MTK_M4U_DOM_ID(2, 19, 2)
> +#define M4U_PORT_L19_IPE_DVP_WDMA MTK_M4U_DOM_ID(2, 19, 3)
> +
> +/* larb20 */
> +#define M4U_PORT_L20_IPE_FDVT_RDA MTK_M4U_DOM_ID(2, 20, 0)
> +#define M4U_PORT_L20_IPE_FDVT_RDB MTK_M4U_DOM_ID(2, 20, 1)
> +#define M4U_PORT_L20_IPE_FDVT_WRA MTK_M4U_DOM_ID(2, 20, 2)
> +#define M4U_PORT_L20_IPE_FDVT_WRB MTK_M4U_DOM_ID(2, 20, 3)
> +#define M4U_PORT_L20_IPE_RSC_RDMA0 MTK_M4U_DOM_ID(2, 20, 4)
> +#define M4U_PORT_L20_IPE_RSC_WDMA MTK_M4U_DOM_ID(2, 20, 5)
> +
> +#endif
> --
> 2.18.0
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2020-12-23 8:18 ` Tomasz Figa
@ 2020-12-24 11:35 ` Yong Wu
2021-01-13 5:30 ` Tomasz Figa
0 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2020-12-24 11:35 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> > This patch adds decriptions for mt8192 IOMMU and SMI.
> >
> > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > table format. The M4U-SMI HW diagram is as below:
> >
> > EMI
> > |
> > M4U
> > |
> > ------------
> > SMI Common
> > ------------
> > |
> > +-------+------+------+----------------------+-------+
> > | | | | ...... | |
> > | | | | | |
> > larb0 larb1 larb2 larb4 ...... larb19 larb20
> > disp0 disp1 mdp vdec IPE IPE
> >
> > All the connections are HW fixed, SW can NOT adjust it.
> >
> > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > into different iova ranges:
> >
> > domain-id module iova-range larbs
> > 0 disp 0 ~ 4G larb0/1
> > 1 vcodec 4G ~ 8G larb4/5/7
> > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
>
> Why do we preassign these addresses in DT? Shouldn't it be a user's or
> integrator's decision to split the 16 GB address range into sub-ranges
> and define which larbs those sub-ranges are shared with?
The problem is that we can't split the 16GB range with the larb as unit.
The example is the below ccu0(larb13 port9/10) is a independent
range(domain), the others ports in larb13 is in another domain.
disp/vcodec/cam/mdp don't have special iova requirement, they could
access any range. vcodec also can locate 8G~12G. it don't care about
where its iova locate. here I preassign like this following with our
internal project setting.
Why set this in DT?, this is only for simplifying the code. Assume we
put it in the platform data. We have up to 32 larbs, each larb has up to
32 ports, each port may be in different iommu domains. we should have a
big array for this..however we only use a macro to get the domain in the
DT method.
When replying this mail, I happen to see there is a "dev->dev_range_map"
which has "dma-range" information, I think I could use this value to get
which domain the device belong to. then no need put domid in DT. I will
test this.
Thanks.
>
> Best regards,
> Tomasz
>
> > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> >
> > The iova range for CCU0/1(camera control unit) is HW requirement.
> >
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> > .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> > include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> > 2 files changed, 257 insertions(+), 1 deletion(-)
> > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> >
[snip]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2020-12-24 11:35 ` Yong Wu
@ 2021-01-13 5:30 ` Tomasz Figa
2021-01-13 6:45 ` Yong Wu
0 siblings, 1 reply; 56+ messages in thread
From: Tomasz Figa @ 2021-01-13 5:30 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Will Deacon, Linux Kernel Mailing List, Evan Green, chao.hao,
open list:IOMMU DRIVERS, Rob Herring,
moderated list:ARM/Mediatek SoC support, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
On Thu, Dec 24, 2020 at 8:35 PM Yong Wu <yong.wu@mediatek.com> wrote:
>
> On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> > > This patch adds decriptions for mt8192 IOMMU and SMI.
> > >
> > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > > table format. The M4U-SMI HW diagram is as below:
> > >
> > > EMI
> > > |
> > > M4U
> > > |
> > > ------------
> > > SMI Common
> > > ------------
> > > |
> > > +-------+------+------+----------------------+-------+
> > > | | | | ...... | |
> > > | | | | | |
> > > larb0 larb1 larb2 larb4 ...... larb19 larb20
> > > disp0 disp1 mdp vdec IPE IPE
> > >
> > > All the connections are HW fixed, SW can NOT adjust it.
> > >
> > > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > > into different iova ranges:
> > >
> > > domain-id module iova-range larbs
> > > 0 disp 0 ~ 4G larb0/1
> > > 1 vcodec 4G ~ 8G larb4/5/7
> > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> >
> > Why do we preassign these addresses in DT? Shouldn't it be a user's or
> > integrator's decision to split the 16 GB address range into sub-ranges
> > and define which larbs those sub-ranges are shared with?
>
> The problem is that we can't split the 16GB range with the larb as unit.
> The example is the below ccu0(larb13 port9/10) is a independent
> range(domain), the others ports in larb13 is in another domain.
>
> disp/vcodec/cam/mdp don't have special iova requirement, they could
> access any range. vcodec also can locate 8G~12G. it don't care about
> where its iova locate. here I preassign like this following with our
> internal project setting.
Let me try to understand this a bit more. Given the split you're
proposing, is there actually any isolation enforced between particular
domains? For example, if I program vcodec to with a DMA address from
the 0-4G range, would the IOMMU actually generate a fault, even if
disp had some memory mapped at that address?
>
> Why set this in DT?, this is only for simplifying the code. Assume we
> put it in the platform data. We have up to 32 larbs, each larb has up to
> 32 ports, each port may be in different iommu domains. we should have a
> big array for this..however we only use a macro to get the domain in the
> DT method.
>
> When replying this mail, I happen to see there is a "dev->dev_range_map"
> which has "dma-range" information, I think I could use this value to get
> which domain the device belong to. then no need put domid in DT. I will
> test this.
My feeling is that the only part that needs to be enforced statically
is the reserved IOVA range for CCUs. The other ranges should be
determined dynamically, although I think I need to understand better
how the hardware and your proposed design work to tell what would be
likely the best choice here.
Best regards,
Tomasz
>
> Thanks.
> >
> > Best regards,
> > Tomasz
> >
> > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > >
> > > The iova range for CCU0/1(camera control unit) is HW requirement.
> > >
> > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > ---
> > > .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> > > include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> > > 2 files changed, 257 insertions(+), 1 deletion(-)
> > > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> > >
> [snip]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2021-01-13 5:30 ` Tomasz Figa
@ 2021-01-13 6:45 ` Yong Wu
2021-01-20 4:15 ` Tomasz Figa
0 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2021-01-13 6:45 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Will Deacon, Linux Kernel Mailing List, Evan Green, chao.hao,
open list:IOMMU DRIVERS, Rob Herring,
moderated list:ARM/Mediatek SoC support, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote:
> On Thu, Dec 24, 2020 at 8:35 PM Yong Wu <yong.wu@mediatek.com> wrote:
> >
> > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> > > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> > > > This patch adds decriptions for mt8192 IOMMU and SMI.
> > > >
> > > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > > > table format. The M4U-SMI HW diagram is as below:
> > > >
> > > > EMI
> > > > |
> > > > M4U
> > > > |
> > > > ------------
> > > > SMI Common
> > > > ------------
> > > > |
> > > > +-------+------+------+----------------------+-------+
> > > > | | | | ...... | |
> > > > | | | | | |
> > > > larb0 larb1 larb2 larb4 ...... larb19 larb20
> > > > disp0 disp1 mdp vdec IPE IPE
> > > >
> > > > All the connections are HW fixed, SW can NOT adjust it.
> > > >
> > > > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > > > into different iova ranges:
> > > >
> > > > domain-id module iova-range larbs
> > > > 0 disp 0 ~ 4G larb0/1
> > > > 1 vcodec 4G ~ 8G larb4/5/7
> > > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > >
> > > Why do we preassign these addresses in DT? Shouldn't it be a user's or
> > > integrator's decision to split the 16 GB address range into sub-ranges
> > > and define which larbs those sub-ranges are shared with?
> >
> > The problem is that we can't split the 16GB range with the larb as unit.
> > The example is the below ccu0(larb13 port9/10) is a independent
> > range(domain), the others ports in larb13 is in another domain.
> >
> > disp/vcodec/cam/mdp don't have special iova requirement, they could
> > access any range. vcodec also can locate 8G~12G. it don't care about
> > where its iova locate. here I preassign like this following with our
> > internal project setting.
>
> Let me try to understand this a bit more. Given the split you're
> proposing, is there actually any isolation enforced between particular
> domains? For example, if I program vcodec to with a DMA address from
> the 0-4G range, would the IOMMU actually generate a fault, even if
> disp had some memory mapped at that address?
In this case. we will get fault in current SW setting.
>
> >
> > Why set this in DT?, this is only for simplifying the code. Assume we
> > put it in the platform data. We have up to 32 larbs, each larb has up to
> > 32 ports, each port may be in different iommu domains. we should have a
> > big array for this..however we only use a macro to get the domain in the
> > DT method.
> >
> > When replying this mail, I happen to see there is a "dev->dev_range_map"
> > which has "dma-range" information, I think I could use this value to get
> > which domain the device belong to. then no need put domid in DT. I will
> > test this.
>
> My feeling is that the only part that needs to be enforced statically
> is the reserved IOVA range for CCUs. The other ranges should be
> determined dynamically, although I think I need to understand better
> how the hardware and your proposed design work to tell what would be
> likely the best choice here.
I have removed the domid patch in v6. and get the domain id in [27/33]
in v6..
About the other ranges should be dynamical, the commit message [30/33]
of v6 should be helpful. the problem is that we have a bank_sel setting
for the iova[32:33]. currently we preassign this value. thus, all the
ranges are fixed. If you adjust this setting, you can let vcodec access
0~4G.
Currently we have no interface to adjust this setting. Suppose we add a
new interface for this. It would be something like:
int mtk_smi_larb_config_banksel(struct device *larb, int banksel)
Then, all the MM drivers should call it before the HW works every
time, and its implement will be a bit complex since we aren't sure if
the larb has power at that time. the important thing is that the MM
devices have already not known which larb it connects with as we plan to
delete "mediatek,larb" in their dtsi nodes.
In current design, the MM device don't need care about it and 4GB
range is enough for them.
>
> Best regards,
> Tomasz
>
> >
> > Thanks.
> > >
> > > Best regards,
> > > Tomasz
> > >
> > > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > > >
> > > > The iova range for CCU0/1(camera control unit) is HW requirement.
> > > >
> > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > ---
> > > > .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> > > > include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> > > > 2 files changed, 257 insertions(+), 1 deletion(-)
> > > > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> > > >
> > [snip]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2021-01-13 6:45 ` Yong Wu
@ 2021-01-20 4:15 ` Tomasz Figa
2021-01-20 7:07 ` Yong Wu
0 siblings, 1 reply; 56+ messages in thread
From: Tomasz Figa @ 2021-01-20 4:15 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Will Deacon, Linux Kernel Mailing List, Evan Green, chao.hao,
open list:IOMMU DRIVERS, Rob Herring,
moderated list:ARM/Mediatek SoC support, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
On Wed, Jan 13, 2021 at 3:45 PM Yong Wu <yong.wu@mediatek.com> wrote:
>
> On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote:
> > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > >
> > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> > > > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> > > > > This patch adds decriptions for mt8192 IOMMU and SMI.
> > > > >
> > > > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > > > > table format. The M4U-SMI HW diagram is as below:
> > > > >
> > > > > EMI
> > > > > |
> > > > > M4U
> > > > > |
> > > > > ------------
> > > > > SMI Common
> > > > > ------------
> > > > > |
> > > > > +-------+------+------+----------------------+-------+
> > > > > | | | | ...... | |
> > > > > | | | | | |
> > > > > larb0 larb1 larb2 larb4 ...... larb19 larb20
> > > > > disp0 disp1 mdp vdec IPE IPE
> > > > >
> > > > > All the connections are HW fixed, SW can NOT adjust it.
> > > > >
> > > > > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > > > > into different iova ranges:
> > > > >
> > > > > domain-id module iova-range larbs
> > > > > 0 disp 0 ~ 4G larb0/1
> > > > > 1 vcodec 4G ~ 8G larb4/5/7
> > > > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > > >
> > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or
> > > > integrator's decision to split the 16 GB address range into sub-ranges
> > > > and define which larbs those sub-ranges are shared with?
> > >
> > > The problem is that we can't split the 16GB range with the larb as unit.
> > > The example is the below ccu0(larb13 port9/10) is a independent
> > > range(domain), the others ports in larb13 is in another domain.
> > >
> > > disp/vcodec/cam/mdp don't have special iova requirement, they could
> > > access any range. vcodec also can locate 8G~12G. it don't care about
> > > where its iova locate. here I preassign like this following with our
> > > internal project setting.
> >
> > Let me try to understand this a bit more. Given the split you're
> > proposing, is there actually any isolation enforced between particular
> > domains? For example, if I program vcodec to with a DMA address from
> > the 0-4G range, would the IOMMU actually generate a fault, even if
> > disp had some memory mapped at that address?
>
> In this case. we will get fault in current SW setting.
>
Okay, thanks.
> >
> > >
> > > Why set this in DT?, this is only for simplifying the code. Assume we
> > > put it in the platform data. We have up to 32 larbs, each larb has up to
> > > 32 ports, each port may be in different iommu domains. we should have a
> > > big array for this..however we only use a macro to get the domain in the
> > > DT method.
> > >
> > > When replying this mail, I happen to see there is a "dev->dev_range_map"
> > > which has "dma-range" information, I think I could use this value to get
> > > which domain the device belong to. then no need put domid in DT. I will
> > > test this.
> >
> > My feeling is that the only part that needs to be enforced statically
> > is the reserved IOVA range for CCUs. The other ranges should be
> > determined dynamically, although I think I need to understand better
> > how the hardware and your proposed design work to tell what would be
> > likely the best choice here.
>
> I have removed the domid patch in v6. and get the domain id in [27/33]
> in v6..
>
> About the other ranges should be dynamical, the commit message [30/33]
> of v6 should be helpful. the problem is that we have a bank_sel setting
> for the iova[32:33]. currently we preassign this value. thus, all the
> ranges are fixed. If you adjust this setting, you can let vcodec access
> 0~4G.
Okay, so it sounds like we effectively have four 4G address spaces and
we can assign the master devices to them. I guess each of these
address spaces makes for an IOMMU group.
It's fine to pre-assign the devices to those groups for now, but it
definitely shouldn't be hardcoded in DT, because it depends on the use
case of the device. I'll take a look at v6, but it sounds like it
should be fine if it doesn't take the address space assignment from DT
anymore.
>
> Currently we have no interface to adjust this setting. Suppose we add a
> new interface for this. It would be something like:
>
> int mtk_smi_larb_config_banksel(struct device *larb, int banksel)
>
> Then, all the MM drivers should call it before the HW works every
> time, and its implement will be a bit complex since we aren't sure if
> the larb has power at that time. the important thing is that the MM
> devices have already not known which larb it connects with as we plan to
> delete "mediatek,larb" in their dtsi nodes.
From the practical point of view, it doesn't look like setting this on
a per-larb basis would make much sense. The reason to switch the
bank_sel would be to decide which MM devices can share the same
address space. This is a security aspect, because it effectively
determines which devices are isolated from each other.
That said, I agree that for now we can just start with a fixed
assignment. We can think of the API if there is a need to adjust the
assignment.
>
> In current design, the MM device don't need care about it and 4GB
> range is enough for them.
>
Actually, is the current assignment correct?
domain-id module iova-range larbs
0 disp 0 ~ 4G larb0/1
1 vcodec 4G ~ 8G larb4/5/7
2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
Wouldn't CCU0 and CCU1 conflict with disp? Should perhaps disp be
assigned 12G ~ 16G instead?
Best regards,
Tomasz
> >
> > Best regards,
> > Tomasz
> >
> > >
> > > Thanks.
> > > >
> > > > Best regards,
> > > > Tomasz
> > > >
> > > > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > > > >
> > > > > The iova range for CCU0/1(camera control unit) is HW requirement.
> > > > >
> > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > > ---
> > > > > .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> > > > > include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> > > > > 2 files changed, 257 insertions(+), 1 deletion(-)
> > > > > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> > > > >
> > > [snip]
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2021-01-20 4:15 ` Tomasz Figa
@ 2021-01-20 7:07 ` Yong Wu
2021-01-25 4:18 ` Tomasz Figa
0 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2021-01-20 7:07 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Will Deacon, Linux Kernel Mailing List, Evan Green, chao.hao,
open list:IOMMU DRIVERS, Rob Herring,
moderated list:ARM/Mediatek SoC support, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote:
> On Wed, Jan 13, 2021 at 3:45 PM Yong Wu <yong.wu@mediatek.com> wrote:
> >
> > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote:
> > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > > >
> > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> > > > > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> > > > > > This patch adds decriptions for mt8192 IOMMU and SMI.
> > > > > >
> > > > > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > > > > > table format. The M4U-SMI HW diagram is as below:
> > > > > >
> > > > > > EMI
> > > > > > |
> > > > > > M4U
> > > > > > |
> > > > > > ------------
> > > > > > SMI Common
> > > > > > ------------
> > > > > > |
> > > > > > +-------+------+------+----------------------+-------+
> > > > > > | | | | ...... | |
> > > > > > | | | | | |
> > > > > > larb0 larb1 larb2 larb4 ...... larb19 larb20
> > > > > > disp0 disp1 mdp vdec IPE IPE
> > > > > >
> > > > > > All the connections are HW fixed, SW can NOT adjust it.
> > > > > >
> > > > > > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > > > > > into different iova ranges:
> > > > > >
> > > > > > domain-id module iova-range larbs
> > > > > > 0 disp 0 ~ 4G larb0/1
> > > > > > 1 vcodec 4G ~ 8G larb4/5/7
> > > > > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > > > >
> > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or
> > > > > integrator's decision to split the 16 GB address range into sub-ranges
> > > > > and define which larbs those sub-ranges are shared with?
> > > >
> > > > The problem is that we can't split the 16GB range with the larb as unit.
> > > > The example is the below ccu0(larb13 port9/10) is a independent
> > > > range(domain), the others ports in larb13 is in another domain.
> > > >
> > > > disp/vcodec/cam/mdp don't have special iova requirement, they could
> > > > access any range. vcodec also can locate 8G~12G. it don't care about
> > > > where its iova locate. here I preassign like this following with our
> > > > internal project setting.
> > >
> > > Let me try to understand this a bit more. Given the split you're
> > > proposing, is there actually any isolation enforced between particular
> > > domains? For example, if I program vcodec to with a DMA address from
> > > the 0-4G range, would the IOMMU actually generate a fault, even if
> > > disp had some memory mapped at that address?
> >
> > In this case. we will get fault in current SW setting.
> >
>
> Okay, thanks.
>
> > >
> > > >
> > > > Why set this in DT?, this is only for simplifying the code. Assume we
> > > > put it in the platform data. We have up to 32 larbs, each larb has up to
> > > > 32 ports, each port may be in different iommu domains. we should have a
> > > > big array for this..however we only use a macro to get the domain in the
> > > > DT method.
> > > >
> > > > When replying this mail, I happen to see there is a "dev->dev_range_map"
> > > > which has "dma-range" information, I think I could use this value to get
> > > > which domain the device belong to. then no need put domid in DT. I will
> > > > test this.
> > >
> > > My feeling is that the only part that needs to be enforced statically
> > > is the reserved IOVA range for CCUs. The other ranges should be
> > > determined dynamically, although I think I need to understand better
> > > how the hardware and your proposed design work to tell what would be
> > > likely the best choice here.
> >
> > I have removed the domid patch in v6. and get the domain id in [27/33]
> > in v6..
> >
> > About the other ranges should be dynamical, the commit message [30/33]
> > of v6 should be helpful. the problem is that we have a bank_sel setting
> > for the iova[32:33]. currently we preassign this value. thus, all the
> > ranges are fixed. If you adjust this setting, you can let vcodec access
> > 0~4G.
>
> Okay, so it sounds like we effectively have four 4G address spaces and
> we can assign the master devices to them. I guess each of these
> address spaces makes for an IOMMU group.
Yes. Each a address spaces is an IOMMU group.
>
> It's fine to pre-assign the devices to those groups for now, but it
> definitely shouldn't be hardcoded in DT, because it depends on the use
> case of the device. I'll take a look at v6, but it sounds like it
> should be fine if it doesn't take the address space assignment from DT
> anymore.
Thanks very much for your review.
>
> >
> > Currently we have no interface to adjust this setting. Suppose we add a
> > new interface for this. It would be something like:
> >
> > int mtk_smi_larb_config_banksel(struct device *larb, int banksel)
> >
> > Then, all the MM drivers should call it before the HW works every
> > time, and its implement will be a bit complex since we aren't sure if
> > the larb has power at that time. the important thing is that the MM
> > devices have already not known which larb it connects with as we plan to
> > delete "mediatek,larb" in their dtsi nodes.
>
> From the practical point of view, it doesn't look like setting this on
> a per-larb basis would make much sense. The reason to switch the
> bank_sel would be to decide which MM devices can share the same
> address space. This is a security aspect, because it effectively
> determines which devices are isolated from each other.
>
> That said, I agree that for now we can just start with a fixed
> assignment. We can think of the API if there is a need to adjust the
> assignment.
Sorry for here. I forgot a thing here. that interface above still will
not be helpful. If we don't divide the whole 16GB ranges into 4
regions(let all the other ranges be dynamical), It won't work since we
can only adjust bank_sel with the larb as unit. This is a problem. there
are many ports in a larb. Take a example, the address for vcodec read
port is 32bits while the address for vcodec write port is 33bit, then it
will fail since we only have one bank_sel setting for one larb. Thus we
have to use current design.
>
> >
> > In current design, the MM device don't need care about it and 4GB
> > range is enough for them.
> >
>
> Actually, is the current assignment correct?
Oh. In the code (patch [32/33] of v6), I put CCU0/1 in the cam/mdp
region which start at 8G since CCU0/1 is a module of camera.
>
> domain-id module iova-range larbs
> 0 disp 0 ~ 4G larb0/1
> 1 vcodec 4G ~ 8G larb4/5/7
> 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
>
> Wouldn't CCU0 and CCU1 conflict with disp?
About the conflict, I use patch [29/33] of v6 for this. I will reserve
this special iova region when the full domain(0-4G in this example)
initialize.
> Should perhaps disp be assigned 12G ~ 16G instead?
I think no need put it to 12G-16G, In previous SoC, we have only 4GB
ranges for whole MM engines. currently only cam/mdp domain exclude 128M
for CCU. it should be something wrong if this is not enough.
>
> Best regards,
> Tomasz
>
> > >
> > > Best regards,
> > > Tomasz
> > >
> > > >
> > > > Thanks.
> > > > >
> > > > > Best regards,
> > > > > Tomasz
> > > > >
> > > > > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > > > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > > > > >
> > > > > > The iova range for CCU0/1(camera control unit) is HW requirement.
> > > > > >
> > > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > > > ---
> > > > > > .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> > > > > > include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> > > > > > 2 files changed, 257 insertions(+), 1 deletion(-)
> > > > > > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> > > > > >
> > > > [snip]
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2021-01-20 7:07 ` Yong Wu
@ 2021-01-25 4:18 ` Tomasz Figa
2021-01-25 7:33 ` Yong Wu
0 siblings, 1 reply; 56+ messages in thread
From: Tomasz Figa @ 2021-01-25 4:18 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Will Deacon, Linux Kernel Mailing List, Evan Green, chao.hao,
open list:IOMMU DRIVERS, Rob Herring,
moderated list:ARM/Mediatek SoC support, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
On Wed, Jan 20, 2021 at 4:08 PM Yong Wu <yong.wu@mediatek.com> wrote:
>
> On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote:
> > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > >
> > > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote:
> > > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > > > >
> > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> > > > > > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> > > > > > > This patch adds decriptions for mt8192 IOMMU and SMI.
> > > > > > >
> > > > > > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > > > > > > table format. The M4U-SMI HW diagram is as below:
> > > > > > >
> > > > > > > EMI
> > > > > > > |
> > > > > > > M4U
> > > > > > > |
> > > > > > > ------------
> > > > > > > SMI Common
> > > > > > > ------------
> > > > > > > |
> > > > > > > +-------+------+------+----------------------+-------+
> > > > > > > | | | | ...... | |
> > > > > > > | | | | | |
> > > > > > > larb0 larb1 larb2 larb4 ...... larb19 larb20
> > > > > > > disp0 disp1 mdp vdec IPE IPE
> > > > > > >
> > > > > > > All the connections are HW fixed, SW can NOT adjust it.
> > > > > > >
> > > > > > > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > > > > > > into different iova ranges:
> > > > > > >
> > > > > > > domain-id module iova-range larbs
> > > > > > > 0 disp 0 ~ 4G larb0/1
> > > > > > > 1 vcodec 4G ~ 8G larb4/5/7
> > > > > > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > > > > >
> > > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or
> > > > > > integrator's decision to split the 16 GB address range into sub-ranges
> > > > > > and define which larbs those sub-ranges are shared with?
> > > > >
> > > > > The problem is that we can't split the 16GB range with the larb as unit.
> > > > > The example is the below ccu0(larb13 port9/10) is a independent
> > > > > range(domain), the others ports in larb13 is in another domain.
> > > > >
> > > > > disp/vcodec/cam/mdp don't have special iova requirement, they could
> > > > > access any range. vcodec also can locate 8G~12G. it don't care about
> > > > > where its iova locate. here I preassign like this following with our
> > > > > internal project setting.
> > > >
> > > > Let me try to understand this a bit more. Given the split you're
> > > > proposing, is there actually any isolation enforced between particular
> > > > domains? For example, if I program vcodec to with a DMA address from
> > > > the 0-4G range, would the IOMMU actually generate a fault, even if
> > > > disp had some memory mapped at that address?
> > >
> > > In this case. we will get fault in current SW setting.
> > >
> >
> > Okay, thanks.
> >
> > > >
> > > > >
> > > > > Why set this in DT?, this is only for simplifying the code. Assume we
> > > > > put it in the platform data. We have up to 32 larbs, each larb has up to
> > > > > 32 ports, each port may be in different iommu domains. we should have a
> > > > > big array for this..however we only use a macro to get the domain in the
> > > > > DT method.
> > > > >
> > > > > When replying this mail, I happen to see there is a "dev->dev_range_map"
> > > > > which has "dma-range" information, I think I could use this value to get
> > > > > which domain the device belong to. then no need put domid in DT. I will
> > > > > test this.
> > > >
> > > > My feeling is that the only part that needs to be enforced statically
> > > > is the reserved IOVA range for CCUs. The other ranges should be
> > > > determined dynamically, although I think I need to understand better
> > > > how the hardware and your proposed design work to tell what would be
> > > > likely the best choice here.
> > >
> > > I have removed the domid patch in v6. and get the domain id in [27/33]
> > > in v6..
> > >
> > > About the other ranges should be dynamical, the commit message [30/33]
> > > of v6 should be helpful. the problem is that we have a bank_sel setting
> > > for the iova[32:33]. currently we preassign this value. thus, all the
> > > ranges are fixed. If you adjust this setting, you can let vcodec access
> > > 0~4G.
> >
> > Okay, so it sounds like we effectively have four 4G address spaces and
> > we can assign the master devices to them. I guess each of these
> > address spaces makes for an IOMMU group.
>
> Yes. Each a address spaces is an IOMMU group.
>
> >
> > It's fine to pre-assign the devices to those groups for now, but it
> > definitely shouldn't be hardcoded in DT, because it depends on the use
> > case of the device. I'll take a look at v6, but it sounds like it
> > should be fine if it doesn't take the address space assignment from DT
> > anymore.
>
> Thanks very much for your review.
>
Hmm, I had a look at v6 and it still has the address spaces hardcoded
in the DTS. Could we move the fixed assignment to the MTK IOMMU driver
code instead, so that it can be easily adjusted as the kernel code
evolves without the need to update the DTS?
> >
> > >
> > > Currently we have no interface to adjust this setting. Suppose we add a
> > > new interface for this. It would be something like:
> > >
> > > int mtk_smi_larb_config_banksel(struct device *larb, int banksel)
> > >
> > > Then, all the MM drivers should call it before the HW works every
> > > time, and its implement will be a bit complex since we aren't sure if
> > > the larb has power at that time. the important thing is that the MM
> > > devices have already not known which larb it connects with as we plan to
> > > delete "mediatek,larb" in their dtsi nodes.
> >
> > From the practical point of view, it doesn't look like setting this on
> > a per-larb basis would make much sense. The reason to switch the
> > bank_sel would be to decide which MM devices can share the same
> > address space. This is a security aspect, because it effectively
> > determines which devices are isolated from each other.
> >
> > That said, I agree that for now we can just start with a fixed
> > assignment. We can think of the API if there is a need to adjust the
> > assignment.
>
> Sorry for here. I forgot a thing here. that interface above still will
> not be helpful. If we don't divide the whole 16GB ranges into 4
> regions(let all the other ranges be dynamical), It won't work since we
> can only adjust bank_sel with the larb as unit. This is a problem. there
> are many ports in a larb. Take a example, the address for vcodec read
> port is 32bits while the address for vcodec write port is 33bit, then it
> will fail since we only have one bank_sel setting for one larb.
That's exactly why I proposed to have the API operate based on the
struct device, rather than individual DMA ports. Although I guess the
CCU case is different, because it's the same larb as the camera.
Anyway, I agree that we don't have to come up with such an API right now.
> Thus we
> have to use current design.
>
> >
> > >
> > > In current design, the MM device don't need care about it and 4GB
> > > range is enough for them.
> > >
> >
> > Actually, is the current assignment correct?
>
> Oh. In the code (patch [32/33] of v6), I put CCU0/1 in the cam/mdp
> region which start at 8G since CCU0/1 is a module of camera.
>
> >
> > domain-id module iova-range larbs
> > 0 disp 0 ~ 4G larb0/1
> > 1 vcodec 4G ~ 8G larb4/5/7
> > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> >
> > Wouldn't CCU0 and CCU1 conflict with disp?
>
> About the conflict, I use patch [29/33] of v6 for this. I will reserve
> this special iova region when the full domain(0-4G in this example)
> initialize.
>
> > Should perhaps disp be assigned 12G ~ 16G instead?
>
> I think no need put it to 12G-16G, In previous SoC, we have only 4GB
> ranges for whole MM engines. currently only cam/mdp domain exclude 128M
> for CCU. it should be something wrong if this is not enough.
>
Indeed, space is not a problem, but from the security point of view
it's undesirable. I believe CCU would be running proprietary firmware,
so it should be isolated as much as possible from other components.
And, after all, why waste the remaining 4G of address space?
Best regards,
Tomasz
> >
> > Best regards,
> > Tomasz
> >
> > > >
> > > > Best regards,
> > > > Tomasz
> > > >
> > > > >
> > > > > Thanks.
> > > > > >
> > > > > > Best regards,
> > > > > > Tomasz
> > > > > >
> > > > > > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > > > > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > > > > > >
> > > > > > > The iova range for CCU0/1(camera control unit) is HW requirement.
> > > > > > >
> > > > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > > > > ---
> > > > > > > .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> > > > > > > include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> > > > > > > 2 files changed, 257 insertions(+), 1 deletion(-)
> > > > > > > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> > > > > > >
> > > > > [snip]
> > >
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2021-01-25 4:18 ` Tomasz Figa
@ 2021-01-25 7:33 ` Yong Wu
2021-01-29 11:45 ` Tomasz Figa
0 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2021-01-25 7:33 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Robin Murphy, Linux Kernel Mailing List, Evan Green, chao.hao,
open list:IOMMU DRIVERS, Rob Herring,
moderated list:ARM/Mediatek SoC support, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Will Deacon,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote:
> On Wed, Jan 20, 2021 at 4:08 PM Yong Wu <yong.wu@mediatek.com> wrote:
> >
> > On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote:
> > > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > > >
> > > > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote:
> > > > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > > > > >
> > > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> > > > > > > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> > > > > > > > This patch adds decriptions for mt8192 IOMMU and SMI.
> > > > > > > >
> > > > > > > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > > > > > > > table format. The M4U-SMI HW diagram is as below:
> > > > > > > >
> > > > > > > > EMI
> > > > > > > > |
> > > > > > > > M4U
> > > > > > > > |
> > > > > > > > ------------
> > > > > > > > SMI Common
> > > > > > > > ------------
> > > > > > > > |
> > > > > > > > +-------+------+------+----------------------+-------+
> > > > > > > > | | | | ...... | |
> > > > > > > > | | | | | |
> > > > > > > > larb0 larb1 larb2 larb4 ...... larb19 larb20
> > > > > > > > disp0 disp1 mdp vdec IPE IPE
> > > > > > > >
> > > > > > > > All the connections are HW fixed, SW can NOT adjust it.
> > > > > > > >
> > > > > > > > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > > > > > > > into different iova ranges:
> > > > > > > >
> > > > > > > > domain-id module iova-range larbs
> > > > > > > > 0 disp 0 ~ 4G larb0/1
> > > > > > > > 1 vcodec 4G ~ 8G larb4/5/7
> > > > > > > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > > > > > >
> > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or
> > > > > > > integrator's decision to split the 16 GB address range into sub-ranges
> > > > > > > and define which larbs those sub-ranges are shared with?
> > > > > >
> > > > > > The problem is that we can't split the 16GB range with the larb as unit.
> > > > > > The example is the below ccu0(larb13 port9/10) is a independent
> > > > > > range(domain), the others ports in larb13 is in another domain.
> > > > > >
> > > > > > disp/vcodec/cam/mdp don't have special iova requirement, they could
> > > > > > access any range. vcodec also can locate 8G~12G. it don't care about
> > > > > > where its iova locate. here I preassign like this following with our
> > > > > > internal project setting.
> > > > >
> > > > > Let me try to understand this a bit more. Given the split you're
> > > > > proposing, is there actually any isolation enforced between particular
> > > > > domains? For example, if I program vcodec to with a DMA address from
> > > > > the 0-4G range, would the IOMMU actually generate a fault, even if
> > > > > disp had some memory mapped at that address?
> > > >
> > > > In this case. we will get fault in current SW setting.
> > > >
> > >
> > > Okay, thanks.
> > >
> > > > >
> > > > > >
> > > > > > Why set this in DT?, this is only for simplifying the code. Assume we
> > > > > > put it in the platform data. We have up to 32 larbs, each larb has up to
> > > > > > 32 ports, each port may be in different iommu domains. we should have a
> > > > > > big array for this..however we only use a macro to get the domain in the
> > > > > > DT method.
> > > > > >
> > > > > > When replying this mail, I happen to see there is a "dev->dev_range_map"
> > > > > > which has "dma-range" information, I think I could use this value to get
> > > > > > which domain the device belong to. then no need put domid in DT. I will
> > > > > > test this.
> > > > >
> > > > > My feeling is that the only part that needs to be enforced statically
> > > > > is the reserved IOVA range for CCUs. The other ranges should be
> > > > > determined dynamically, although I think I need to understand better
> > > > > how the hardware and your proposed design work to tell what would be
> > > > > likely the best choice here.
> > > >
> > > > I have removed the domid patch in v6. and get the domain id in [27/33]
> > > > in v6..
> > > >
> > > > About the other ranges should be dynamical, the commit message [30/33]
> > > > of v6 should be helpful. the problem is that we have a bank_sel setting
> > > > for the iova[32:33]. currently we preassign this value. thus, all the
> > > > ranges are fixed. If you adjust this setting, you can let vcodec access
> > > > 0~4G.
> > >
> > > Okay, so it sounds like we effectively have four 4G address spaces and
> > > we can assign the master devices to them. I guess each of these
> > > address spaces makes for an IOMMU group.
> >
> > Yes. Each a address spaces is an IOMMU group.
> >
> > >
> > > It's fine to pre-assign the devices to those groups for now, but it
> > > definitely shouldn't be hardcoded in DT, because it depends on the use
> > > case of the device. I'll take a look at v6, but it sounds like it
> > > should be fine if it doesn't take the address space assignment from DT
> > > anymore.
> >
> > Thanks very much for your review.
> >
>
> Hmm, I had a look at v6 and it still has the address spaces hardcoded
> in the DTS.
sorry. I didn't get here. where do you mean. or help reply in v6.
I only added the preassign list as comment in the file
(dt-binding/memory/mt8192-larb-port.h). I thought our iommu consumer may
need it when they use these ports. they need add dma-ranges property if
its iova is over 4GB.
> Could we move the fixed assignment to the MTK IOMMU driver code instead,
> so that it can be easily adjusted as the kernel code
> evolves without the need to update the DTS?
>
> > >
> > > >
> > > > Currently we have no interface to adjust this setting. Suppose we add a
> > > > new interface for this. It would be something like:
> > > >
> > > > int mtk_smi_larb_config_banksel(struct device *larb, int banksel)
> > > >
> > > > Then, all the MM drivers should call it before the HW works every
> > > > time, and its implement will be a bit complex since we aren't sure if
> > > > the larb has power at that time. the important thing is that the MM
> > > > devices have already not known which larb it connects with as we plan to
> > > > delete "mediatek,larb" in their dtsi nodes.
> > >
> > > From the practical point of view, it doesn't look like setting this on
> > > a per-larb basis would make much sense. The reason to switch the
> > > bank_sel would be to decide which MM devices can share the same
> > > address space. This is a security aspect, because it effectively
> > > determines which devices are isolated from each other.
> > >
> > > That said, I agree that for now we can just start with a fixed
> > > assignment. We can think of the API if there is a need to adjust the
> > > assignment.
> >
> > Sorry for here. I forgot a thing here. that interface above still will
> > not be helpful. If we don't divide the whole 16GB ranges into 4
> > regions(let all the other ranges be dynamical), It won't work since we
> > can only adjust bank_sel with the larb as unit. This is a problem. there
> > are many ports in a larb. Take a example, the address for vcodec read
> > port is 32bits while the address for vcodec write port is 33bit, then it
> > will fail since we only have one bank_sel setting for one larb.
>
> That's exactly why I proposed to have the API operate based on the
> struct device, rather than individual DMA ports. Although I guess the
> CCU case is different, because it's the same larb as the camera.
>
> Anyway, I agree that we don't have to come up with such an API right now.
Thanks for the confirm.
>
> > Thus we
> > have to use current design.
> >
> > >
> > > >
> > > > In current design, the MM device don't need care about it and 4GB
> > > > range is enough for them.
> > > >
> > >
> > > Actually, is the current assignment correct?
> >
> > Oh. In the code (patch [32/33] of v6), I put CCU0/1 in the cam/mdp
> > region which start at 8G since CCU0/1 is a module of camera.
> >
> > >
> > > domain-id module iova-range larbs
> > > 0 disp 0 ~ 4G larb0/1
> > > 1 vcodec 4G ~ 8G larb4/5/7
> > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > >
> > > Wouldn't CCU0 and CCU1 conflict with disp?
> >
> > About the conflict, I use patch [29/33] of v6 for this. I will reserve
> > this special iova region when the full domain(0-4G in this example)
> > initialize.
> >
> > > Should perhaps disp be assigned 12G ~ 16G instead?
> >
> > I think no need put it to 12G-16G, In previous SoC, we have only 4GB
> > ranges for whole MM engines. currently only cam/mdp domain exclude 128M
> > for CCU. it should be something wrong if this is not enough.
> >
>
> Indeed, space is not a problem, but from the security point of view
> it's undesirable. I believe CCU would be running proprietary firmware,
> so it should be isolated as much as possible from other components.
CCU are in the same larb with camera. Thus, it also need locate the same
iova range with camera.
> And, after all, why waste the remaining 4G of address space?
>
> Best regards,
> Tomasz
>
> > >
> > > Best regards,
> > > Tomasz
> > >
> > > > >
> > > > > Best regards,
> > > > > Tomasz
> > > > >
> > > > > >
> > > > > > Thanks.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Tomasz
> > > > > > >
> > > > > > > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > > > > > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > > > > > > >
> > > > > > > > The iova range for CCU0/1(camera control unit) is HW requirement.
> > > > > > > >
> > > > > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > > > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > > > > > ---
> > > > > > > > .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> > > > > > > > include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> > > > > > > > 2 files changed, 257 insertions(+), 1 deletion(-)
> > > > > > > > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> > > > > > > >
> > > > > > [snip]
> > > >
> >
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2021-01-25 7:33 ` Yong Wu
@ 2021-01-29 11:45 ` Tomasz Figa
2021-02-01 5:36 ` Yong Wu
2021-02-01 10:44 ` Robin Murphy
0 siblings, 2 replies; 56+ messages in thread
From: Tomasz Figa @ 2021-01-29 11:45 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Robin Murphy, Linux Kernel Mailing List, Evan Green, chao.hao,
open list:IOMMU DRIVERS, Rob Herring,
moderated list:ARM/Mediatek SoC support, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Will Deacon,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
On Mon, Jan 25, 2021 at 4:34 PM Yong Wu <yong.wu@mediatek.com> wrote:
>
> On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote:
> > On Wed, Jan 20, 2021 at 4:08 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > >
> > > On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote:
> > > > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > > > >
> > > > > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote:
> > > > > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > > > > > >
> > > > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> > > > > > > > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> > > > > > > > > This patch adds decriptions for mt8192 IOMMU and SMI.
> > > > > > > > >
> > > > > > > > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > > > > > > > > table format. The M4U-SMI HW diagram is as below:
> > > > > > > > >
> > > > > > > > > EMI
> > > > > > > > > |
> > > > > > > > > M4U
> > > > > > > > > |
> > > > > > > > > ------------
> > > > > > > > > SMI Common
> > > > > > > > > ------------
> > > > > > > > > |
> > > > > > > > > +-------+------+------+----------------------+-------+
> > > > > > > > > | | | | ...... | |
> > > > > > > > > | | | | | |
> > > > > > > > > larb0 larb1 larb2 larb4 ...... larb19 larb20
> > > > > > > > > disp0 disp1 mdp vdec IPE IPE
> > > > > > > > >
> > > > > > > > > All the connections are HW fixed, SW can NOT adjust it.
> > > > > > > > >
> > > > > > > > > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > > > > > > > > into different iova ranges:
> > > > > > > > >
> > > > > > > > > domain-id module iova-range larbs
> > > > > > > > > 0 disp 0 ~ 4G larb0/1
> > > > > > > > > 1 vcodec 4G ~ 8G larb4/5/7
> > > > > > > > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > > > > > > >
> > > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or
> > > > > > > > integrator's decision to split the 16 GB address range into sub-ranges
> > > > > > > > and define which larbs those sub-ranges are shared with?
> > > > > > >
> > > > > > > The problem is that we can't split the 16GB range with the larb as unit.
> > > > > > > The example is the below ccu0(larb13 port9/10) is a independent
> > > > > > > range(domain), the others ports in larb13 is in another domain.
> > > > > > >
> > > > > > > disp/vcodec/cam/mdp don't have special iova requirement, they could
> > > > > > > access any range. vcodec also can locate 8G~12G. it don't care about
> > > > > > > where its iova locate. here I preassign like this following with our
> > > > > > > internal project setting.
> > > > > >
> > > > > > Let me try to understand this a bit more. Given the split you're
> > > > > > proposing, is there actually any isolation enforced between particular
> > > > > > domains? For example, if I program vcodec to with a DMA address from
> > > > > > the 0-4G range, would the IOMMU actually generate a fault, even if
> > > > > > disp had some memory mapped at that address?
> > > > >
> > > > > In this case. we will get fault in current SW setting.
> > > > >
> > > >
> > > > Okay, thanks.
> > > >
> > > > > >
> > > > > > >
> > > > > > > Why set this in DT?, this is only for simplifying the code. Assume we
> > > > > > > put it in the platform data. We have up to 32 larbs, each larb has up to
> > > > > > > 32 ports, each port may be in different iommu domains. we should have a
> > > > > > > big array for this..however we only use a macro to get the domain in the
> > > > > > > DT method.
> > > > > > >
> > > > > > > When replying this mail, I happen to see there is a "dev->dev_range_map"
> > > > > > > which has "dma-range" information, I think I could use this value to get
> > > > > > > which domain the device belong to. then no need put domid in DT. I will
> > > > > > > test this.
> > > > > >
> > > > > > My feeling is that the only part that needs to be enforced statically
> > > > > > is the reserved IOVA range for CCUs. The other ranges should be
> > > > > > determined dynamically, although I think I need to understand better
> > > > > > how the hardware and your proposed design work to tell what would be
> > > > > > likely the best choice here.
> > > > >
> > > > > I have removed the domid patch in v6. and get the domain id in [27/33]
> > > > > in v6..
> > > > >
> > > > > About the other ranges should be dynamical, the commit message [30/33]
> > > > > of v6 should be helpful. the problem is that we have a bank_sel setting
> > > > > for the iova[32:33]. currently we preassign this value. thus, all the
> > > > > ranges are fixed. If you adjust this setting, you can let vcodec access
> > > > > 0~4G.
> > > >
> > > > Okay, so it sounds like we effectively have four 4G address spaces and
> > > > we can assign the master devices to them. I guess each of these
> > > > address spaces makes for an IOMMU group.
> > >
> > > Yes. Each a address spaces is an IOMMU group.
> > >
> > > >
> > > > It's fine to pre-assign the devices to those groups for now, but it
> > > > definitely shouldn't be hardcoded in DT, because it depends on the use
> > > > case of the device. I'll take a look at v6, but it sounds like it
> > > > should be fine if it doesn't take the address space assignment from DT
> > > > anymore.
> > >
> > > Thanks very much for your review.
> > >
> >
> > Hmm, I had a look at v6 and it still has the address spaces hardcoded
> > in the DTS.
>
> sorry. I didn't get here. where do you mean. or help reply in v6.
>
> I only added the preassign list as comment in the file
> (dt-binding/memory/mt8192-larb-port.h). I thought our iommu consumer may
> need it when they use these ports. they need add dma-ranges property if
> its iova is over 4GB.
That's exactly the problem. v6 simply replaced one way to describe the
policy (domain ID) with another (dma-ranges). However, DT is not the
right place to describe policies, because it's the place to describe
hardware in a way agnostic from policies and use cases. In other
words, DT must not impose using the hardware in one way or another.
For example, we have two different companies that want to ship
products based on this SoC - A and B. Company A may want to put MDP
and camera in the same address space, but company B instead would
prefer MDP to be in the same address space as video. Because this
decision is stored in DT, one of them will have to change and rebuild
their kernel and maintain a downstream patch.
My suggestion to follow here would be to:
- stop using dma-ranges for this purpose,
- add an array in the MTK IOMMU driver that has a default map between
larbs and domains, e.g.
static u8 mt8192_domain_map[NUM_DOMAINS][NUM_LARBS] = {
[0] = { 0 , 1, 0xff },
[1] = { 4, 5, 7, 0xff },
[2] = { 2, 9, 11, 13, 14, 16, 17, 18, 19, 20, 0xff },
};
- add a kernel command line parameter that allows overriding of this map, e.g.
mtk_iommu.domain_map="0:0,1:1:4,5,7:2:2,9,11,13,14,16,17,18,19,20"
would be equivalent to the array above. Same could be also given by a
Kconfig entry if one can't or doesn't want to add extra command line
parameters.
Would something like this work?
>
> > Could we move the fixed assignment to the MTK IOMMU driver code instead,
> > so that it can be easily adjusted as the kernel code
> > evolves without the need to update the DTS?
> >
> > > >
> > > > >
> > > > > Currently we have no interface to adjust this setting. Suppose we add a
> > > > > new interface for this. It would be something like:
> > > > >
> > > > > int mtk_smi_larb_config_banksel(struct device *larb, int banksel)
> > > > >
> > > > > Then, all the MM drivers should call it before the HW works every
> > > > > time, and its implement will be a bit complex since we aren't sure if
> > > > > the larb has power at that time. the important thing is that the MM
> > > > > devices have already not known which larb it connects with as we plan to
> > > > > delete "mediatek,larb" in their dtsi nodes.
> > > >
> > > > From the practical point of view, it doesn't look like setting this on
> > > > a per-larb basis would make much sense. The reason to switch the
> > > > bank_sel would be to decide which MM devices can share the same
> > > > address space. This is a security aspect, because it effectively
> > > > determines which devices are isolated from each other.
> > > >
> > > > That said, I agree that for now we can just start with a fixed
> > > > assignment. We can think of the API if there is a need to adjust the
> > > > assignment.
> > >
> > > Sorry for here. I forgot a thing here. that interface above still will
> > > not be helpful. If we don't divide the whole 16GB ranges into 4
> > > regions(let all the other ranges be dynamical), It won't work since we
> > > can only adjust bank_sel with the larb as unit. This is a problem. there
> > > are many ports in a larb. Take a example, the address for vcodec read
> > > port is 32bits while the address for vcodec write port is 33bit, then it
> > > will fail since we only have one bank_sel setting for one larb.
> >
> > That's exactly why I proposed to have the API operate based on the
> > struct device, rather than individual DMA ports. Although I guess the
> > CCU case is different, because it's the same larb as the camera.
> >
> > Anyway, I agree that we don't have to come up with such an API right now.
>
> Thanks for the confirm.
>
> >
> > > Thus we
> > > have to use current design.
> > >
> > > >
> > > > >
> > > > > In current design, the MM device don't need care about it and 4GB
> > > > > range is enough for them.
> > > > >
> > > >
> > > > Actually, is the current assignment correct?
> > >
> > > Oh. In the code (patch [32/33] of v6), I put CCU0/1 in the cam/mdp
> > > region which start at 8G since CCU0/1 is a module of camera.
> > >
> > > >
> > > > domain-id module iova-range larbs
> > > > 0 disp 0 ~ 4G larb0/1
> > > > 1 vcodec 4G ~ 8G larb4/5/7
> > > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > > >
> > > > Wouldn't CCU0 and CCU1 conflict with disp?
> > >
> > > About the conflict, I use patch [29/33] of v6 for this. I will reserve
> > > this special iova region when the full domain(0-4G in this example)
> > > initialize.
> > >
> > > > Should perhaps disp be assigned 12G ~ 16G instead?
> > >
> > > I think no need put it to 12G-16G, In previous SoC, we have only 4GB
> > > ranges for whole MM engines. currently only cam/mdp domain exclude 128M
> > > for CCU. it should be something wrong if this is not enough.
> > >
> >
> > Indeed, space is not a problem, but from the security point of view
> > it's undesirable. I believe CCU would be running proprietary firmware,
> > so it should be isolated as much as possible from other components.
>
> CCU are in the same larb with camera. Thus, it also need locate the same
> iova range with camera.
What are larb13 and larb14 used by besides CCU? Is it possible to put
them in a separate address space from other camera larbs?
Best regards,
Tomasz
>
> > And, after all, why waste the remaining 4G of address space?
> >
> > Best regards,
> > Tomasz
> >
> > > >
> > > > Best regards,
> > > > Tomasz
> > > >
> > > > > >
> > > > > > Best regards,
> > > > > > Tomasz
> > > > > >
> > > > > > >
> > > > > > > Thanks.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Tomasz
> > > > > > > >
> > > > > > > > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > > > > > > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > > > > > > > >
> > > > > > > > > The iova range for CCU0/1(camera control unit) is HW requirement.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > > > > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > > > > > > ---
> > > > > > > > > .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> > > > > > > > > include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> > > > > > > > > 2 files changed, 257 insertions(+), 1 deletion(-)
> > > > > > > > > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> > > > > > > > >
> > > > > > > [snip]
> > > > >
> > >
> >
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2021-01-29 11:45 ` Tomasz Figa
@ 2021-02-01 5:36 ` Yong Wu
2021-02-01 10:44 ` Robin Murphy
1 sibling, 0 replies; 56+ messages in thread
From: Yong Wu @ 2021-02-01 5:36 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Robin Murphy, Linux Kernel Mailing List, Evan Green, chao.hao,
open list:IOMMU DRIVERS, Rob Herring,
moderated list:ARM/Mediatek SoC support, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Will Deacon,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
On Fri, 2021-01-29 at 20:45 +0900, Tomasz Figa wrote:
> On Mon, Jan 25, 2021 at 4:34 PM Yong Wu <yong.wu@mediatek.com> wrote:
> >
> > On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote:
> > > On Wed, Jan 20, 2021 at 4:08 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > > >
> > > > On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote:
> > > > > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > > > > >
> > > > > > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote:
> > > > > > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu <yong.wu@mediatek.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
> > > > > > > > > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> > > > > > > > > > This patch adds decriptions for mt8192 IOMMU and SMI.
> > > > > > > > > >
> > > > > > > > > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > > > > > > > > > table format. The M4U-SMI HW diagram is as below:
> > > > > > > > > >
> > > > > > > > > > EMI
> > > > > > > > > > |
> > > > > > > > > > M4U
> > > > > > > > > > |
> > > > > > > > > > ------------
> > > > > > > > > > SMI Common
> > > > > > > > > > ------------
> > > > > > > > > > |
> > > > > > > > > > +-------+------+------+----------------------+-------+
> > > > > > > > > > | | | | ...... | |
> > > > > > > > > > | | | | | |
> > > > > > > > > > larb0 larb1 larb2 larb4 ...... larb19 larb20
> > > > > > > > > > disp0 disp1 mdp vdec IPE IPE
> > > > > > > > > >
> > > > > > > > > > All the connections are HW fixed, SW can NOT adjust it.
> > > > > > > > > >
> > > > > > > > > > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > > > > > > > > > into different iova ranges:
> > > > > > > > > >
> > > > > > > > > > domain-id module iova-range larbs
> > > > > > > > > > 0 disp 0 ~ 4G larb0/1
> > > > > > > > > > 1 vcodec 4G ~ 8G larb4/5/7
> > > > > > > > > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > > > > > > > >
> > > > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or
> > > > > > > > > integrator's decision to split the 16 GB address range into sub-ranges
> > > > > > > > > and define which larbs those sub-ranges are shared with?
> > > > > > > >
> > > > > > > > The problem is that we can't split the 16GB range with the larb as unit.
> > > > > > > > The example is the below ccu0(larb13 port9/10) is a independent
> > > > > > > > range(domain), the others ports in larb13 is in another domain.
> > > > > > > >
> > > > > > > > disp/vcodec/cam/mdp don't have special iova requirement, they could
> > > > > > > > access any range. vcodec also can locate 8G~12G. it don't care about
> > > > > > > > where its iova locate. here I preassign like this following with our
> > > > > > > > internal project setting.
> > > > > > >
> > > > > > > Let me try to understand this a bit more. Given the split you're
> > > > > > > proposing, is there actually any isolation enforced between particular
> > > > > > > domains? For example, if I program vcodec to with a DMA address from
> > > > > > > the 0-4G range, would the IOMMU actually generate a fault, even if
> > > > > > > disp had some memory mapped at that address?
> > > > > >
> > > > > > In this case. we will get fault in current SW setting.
> > > > > >
> > > > >
> > > > > Okay, thanks.
> > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Why set this in DT?, this is only for simplifying the code. Assume we
> > > > > > > > put it in the platform data. We have up to 32 larbs, each larb has up to
> > > > > > > > 32 ports, each port may be in different iommu domains. we should have a
> > > > > > > > big array for this..however we only use a macro to get the domain in the
> > > > > > > > DT method.
> > > > > > > >
> > > > > > > > When replying this mail, I happen to see there is a "dev->dev_range_map"
> > > > > > > > which has "dma-range" information, I think I could use this value to get
> > > > > > > > which domain the device belong to. then no need put domid in DT. I will
> > > > > > > > test this.
> > > > > > >
> > > > > > > My feeling is that the only part that needs to be enforced statically
> > > > > > > is the reserved IOVA range for CCUs. The other ranges should be
> > > > > > > determined dynamically, although I think I need to understand better
> > > > > > > how the hardware and your proposed design work to tell what would be
> > > > > > > likely the best choice here.
> > > > > >
> > > > > > I have removed the domid patch in v6. and get the domain id in [27/33]
> > > > > > in v6..
> > > > > >
> > > > > > About the other ranges should be dynamical, the commit message [30/33]
> > > > > > of v6 should be helpful. the problem is that we have a bank_sel setting
> > > > > > for the iova[32:33]. currently we preassign this value. thus, all the
> > > > > > ranges are fixed. If you adjust this setting, you can let vcodec access
> > > > > > 0~4G.
> > > > >
> > > > > Okay, so it sounds like we effectively have four 4G address spaces and
> > > > > we can assign the master devices to them. I guess each of these
> > > > > address spaces makes for an IOMMU group.
> > > >
> > > > Yes. Each a address spaces is an IOMMU group.
> > > >
> > > > >
> > > > > It's fine to pre-assign the devices to those groups for now, but it
> > > > > definitely shouldn't be hardcoded in DT, because it depends on the use
> > > > > case of the device. I'll take a look at v6, but it sounds like it
> > > > > should be fine if it doesn't take the address space assignment from DT
> > > > > anymore.
> > > >
> > > > Thanks very much for your review.
> > > >
> > >
> > > Hmm, I had a look at v6 and it still has the address spaces hardcoded
> > > in the DTS.
> >
> > sorry. I didn't get here. where do you mean. or help reply in v6.
> >
> > I only added the preassign list as comment in the file
> > (dt-binding/memory/mt8192-larb-port.h). I thought our iommu consumer may
> > need it when they use these ports. they need add dma-ranges property if
> > its iova is over 4GB.
>
> That's exactly the problem. v6 simply replaced one way to describe the
> policy (domain ID) with another (dma-ranges). However, DT is not the
> right place to describe policies, because it's the place to describe
> hardware in a way agnostic from policies and use cases. In other
> words, DT must not impose using the hardware in one way or another.
>
> For example, we have two different companies that want to ship
> products based on this SoC - A and B. Company A may want to put MDP
> and camera in the same address space, but company B instead would
> prefer MDP to be in the same address space as video. Because this
> decision is stored in DT, one of them will have to change and rebuild
> their kernel and maintain a downstream patch.
We have already got the domain id from the device's dma-ranges of DT. In
this case, we don't need rebuild the kernel, right? they only need
update the dma-ranges in DT.
>
> My suggestion to follow here would be to:
> - stop using dma-ranges for this purpose,
Assume we have already adjusted the iova of engine A to 4G~8G with the
below array, if it don't use dma-ranges in DT, It will abort at [1]
since we have already updated the domain->geometer.aperture_start/end to
4G~8G and the default base/size in this function always are 0/4G.
[1]
https://elixir.bootlin.com/linux/v5.11-rc1/source/drivers/iommu/dma-iommu.c#L345
> - add an array in the MTK IOMMU driver that has a default map between
> larbs and domains, e.g.
>
> static u8 mt8192_domain_map[NUM_DOMAINS][NUM_LARBS] = {
> [0] = { 0 , 1, 0xff },
> [1] = { 4, 5, 7, 0xff },
> [2] = { 2, 9, 11, 13, 14, 16, 17, 18, 19, 20, 0xff },
> };
If this simple array work, I won't add dom_id in DT at the begginning.
As you may already know, we determine the domain by port number within
the larb rather that the larb number. If using the array, It should be
something like:
static u8 mt8192_domain_map[NUM_DOMAINS][NUM_LARBS_MAX] = {
/* Each a bit represent a port. ~0 means all ports in domain 0. */
[0] = {~0, ~0, }, /* larb0/1 in domain 0 */
[1] = { 0, 0, 0, 0, ~0, ~0, 0, ~0, }, /* larb4/5/7 in domain1 */
[2] = { 0, 0, ~0 ....},
/* CCU0: larb13 bit9/10 */
[3] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, BIT(9) | BIT(10)}
/* CCU1: larb14 port4/5*/
[4] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, BIT(4) | BIT(5)},
};
This array looks a bit complex. I didn't like it before.
>
> - add a kernel command line parameter that allows overriding of this map, e.g.
>
> mtk_iommu.domain_map="0:0,1:1:4,5,7:2:2,9,11,13,14,16,17,18,19,20"
>
> would be equivalent to the array above. Same could be also given by a
> Kconfig entry if one can't or doesn't want to add extra command line
> parameters.
>
> Would something like this work?
>
> >
> > > Could we move the fixed assignment to the MTK IOMMU driver code instead,
> > > so that it can be easily adjusted as the kernel code
> > > evolves without the need to update the DTS?
> > >
> > > > >
> > > > > >
> > > > > > Currently we have no interface to adjust this setting. Suppose we add a
> > > > > > new interface for this. It would be something like:
> > > > > >
> > > > > > int mtk_smi_larb_config_banksel(struct device *larb, int banksel)
> > > > > >
> > > > > > Then, all the MM drivers should call it before the HW works every
> > > > > > time, and its implement will be a bit complex since we aren't sure if
> > > > > > the larb has power at that time. the important thing is that the MM
> > > > > > devices have already not known which larb it connects with as we plan to
> > > > > > delete "mediatek,larb" in their dtsi nodes.
> > > > >
> > > > > From the practical point of view, it doesn't look like setting this on
> > > > > a per-larb basis would make much sense. The reason to switch the
> > > > > bank_sel would be to decide which MM devices can share the same
> > > > > address space. This is a security aspect, because it effectively
> > > > > determines which devices are isolated from each other.
> > > > >
> > > > > That said, I agree that for now we can just start with a fixed
> > > > > assignment. We can think of the API if there is a need to adjust the
> > > > > assignment.
> > > >
> > > > Sorry for here. I forgot a thing here. that interface above still will
> > > > not be helpful. If we don't divide the whole 16GB ranges into 4
> > > > regions(let all the other ranges be dynamical), It won't work since we
> > > > can only adjust bank_sel with the larb as unit. This is a problem. there
> > > > are many ports in a larb. Take a example, the address for vcodec read
> > > > port is 32bits while the address for vcodec write port is 33bit, then it
> > > > will fail since we only have one bank_sel setting for one larb.
> > >
> > > That's exactly why I proposed to have the API operate based on the
> > > struct device, rather than individual DMA ports. Although I guess the
> > > CCU case is different, because it's the same larb as the camera.
> > >
> > > Anyway, I agree that we don't have to come up with such an API right now.
> >
> > Thanks for the confirm.
> >
> > >
> > > > Thus we
> > > > have to use current design.
> > > >
> > > > >
> > > > > >
> > > > > > In current design, the MM device don't need care about it and 4GB
> > > > > > range is enough for them.
> > > > > >
> > > > >
> > > > > Actually, is the current assignment correct?
> > > >
> > > > Oh. In the code (patch [32/33] of v6), I put CCU0/1 in the cam/mdp
> > > > region which start at 8G since CCU0/1 is a module of camera.
> > > >
> > > > >
> > > > > domain-id module iova-range larbs
> > > > > 0 disp 0 ~ 4G larb0/1
> > > > > 1 vcodec 4G ~ 8G larb4/5/7
> > > > > 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
> > > > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > > > >
> > > > > Wouldn't CCU0 and CCU1 conflict with disp?
> > > >
> > > > About the conflict, I use patch [29/33] of v6 for this. I will reserve
> > > > this special iova region when the full domain(0-4G in this example)
> > > > initialize.
> > > >
> > > > > Should perhaps disp be assigned 12G ~ 16G instead?
> > > >
> > > > I think no need put it to 12G-16G, In previous SoC, we have only 4GB
> > > > ranges for whole MM engines. currently only cam/mdp domain exclude 128M
> > > > for CCU. it should be something wrong if this is not enough.
> > > >
> > >
> > > Indeed, space is not a problem, but from the security point of view
> > > it's undesirable. I believe CCU would be running proprietary firmware,
> > > so it should be isolated as much as possible from other components.
> >
> > CCU are in the same larb with camera. Thus, it also need locate the same
> > iova range with camera.
>
> What are larb13 and larb14 used by besides CCU? Is it possible to put
> them in a separate address space from other camera larbs?
I may not following you here. What's the benefit for this? The problem
is that larb13-port-9/10 and larb14-port4/5 should be a separate address
space, the others can not occupy their ranges.
In the end, the dma-range can not be omited in two case:
a) the iova over 4GB.
b) the special engine that can only support a special range.
right?
Actually we support the device adjust their dma-ranges like from 4G~8G
to 8G~12G. but we also have our limitation. How about I reword comment
in the mtxxxx-larb-port.h like:
/*
* MM IOMMU supports 16GB dma address. We seperate it to four banks:
* 0 ~ 4G; 4G ~ 8G; 8G ~12G; 12G ~ 16G. we could adjust these master
* locate any banks. BUT
* 1) Make sure all the ports in a larb are in one bank.
* 2) The iova of any master can NOT cross the 4G/8G/12G boundary.
* 3) If there is some special master require a special iova range,
* Make sure the other port in that larb locate in the same bank.
*
* This is the suggested mapping in this SoC:
*
* modules iova-range larbs-ports
* display 0 ~ 4G larb0/1
* vcodec 4G ~ 8G larb4/5/7
* cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
* CCU0 0x2_4000_0000 ~ 0x2_43ff_ffff larb13: port 9/10
* CCU1 0x2_4400_0000 ~ 0x2_47ff_ffff larb14: port 4/5
*
* In this SoC, CCU have a special iova range requirement, that means
larb13/larb14 always need locate 8G ~ 16G.
*
*/
We list our limitation and suggesting. If someone would like adjust the
dma-ranges, then he should make sure it follow these rules and guarantee
the drivers works, I means If a iova-A comes from another iommu domain,
the master should map it again in its own domain to make sure the HW
works.
How about this? or still think the array is better?
About the command line, because I have fixed the CCU0/1 in 8G~12G in the
driver code, and this is possible to be adjusted in command-line. This
is only for larb13/14. and could be added when necessary.(currently I
think we no need this).
And in the code I will add 12 ~ 16G support.
>
> Best regards,
> Tomasz
>
> >
> > > And, after all, why waste the remaining 4G of address space?
> > >
> > > Best regards,
> > > Tomasz
> > >
> > > > >
> > > > > Best regards,
> > > > > Tomasz
> > > > >
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Tomasz
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > > Tomasz
> > > > > > > > >
> > > > > > > > > > 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
> > > > > > > > > > 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
> > > > > > > > > >
> > > > > > > > > > The iova range for CCU0/1(camera control unit) is HW requirement.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > > > > > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > > > > > > > ---
> > > > > > > > > > .../bindings/iommu/mediatek,iommu.yaml | 18 +-
> > > > > > > > > > include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
> > > > > > > > > > 2 files changed, 257 insertions(+), 1 deletion(-)
> > > > > > > > > > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> > > > > > > > > >
> > > > > > > > [snip]
> > > > > >
> > > >
> > >
> > > _______________________________________________
> > > Linux-mediatek mailing list
> > > Linux-mediatek@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
2021-01-29 11:45 ` Tomasz Figa
2021-02-01 5:36 ` Yong Wu
@ 2021-02-01 10:44 ` Robin Murphy
1 sibling, 0 replies; 56+ messages in thread
From: Robin Murphy @ 2021-02-01 10:44 UTC (permalink / raw)
To: Tomasz Figa, Yong Wu
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Linux Kernel Mailing List, Evan Green, chao.hao,
list@263.net:IOMMU DRIVERS, Rob Herring,
moderated list:ARM/Mediatek SoC support, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Will Deacon, linux-arm-kernel
On 2021-01-29 11:45, Tomasz Figa wrote:
> On Mon, Jan 25, 2021 at 4:34 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>
>> On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote:
>>> On Wed, Jan 20, 2021 at 4:08 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>>>
>>>> On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote:
>>>>> On Wed, Jan 13, 2021 at 3:45 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>>>>>
>>>>>> On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote:
>>>>>>> On Thu, Dec 24, 2020 at 8:35 PM Yong Wu <yong.wu@mediatek.com> wrote:
>>>>>>>>
>>>>>>>> On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote:
>>>>>>>>> On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
>>>>>>>>>> This patch adds decriptions for mt8192 IOMMU and SMI.
>>>>>>>>>>
>>>>>>>>>> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
>>>>>>>>>> table format. The M4U-SMI HW diagram is as below:
>>>>>>>>>>
>>>>>>>>>> EMI
>>>>>>>>>> |
>>>>>>>>>> M4U
>>>>>>>>>> |
>>>>>>>>>> ------------
>>>>>>>>>> SMI Common
>>>>>>>>>> ------------
>>>>>>>>>> |
>>>>>>>>>> +-------+------+------+----------------------+-------+
>>>>>>>>>> | | | | ...... | |
>>>>>>>>>> | | | | | |
>>>>>>>>>> larb0 larb1 larb2 larb4 ...... larb19 larb20
>>>>>>>>>> disp0 disp1 mdp vdec IPE IPE
>>>>>>>>>>
>>>>>>>>>> All the connections are HW fixed, SW can NOT adjust it.
>>>>>>>>>>
>>>>>>>>>> mt8192 M4U support 0~16GB iova range. we preassign different engines
>>>>>>>>>> into different iova ranges:
>>>>>>>>>>
>>>>>>>>>> domain-id module iova-range larbs
>>>>>>>>>> 0 disp 0 ~ 4G larb0/1
>>>>>>>>>> 1 vcodec 4G ~ 8G larb4/5/7
>>>>>>>>>> 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
>>>>>>>>>
>>>>>>>>> Why do we preassign these addresses in DT? Shouldn't it be a user's or
>>>>>>>>> integrator's decision to split the 16 GB address range into sub-ranges
>>>>>>>>> and define which larbs those sub-ranges are shared with?
>>>>>>>>
>>>>>>>> The problem is that we can't split the 16GB range with the larb as unit.
>>>>>>>> The example is the below ccu0(larb13 port9/10) is a independent
>>>>>>>> range(domain), the others ports in larb13 is in another domain.
>>>>>>>>
>>>>>>>> disp/vcodec/cam/mdp don't have special iova requirement, they could
>>>>>>>> access any range. vcodec also can locate 8G~12G. it don't care about
>>>>>>>> where its iova locate. here I preassign like this following with our
>>>>>>>> internal project setting.
>>>>>>>
>>>>>>> Let me try to understand this a bit more. Given the split you're
>>>>>>> proposing, is there actually any isolation enforced between particular
>>>>>>> domains? For example, if I program vcodec to with a DMA address from
>>>>>>> the 0-4G range, would the IOMMU actually generate a fault, even if
>>>>>>> disp had some memory mapped at that address?
>>>>>>
>>>>>> In this case. we will get fault in current SW setting.
>>>>>>
>>>>>
>>>>> Okay, thanks.
>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Why set this in DT?, this is only for simplifying the code. Assume we
>>>>>>>> put it in the platform data. We have up to 32 larbs, each larb has up to
>>>>>>>> 32 ports, each port may be in different iommu domains. we should have a
>>>>>>>> big array for this..however we only use a macro to get the domain in the
>>>>>>>> DT method.
>>>>>>>>
>>>>>>>> When replying this mail, I happen to see there is a "dev->dev_range_map"
>>>>>>>> which has "dma-range" information, I think I could use this value to get
>>>>>>>> which domain the device belong to. then no need put domid in DT. I will
>>>>>>>> test this.
>>>>>>>
>>>>>>> My feeling is that the only part that needs to be enforced statically
>>>>>>> is the reserved IOVA range for CCUs. The other ranges should be
>>>>>>> determined dynamically, although I think I need to understand better
>>>>>>> how the hardware and your proposed design work to tell what would be
>>>>>>> likely the best choice here.
>>>>>>
>>>>>> I have removed the domid patch in v6. and get the domain id in [27/33]
>>>>>> in v6..
>>>>>>
>>>>>> About the other ranges should be dynamical, the commit message [30/33]
>>>>>> of v6 should be helpful. the problem is that we have a bank_sel setting
>>>>>> for the iova[32:33]. currently we preassign this value. thus, all the
>>>>>> ranges are fixed. If you adjust this setting, you can let vcodec access
>>>>>> 0~4G.
>>>>>
>>>>> Okay, so it sounds like we effectively have four 4G address spaces and
>>>>> we can assign the master devices to them. I guess each of these
>>>>> address spaces makes for an IOMMU group.
>>>>
>>>> Yes. Each a address spaces is an IOMMU group.
>>>>
>>>>>
>>>>> It's fine to pre-assign the devices to those groups for now, but it
>>>>> definitely shouldn't be hardcoded in DT, because it depends on the use
>>>>> case of the device. I'll take a look at v6, but it sounds like it
>>>>> should be fine if it doesn't take the address space assignment from DT
>>>>> anymore.
>>>>
>>>> Thanks very much for your review.
>>>>
>>>
>>> Hmm, I had a look at v6 and it still has the address spaces hardcoded
>>> in the DTS.
>>
>> sorry. I didn't get here. where do you mean. or help reply in v6.
>>
>> I only added the preassign list as comment in the file
>> (dt-binding/memory/mt8192-larb-port.h). I thought our iommu consumer may
>> need it when they use these ports. they need add dma-ranges property if
>> its iova is over 4GB.
>
> That's exactly the problem. v6 simply replaced one way to describe the
> policy (domain ID) with another (dma-ranges). However, DT is not the
> right place to describe policies, because it's the place to describe
> hardware in a way agnostic from policies and use cases. In other
> words, DT must not impose using the hardware in one way or another.
>
> For example, we have two different companies that want to ship
> products based on this SoC - A and B. Company A may want to put MDP
> and camera in the same address space, but company B instead would
> prefer MDP to be in the same address space as video. Because this
> decision is stored in DT, one of them will have to change and rebuild
> their kernel and maintain a downstream patch.
Well, in most cases Company A and Company B will be building their own
products around the SoC, so will each have their own downstream DTS
anyway. Even if they're buying complete hardware from an OEM and just
shipping it with custom software configurations, it's still quite likely
that they'd have their own DTS tweaks for branding and possibly other
firmware-related things.
Also note that expected use-cases frequently *are* reflected in DT -
pretty much every use of the "linux,shared-dma-pool" reserved-memory
binding, for instance. In fact memory carveouts in general are usually
just software policy rather than any kind of hardware or firmware
description. There are also plenty of DT properties for actual hardware
that imply "this is how you need to configure me" rather than just "this
is what I can do", so the distinction between "describing the platform"
and "telling software what to do" isn't as clear-cut as we'd like it to be.
While I'm also not entirely convinced that "dma-ranges" is the perfect
tool for the job - as opposed to less abstraction via a larb property or
extra IOMMU specifier cell - it is at least descriptive to the DMA and
IOMMU subsystems as well as the driver, and can draw a direct parallel
to how some PCI host bridge drivers handle inbound windows. In many
cases those just need to be programmed *somehow*, so "dma-ranges" is set
in the DTS or inserted by the bootloader, and the kernel driver parses
that then programs the hardware to match. It seems like we're doing a
directly comparable thing here.
Robin.
> My suggestion to follow here would be to:
> - stop using dma-ranges for this purpose,
> - add an array in the MTK IOMMU driver that has a default map between
> larbs and domains, e.g.
>
> static u8 mt8192_domain_map[NUM_DOMAINS][NUM_LARBS] = {
> [0] = { 0 , 1, 0xff },
> [1] = { 4, 5, 7, 0xff },
> [2] = { 2, 9, 11, 13, 14, 16, 17, 18, 19, 20, 0xff },
> };
>
> - add a kernel command line parameter that allows overriding of this map, e.g.
>
> mtk_iommu.domain_map="0:0,1:1:4,5,7:2:2,9,11,13,14,16,17,18,19,20"
>
> would be equivalent to the array above. Same could be also given by a
> Kconfig entry if one can't or doesn't want to add extra command line
> parameters.
>
> Would something like this work?
>
>>
>>> Could we move the fixed assignment to the MTK IOMMU driver code instead,
>>> so that it can be easily adjusted as the kernel code
>>> evolves without the need to update the DTS?
>>>
>>>>>
>>>>>>
>>>>>> Currently we have no interface to adjust this setting. Suppose we add a
>>>>>> new interface for this. It would be something like:
>>>>>>
>>>>>> int mtk_smi_larb_config_banksel(struct device *larb, int banksel)
>>>>>>
>>>>>> Then, all the MM drivers should call it before the HW works every
>>>>>> time, and its implement will be a bit complex since we aren't sure if
>>>>>> the larb has power at that time. the important thing is that the MM
>>>>>> devices have already not known which larb it connects with as we plan to
>>>>>> delete "mediatek,larb" in their dtsi nodes.
>>>>>
>>>>> From the practical point of view, it doesn't look like setting this on
>>>>> a per-larb basis would make much sense. The reason to switch the
>>>>> bank_sel would be to decide which MM devices can share the same
>>>>> address space. This is a security aspect, because it effectively
>>>>> determines which devices are isolated from each other.
>>>>>
>>>>> That said, I agree that for now we can just start with a fixed
>>>>> assignment. We can think of the API if there is a need to adjust the
>>>>> assignment.
>>>>
>>>> Sorry for here. I forgot a thing here. that interface above still will
>>>> not be helpful. If we don't divide the whole 16GB ranges into 4
>>>> regions(let all the other ranges be dynamical), It won't work since we
>>>> can only adjust bank_sel with the larb as unit. This is a problem. there
>>>> are many ports in a larb. Take a example, the address for vcodec read
>>>> port is 32bits while the address for vcodec write port is 33bit, then it
>>>> will fail since we only have one bank_sel setting for one larb.
>>>
>>> That's exactly why I proposed to have the API operate based on the
>>> struct device, rather than individual DMA ports. Although I guess the
>>> CCU case is different, because it's the same larb as the camera.
>>>
>>> Anyway, I agree that we don't have to come up with such an API right now.
>>
>> Thanks for the confirm.
>>
>>>
>>>> Thus we
>>>> have to use current design.
>>>>
>>>>>
>>>>>>
>>>>>> In current design, the MM device don't need care about it and 4GB
>>>>>> range is enough for them.
>>>>>>
>>>>>
>>>>> Actually, is the current assignment correct?
>>>>
>>>> Oh. In the code (patch [32/33] of v6), I put CCU0/1 in the cam/mdp
>>>> region which start at 8G since CCU0/1 is a module of camera.
>>>>
>>>>>
>>>>> domain-id module iova-range larbs
>>>>> 0 disp 0 ~ 4G larb0/1
>>>>> 1 vcodec 4G ~ 8G larb4/5/7
>>>>> 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
>>>>> 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
>>>>> 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
>>>>>
>>>>> Wouldn't CCU0 and CCU1 conflict with disp?
>>>>
>>>> About the conflict, I use patch [29/33] of v6 for this. I will reserve
>>>> this special iova region when the full domain(0-4G in this example)
>>>> initialize.
>>>>
>>>>> Should perhaps disp be assigned 12G ~ 16G instead?
>>>>
>>>> I think no need put it to 12G-16G, In previous SoC, we have only 4GB
>>>> ranges for whole MM engines. currently only cam/mdp domain exclude 128M
>>>> for CCU. it should be something wrong if this is not enough.
>>>>
>>>
>>> Indeed, space is not a problem, but from the security point of view
>>> it's undesirable. I believe CCU would be running proprietary firmware,
>>> so it should be isolated as much as possible from other components.
>>
>> CCU are in the same larb with camera. Thus, it also need locate the same
>> iova range with camera.
>
> What are larb13 and larb14 used by besides CCU? Is it possible to put
> them in a separate address space from other camera larbs?
>
> Best regards,
> Tomasz
>
>>
>>> And, after all, why waste the remaining 4G of address space?
>>>
>>> Best regards,
>>> Tomasz
>>>
>>>>>
>>>>> Best regards,
>>>>> Tomasz
>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Tomasz
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Tomasz
>>>>>>>>>
>>>>>>>>>> 3 CCU0 0x4000_0000 ~ 0x43ff_ffff larb13: port 9/10
>>>>>>>>>> 4 CCU1 0x4400_0000 ~ 0x47ff_ffff larb14: port 4/5
>>>>>>>>>>
>>>>>>>>>> The iova range for CCU0/1(camera control unit) is HW requirement.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
>>>>>>>>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>>>>>>>>> ---
>>>>>>>>>> .../bindings/iommu/mediatek,iommu.yaml | 18 +-
>>>>>>>>>> include/dt-bindings/memory/mt8192-larb-port.h | 240 ++++++++++++++++++
>>>>>>>>>> 2 files changed, 257 insertions(+), 1 deletion(-)
>>>>>>>>>> create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
>>>>>>>>>>
>>>>>>>> [snip]
>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Linux-mediatek mailing list
>>> Linux-mediatek@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH v5 07/27] iommu/mediatek: Use the common mtk-smi-larb-port.h
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (5 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 08/27] iommu/io-pgtable-arm-v7s: Use ias to check the valid iova in unmap Yong Wu
` (19 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Use the common larb-port header in the source code.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/iommu/mtk_iommu.c | 7 -------
drivers/iommu/mtk_iommu.h | 1 +
drivers/memory/mtk-smi.c | 1 +
include/soc/mediatek/smi.h | 2 --
4 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c072cee532c2..6451d83753e1 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -103,13 +103,6 @@
#define MTK_PROTECT_PA_ALIGN 256
-/*
- * Get the local arbiter ID and the portid within the larb arbiter
- * from mtk_m4u_id which is defined by MTK_M4U_ID.
- */
-#define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0xf)
-#define MTK_M4U_TO_PORT(id) ((id) & 0x1f)
-
#define HAS_4GB_MODE BIT(0)
/* HW will use the EMI clock if there isn't the "bclk". */
#define HAS_BCLK BIT(1)
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index df32b3e3408b..d0c93652bdbe 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -17,6 +17,7 @@
#include <linux/spinlock.h>
#include <linux/dma-mapping.h>
#include <soc/mediatek/smi.h>
+#include <dt-bindings/memory/mtk-smi-larb-port.h>
#define MTK_LARB_COM_MAX 8
#define MTK_LARB_SUBCOM_MAX 4
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index ac350f8d1e20..2beb67908f3c 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -14,6 +14,7 @@
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <soc/mediatek/smi.h>
+#include <dt-bindings/memory/mtk-smi-larb-port.h>
#include <dt-bindings/memory/mt2701-larb-port.h>
/* mt8173 */
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 5a34b87d89e3..9371bf572ab8 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -11,8 +11,6 @@
#ifdef CONFIG_MTK_SMI
-#define MTK_LARB_NR_MAX 16
-
#define MTK_SMI_MMU_EN(port) BIT(port)
struct mtk_smi_larb_iommu {
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 08/27] iommu/io-pgtable-arm-v7s: Use ias to check the valid iova in unmap
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (6 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 07/27] iommu/mediatek: Use the common mtk-smi-larb-port.h Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 09/27] iommu/io-pgtable-arm-v7s: Extend PA34 for MediaTek Yong Wu
` (18 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Use the ias for the valid iova checking in arm_v7s_unmap. This is a
preparing patch for supporting iova 34bit for MediaTek.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm-v7s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index a688f22cbe3b..e880745ab1e8 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -717,7 +717,7 @@ static size_t arm_v7s_unmap(struct io_pgtable_ops *ops, unsigned long iova,
{
struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
- if (WARN_ON(upper_32_bits(iova)))
+ if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias)))
return 0;
return __arm_v7s_unmap(data, gather, iova, size, 1, data->pgd);
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 09/27] iommu/io-pgtable-arm-v7s: Extend PA34 for MediaTek
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (7 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 08/27] iommu/io-pgtable-arm-v7s: Use ias to check the valid iova in unmap Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-23 8:20 ` Tomasz Figa
2020-12-09 8:00 ` [PATCH v5 10/27] iommu/io-pgtable-arm-v7s: Clarify LVL_SHIFT/BITS macro Yong Wu
` (17 subsequent siblings)
26 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Will Deacon <will@kernel.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm-v7s.c | 9 +++++++--
drivers/iommu/mtk_iommu.c | 2 +-
include/linux/io-pgtable.h | 4 ++--
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index e880745ab1e8..4d0aa079470f 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -112,9 +112,10 @@
#define ARM_V7S_TEX_MASK 0x7
#define ARM_V7S_ATTR_TEX(val) (((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
-/* MediaTek extend the two bits for PA 32bit/33bit */
+/* MediaTek extend the bits below for PA 32bit/33bit/34bit */
#define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
#define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
+#define ARM_V7S_ATTR_MTK_PA_BIT34 BIT(5)
/* *well, except for TEX on level 2 large pages, of course :( */
#define ARM_V7S_CONT_PAGE_TEX_SHIFT 6
@@ -194,6 +195,8 @@ static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
if (paddr & BIT_ULL(33))
pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ if (paddr & BIT_ULL(34))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT34;
return pte;
}
@@ -218,6 +221,8 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
paddr |= BIT_ULL(32);
if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
paddr |= BIT_ULL(33);
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT34)
+ paddr |= BIT_ULL(34);
return paddr;
}
@@ -754,7 +759,7 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
if (cfg->ias > ARM_V7S_ADDR_BITS)
return NULL;
- if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
+ if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 35 : ARM_V7S_ADDR_BITS))
return NULL;
if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6451d83753e1..ec3c87d4b172 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -320,7 +320,7 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom)
IO_PGTABLE_QUIRK_ARM_MTK_EXT,
.pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
.ias = 32,
- .oas = 34,
+ .oas = 35,
.tlb = &mtk_iommu_flush_ops,
.iommu_dev = data->dev,
};
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 4cde111e425b..1ae0757f4f94 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -77,8 +77,8 @@ struct io_pgtable_cfg {
* TLB maintenance when mapping as well as when unmapping.
*
* IO_PGTABLE_QUIRK_ARM_MTK_EXT: (ARM v7s format) MediaTek IOMMUs extend
- * to support up to 34 bits PA where the bit32 and bit33 are
- * encoded in the bit9 and bit4 of the PTE respectively.
+ * to support up to 35 bits PA where the bit32, bit33 and bit34 are
+ * encoded in the bit9, bit4 and bit5 of the PTE respectively.
*
* IO_PGTABLE_QUIRK_NON_STRICT: Skip issuing synchronous leaf TLBIs
* on unmap, for DMA domains using the flush queue mechanism for
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [PATCH v5 09/27] iommu/io-pgtable-arm-v7s: Extend PA34 for MediaTek
2020-12-09 8:00 ` [PATCH v5 09/27] iommu/io-pgtable-arm-v7s: Extend PA34 for MediaTek Yong Wu
@ 2020-12-23 8:20 ` Tomasz Figa
2020-12-29 11:17 ` Yong Wu
0 siblings, 1 reply; 56+ messages in thread
From: Tomasz Figa @ 2020-12-23 8:20 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, Dec 09, 2020 at 04:00:44PM +0800, Yong Wu wrote:
> MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> Acked-by: Will Deacon <will@kernel.org>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/io-pgtable-arm-v7s.c | 9 +++++++--
> drivers/iommu/mtk_iommu.c | 2 +-
> include/linux/io-pgtable.h | 4 ++--
> 3 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> index e880745ab1e8..4d0aa079470f 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -112,9 +112,10 @@
> #define ARM_V7S_TEX_MASK 0x7
> #define ARM_V7S_ATTR_TEX(val) (((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
>
> -/* MediaTek extend the two bits for PA 32bit/33bit */
> +/* MediaTek extend the bits below for PA 32bit/33bit/34bit */
> #define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
> #define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
> +#define ARM_V7S_ATTR_MTK_PA_BIT34 BIT(5)
>
> /* *well, except for TEX on level 2 large pages, of course :( */
> #define ARM_V7S_CONT_PAGE_TEX_SHIFT 6
> @@ -194,6 +195,8 @@ static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
> pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
> if (paddr & BIT_ULL(33))
> pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
> + if (paddr & BIT_ULL(34))
> + pte |= ARM_V7S_ATTR_MTK_PA_BIT34;
> return pte;
> }
>
> @@ -218,6 +221,8 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
> paddr |= BIT_ULL(32);
> if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
> paddr |= BIT_ULL(33);
> + if (pte & ARM_V7S_ATTR_MTK_PA_BIT34)
> + paddr |= BIT_ULL(34);
> return paddr;
> }
>
> @@ -754,7 +759,7 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
> if (cfg->ias > ARM_V7S_ADDR_BITS)
> return NULL;
>
> - if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
> + if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 35 : ARM_V7S_ADDR_BITS))
> return NULL;
>
> if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 6451d83753e1..ec3c87d4b172 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -320,7 +320,7 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom)
> IO_PGTABLE_QUIRK_ARM_MTK_EXT,
> .pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
> .ias = 32,
> - .oas = 34,
> + .oas = 35,
Shouldn't this be set according to the real hardware capabilities,
instead of always setting it to 35?
Best regards,
Tomasz
> .tlb = &mtk_iommu_flush_ops,
> .iommu_dev = data->dev,
> };
> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
> index 4cde111e425b..1ae0757f4f94 100644
> --- a/include/linux/io-pgtable.h
> +++ b/include/linux/io-pgtable.h
> @@ -77,8 +77,8 @@ struct io_pgtable_cfg {
> * TLB maintenance when mapping as well as when unmapping.
> *
> * IO_PGTABLE_QUIRK_ARM_MTK_EXT: (ARM v7s format) MediaTek IOMMUs extend
> - * to support up to 34 bits PA where the bit32 and bit33 are
> - * encoded in the bit9 and bit4 of the PTE respectively.
> + * to support up to 35 bits PA where the bit32, bit33 and bit34 are
> + * encoded in the bit9, bit4 and bit5 of the PTE respectively.
> *
> * IO_PGTABLE_QUIRK_NON_STRICT: Skip issuing synchronous leaf TLBIs
> * on unmap, for DMA domains using the flush queue mechanism for
> --
> 2.18.0
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [PATCH v5 09/27] iommu/io-pgtable-arm-v7s: Extend PA34 for MediaTek
2020-12-23 8:20 ` Tomasz Figa
@ 2020-12-29 11:17 ` Yong Wu
0 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-29 11:17 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, 2020-12-23 at 17:20 +0900, Tomasz Figa wrote:
> On Wed, Dec 09, 2020 at 04:00:44PM +0800, Yong Wu wrote:
> > MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34.
> >
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > Acked-by: Will Deacon <will@kernel.org>
> > Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> > ---
> > drivers/iommu/io-pgtable-arm-v7s.c | 9 +++++++--
> > drivers/iommu/mtk_iommu.c | 2 +-
> > include/linux/io-pgtable.h | 4 ++--
> > 3 files changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> > index e880745ab1e8..4d0aa079470f 100644
> > --- a/drivers/iommu/io-pgtable-arm-v7s.c
> > +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> > @@ -112,9 +112,10 @@
> > #define ARM_V7S_TEX_MASK 0x7
> > #define ARM_V7S_ATTR_TEX(val) (((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
> >
> > -/* MediaTek extend the two bits for PA 32bit/33bit */
> > +/* MediaTek extend the bits below for PA 32bit/33bit/34bit */
> > #define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
> > #define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
> > +#define ARM_V7S_ATTR_MTK_PA_BIT34 BIT(5)
> >
> > /* *well, except for TEX on level 2 large pages, of course :( */
> > #define ARM_V7S_CONT_PAGE_TEX_SHIFT 6
> > @@ -194,6 +195,8 @@ static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
> > pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
> > if (paddr & BIT_ULL(33))
> > pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
> > + if (paddr & BIT_ULL(34))
> > + pte |= ARM_V7S_ATTR_MTK_PA_BIT34;
> > return pte;
> > }
> >
> > @@ -218,6 +221,8 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
> > paddr |= BIT_ULL(32);
> > if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
> > paddr |= BIT_ULL(33);
> > + if (pte & ARM_V7S_ATTR_MTK_PA_BIT34)
> > + paddr |= BIT_ULL(34);
> > return paddr;
> > }
> >
> > @@ -754,7 +759,7 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
> > if (cfg->ias > ARM_V7S_ADDR_BITS)
> > return NULL;
> >
> > - if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
> > + if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 35 : ARM_V7S_ADDR_BITS))
> > return NULL;
> >
> > if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 6451d83753e1..ec3c87d4b172 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -320,7 +320,7 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom)
> > IO_PGTABLE_QUIRK_ARM_MTK_EXT,
> > .pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
> > .ias = 32,
> > - .oas = 34,
> > + .oas = 35,
>
> Shouldn't this be set according to the real hardware capabilities,
> instead of always setting it to 35?
Here only make the code clean. 35 is ok for all the SoC.
But you are right from the HW point, the logic is like this:
if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
dom->cfg.oas = data->enable_4GB ? 33 : 32;
else
dom->cfg.oas = 35;
I will use this in next version.
>
> Best regards,
> Tomasz
>
> > .tlb = &mtk_iommu_flush_ops,
> > .iommu_dev = data->dev,
> > };
> > diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
> > index 4cde111e425b..1ae0757f4f94 100644
> > --- a/include/linux/io-pgtable.h
> > +++ b/include/linux/io-pgtable.h
> > @@ -77,8 +77,8 @@ struct io_pgtable_cfg {
> > * TLB maintenance when mapping as well as when unmapping.
> > *
> > * IO_PGTABLE_QUIRK_ARM_MTK_EXT: (ARM v7s format) MediaTek IOMMUs extend
> > - * to support up to 34 bits PA where the bit32 and bit33 are
> > - * encoded in the bit9 and bit4 of the PTE respectively.
> > + * to support up to 35 bits PA where the bit32, bit33 and bit34 are
> > + * encoded in the bit9, bit4 and bit5 of the PTE respectively.
> > *
> > * IO_PGTABLE_QUIRK_NON_STRICT: Skip issuing synchronous leaf TLBIs
> > * on unmap, for DMA domains using the flush queue mechanism for
> > --
> > 2.18.0
> >
> > _______________________________________________
> > iommu mailing list
> > iommu@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH v5 10/27] iommu/io-pgtable-arm-v7s: Clarify LVL_SHIFT/BITS macro
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (8 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 09/27] iommu/io-pgtable-arm-v7s: Extend PA34 for MediaTek Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 11/27] iommu/io-pgtable-arm-v7s: Add cfg as a param in some macros Yong Wu
` (16 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
The current _ARM_V7S_LVL_BITS/ARM_V7S_LVL_SHIFT use a formula to calculate
the corresponding value for level1 and level2 to pretend the code sane.
Actually their level1 and level2 values are different from each other.
This patch only clarify the two macro. No functional change.
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm-v7s.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 4d0aa079470f..58cc201c10a3 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -44,13 +44,11 @@
/*
* We have 32 bits total; 12 bits resolved at level 1, 8 bits at level 2,
- * and 12 bits in a page. With some carefully-chosen coefficients we can
- * hide the ugly inconsistencies behind these macros and at least let the
- * rest of the code pretend to be somewhat sane.
+ * and 12 bits in a page.
*/
#define ARM_V7S_ADDR_BITS 32
-#define _ARM_V7S_LVL_BITS(lvl) (16 - (lvl) * 4)
-#define ARM_V7S_LVL_SHIFT(lvl) (ARM_V7S_ADDR_BITS - (4 + 8 * (lvl)))
+#define _ARM_V7S_LVL_BITS(lvl) ((lvl) == 1 ? 12 : 8)
+#define ARM_V7S_LVL_SHIFT(lvl) ((lvl) == 1 ? 20 : 12)
#define ARM_V7S_TABLE_SHIFT 10
#define ARM_V7S_PTES_PER_LVL(lvl) (1 << _ARM_V7S_LVL_BITS(lvl))
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 11/27] iommu/io-pgtable-arm-v7s: Add cfg as a param in some macros
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (9 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 10/27] iommu/io-pgtable-arm-v7s: Clarify LVL_SHIFT/BITS macro Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 12/27] iommu/io-pgtable-arm-v7s: Quad lvl1 pgtable for MediaTek Yong Wu
` (15 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Add "cfg" as a parameter for some macros. This is a preparing patch for
mediatek extend the lvl1 pgtable. No functional change.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Will Deacon <will@kernel.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm-v7s.c | 36 +++++++++++++++---------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 58cc201c10a3..0b3c5b904ddc 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -47,21 +47,21 @@
* and 12 bits in a page.
*/
#define ARM_V7S_ADDR_BITS 32
-#define _ARM_V7S_LVL_BITS(lvl) ((lvl) == 1 ? 12 : 8)
+#define _ARM_V7S_LVL_BITS(lvl, cfg) ((lvl) == 1 ? 12 : 8)
#define ARM_V7S_LVL_SHIFT(lvl) ((lvl) == 1 ? 20 : 12)
#define ARM_V7S_TABLE_SHIFT 10
-#define ARM_V7S_PTES_PER_LVL(lvl) (1 << _ARM_V7S_LVL_BITS(lvl))
-#define ARM_V7S_TABLE_SIZE(lvl) \
- (ARM_V7S_PTES_PER_LVL(lvl) * sizeof(arm_v7s_iopte))
+#define ARM_V7S_PTES_PER_LVL(lvl, cfg) (1 << _ARM_V7S_LVL_BITS(lvl, cfg))
+#define ARM_V7S_TABLE_SIZE(lvl, cfg) \
+ (ARM_V7S_PTES_PER_LVL(lvl, cfg) * sizeof(arm_v7s_iopte))
#define ARM_V7S_BLOCK_SIZE(lvl) (1UL << ARM_V7S_LVL_SHIFT(lvl))
#define ARM_V7S_LVL_MASK(lvl) ((u32)(~0U << ARM_V7S_LVL_SHIFT(lvl)))
#define ARM_V7S_TABLE_MASK ((u32)(~0U << ARM_V7S_TABLE_SHIFT))
-#define _ARM_V7S_IDX_MASK(lvl) (ARM_V7S_PTES_PER_LVL(lvl) - 1)
-#define ARM_V7S_LVL_IDX(addr, lvl) ({ \
+#define _ARM_V7S_IDX_MASK(lvl, cfg) (ARM_V7S_PTES_PER_LVL(lvl, cfg) - 1)
+#define ARM_V7S_LVL_IDX(addr, lvl, cfg) ({ \
int _l = lvl; \
- ((u32)(addr) >> ARM_V7S_LVL_SHIFT(_l)) & _ARM_V7S_IDX_MASK(_l); \
+ ((u32)(addr) >> ARM_V7S_LVL_SHIFT(_l)) & _ARM_V7S_IDX_MASK(_l, cfg); \
})
/*
@@ -237,7 +237,7 @@ static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
struct device *dev = cfg->iommu_dev;
phys_addr_t phys;
dma_addr_t dma;
- size_t size = ARM_V7S_TABLE_SIZE(lvl);
+ size_t size = ARM_V7S_TABLE_SIZE(lvl, cfg);
void *table = NULL;
if (lvl == 1)
@@ -283,7 +283,7 @@ static void __arm_v7s_free_table(void *table, int lvl,
{
struct io_pgtable_cfg *cfg = &data->iop.cfg;
struct device *dev = cfg->iommu_dev;
- size_t size = ARM_V7S_TABLE_SIZE(lvl);
+ size_t size = ARM_V7S_TABLE_SIZE(lvl, cfg);
if (!cfg->coherent_walk)
dma_unmap_single(dev, __arm_v7s_dma_addr(table), size,
@@ -427,7 +427,7 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
arm_v7s_iopte *tblp;
size_t sz = ARM_V7S_BLOCK_SIZE(lvl);
- tblp = ptep - ARM_V7S_LVL_IDX(iova, lvl);
+ tblp = ptep - ARM_V7S_LVL_IDX(iova, lvl, cfg);
if (WARN_ON(__arm_v7s_unmap(data, NULL, iova + i * sz,
sz, lvl, tblp) != sz))
return -EINVAL;
@@ -480,7 +480,7 @@ static int __arm_v7s_map(struct arm_v7s_io_pgtable *data, unsigned long iova,
int num_entries = size >> ARM_V7S_LVL_SHIFT(lvl);
/* Find our entry at the current level */
- ptep += ARM_V7S_LVL_IDX(iova, lvl);
+ ptep += ARM_V7S_LVL_IDX(iova, lvl, cfg);
/* If we can install a leaf entry at this level, then do so */
if (num_entries)
@@ -553,7 +553,7 @@ static void arm_v7s_free_pgtable(struct io_pgtable *iop)
struct arm_v7s_io_pgtable *data = io_pgtable_to_data(iop);
int i;
- for (i = 0; i < ARM_V7S_PTES_PER_LVL(1); i++) {
+ for (i = 0; i < ARM_V7S_PTES_PER_LVL(1, &data->iop.cfg); i++) {
arm_v7s_iopte pte = data->pgd[i];
if (ARM_V7S_PTE_IS_TABLE(pte, 1))
@@ -605,9 +605,9 @@ static size_t arm_v7s_split_blk_unmap(struct arm_v7s_io_pgtable *data,
if (!tablep)
return 0; /* Bytes unmapped */
- num_ptes = ARM_V7S_PTES_PER_LVL(2);
+ num_ptes = ARM_V7S_PTES_PER_LVL(2, cfg);
num_entries = size >> ARM_V7S_LVL_SHIFT(2);
- unmap_idx = ARM_V7S_LVL_IDX(iova, 2);
+ unmap_idx = ARM_V7S_LVL_IDX(iova, 2, cfg);
pte = arm_v7s_prot_to_pte(arm_v7s_pte_to_prot(blk_pte, 1), 2, cfg);
if (num_entries > 1)
@@ -649,7 +649,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable *data,
if (WARN_ON(lvl > 2))
return 0;
- idx = ARM_V7S_LVL_IDX(iova, lvl);
+ idx = ARM_V7S_LVL_IDX(iova, lvl, &iop->cfg);
ptep += idx;
do {
pte[i] = READ_ONCE(ptep[i]);
@@ -735,7 +735,7 @@ static phys_addr_t arm_v7s_iova_to_phys(struct io_pgtable_ops *ops,
u32 mask;
do {
- ptep += ARM_V7S_LVL_IDX(iova, ++lvl);
+ ptep += ARM_V7S_LVL_IDX(iova, ++lvl, &data->iop.cfg);
pte = READ_ONCE(*ptep);
ptep = iopte_deref(pte, lvl, data);
} while (ARM_V7S_PTE_IS_TABLE(pte, lvl));
@@ -778,8 +778,8 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
spin_lock_init(&data->split_lock);
data->l2_tables = kmem_cache_create("io-pgtable_armv7s_l2",
- ARM_V7S_TABLE_SIZE(2),
- ARM_V7S_TABLE_SIZE(2),
+ ARM_V7S_TABLE_SIZE(2, cfg),
+ ARM_V7S_TABLE_SIZE(2, cfg),
ARM_V7S_TABLE_SLAB_FLAGS, NULL);
if (!data->l2_tables)
goto out_free_data;
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 12/27] iommu/io-pgtable-arm-v7s: Quad lvl1 pgtable for MediaTek
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (10 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 11/27] iommu/io-pgtable-arm-v7s: Add cfg as a param in some macros Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 13/27] iommu/mediatek: Add a flag for iova_34 bit case Yong Wu
` (14 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
The standard input iova bits is 32. MediaTek quad the lvl1 pagetable
(4 * lvl1). No change for lvl2 pagetable. Then the iova bits can reach
34bit.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm-v7s.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 0b3c5b904ddc..5601dc8bf810 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -45,9 +45,10 @@
/*
* We have 32 bits total; 12 bits resolved at level 1, 8 bits at level 2,
* and 12 bits in a page.
+ * MediaTek extend 2 bits to reach 34bits, 14 bits at lvl1 and 8 bits at lvl2.
*/
#define ARM_V7S_ADDR_BITS 32
-#define _ARM_V7S_LVL_BITS(lvl, cfg) ((lvl) == 1 ? 12 : 8)
+#define _ARM_V7S_LVL_BITS(lvl, cfg) ((lvl) == 1 ? ((cfg)->ias - 20) : 8)
#define ARM_V7S_LVL_SHIFT(lvl) ((lvl) == 1 ? 20 : 12)
#define ARM_V7S_TABLE_SHIFT 10
@@ -61,7 +62,7 @@
#define _ARM_V7S_IDX_MASK(lvl, cfg) (ARM_V7S_PTES_PER_LVL(lvl, cfg) - 1)
#define ARM_V7S_LVL_IDX(addr, lvl, cfg) ({ \
int _l = lvl; \
- ((u32)(addr) >> ARM_V7S_LVL_SHIFT(_l)) & _ARM_V7S_IDX_MASK(_l, cfg); \
+ ((addr) >> ARM_V7S_LVL_SHIFT(_l)) & _ARM_V7S_IDX_MASK(_l, cfg); \
})
/*
@@ -754,7 +755,7 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
{
struct arm_v7s_io_pgtable *data;
- if (cfg->ias > ARM_V7S_ADDR_BITS)
+ if (cfg->ias > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
return NULL;
if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 35 : ARM_V7S_ADDR_BITS))
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 13/27] iommu/mediatek: Add a flag for iova_34 bit case
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (11 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 12/27] iommu/io-pgtable-arm-v7s: Quad lvl1 pgtable for MediaTek Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 14/27] iommu/mediatek: Move hw_init into attach_device Yong Wu
` (13 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Add a HW flag for if the HW support 34bit IOVA. the previous SoC
still use 32bit. normally the lvl1 pgtable size is 16KB when ias == 32.
if ias == 34, lvl1 pgtable size is 16KB * 4. The purpose of this patch
is to save 16KB*3 continuous memory for the previous SoC.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index ec3c87d4b172..1bc5e881951c 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -112,6 +112,7 @@
#define HAS_SUB_COMM BIT(5)
#define WR_THROT_EN BIT(6)
#define HAS_LEGACY_IVRP_PADDR BIT(7)
+#define IOVA_34_EN BIT(8)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
((((pdata)->flags) & (_x)) == (_x))
@@ -319,7 +320,7 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom)
IO_PGTABLE_QUIRK_TLBI_ON_MAP |
IO_PGTABLE_QUIRK_ARM_MTK_EXT,
.pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
- .ias = 32,
+ .ias = MTK_IOMMU_HAS_FLAG(data->plat_data, IOVA_34_EN) ? 34 : 32,
.oas = 35,
.tlb = &mtk_iommu_flush_ops,
.iommu_dev = data->dev,
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 14/27] iommu/mediatek: Move hw_init into attach_device
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (12 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 13/27] iommu/mediatek: Add a flag for iova_34 bit case Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 15/27] iommu/mediatek: Add fail handle for sysfs_add and device_register Yong Wu
` (12 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
In attach device, it will update the pagetable base address register.
Move the hw_init function also here. Then it only need call
pm_runtime_get/put one time here if m4u has power domain.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 1bc5e881951c..39478cfbe0f1 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -126,6 +126,8 @@ struct mtk_iommu_domain {
static const struct iommu_ops mtk_iommu_ops;
+static int mtk_iommu_hw_init(const struct mtk_iommu_data *data);
+
/*
* In M4U 4GB mode, the physical address is remapped as below:
*
@@ -381,12 +383,16 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
{
struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+ int ret;
if (!data)
return -ENODEV;
/* Update the pgtable base address register of the M4U HW */
if (!data->m4u_dom) {
+ ret = mtk_iommu_hw_init(data);
+ if (ret)
+ return ret;
data->m4u_dom = dom;
writel(dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK,
data->base + REG_MMU_PT_BASE_ADDR);
@@ -730,10 +736,6 @@ static int mtk_iommu_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
- ret = mtk_iommu_hw_init(data);
- if (ret)
- return ret;
-
ret = iommu_device_sysfs_add(&data->iommu, dev, NULL,
"mtk-iommu.%pa", &ioaddr);
if (ret)
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 15/27] iommu/mediatek: Add fail handle for sysfs_add and device_register
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (13 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 14/27] iommu/mediatek: Move hw_init into attach_device Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-23 8:25 ` Tomasz Figa
2020-12-09 8:00 ` [PATCH v5 16/27] iommu/mediatek: Add device link for smi-common and m4u Yong Wu
` (11 subsequent siblings)
26 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Add fail handle for iommu_device_sysfs_add and iommu_device_register.
Fixes: b16c0170b53c ("iommu/mediatek: Make use of iommu_device_register interface")
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 39478cfbe0f1..09c8c58feb78 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -746,7 +746,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
ret = iommu_device_register(&data->iommu);
if (ret)
- return ret;
+ goto out_sysfs_remove;
spin_lock_init(&data->tlb_lock);
list_add_tail(&data->list, &m4ulist);
@@ -754,7 +754,16 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (!iommu_present(&platform_bus_type))
bus_set_iommu(&platform_bus_type, &mtk_iommu_ops);
- return component_master_add_with_match(dev, &mtk_iommu_com_ops, match);
+ ret = component_master_add_with_match(dev, &mtk_iommu_com_ops, match);
+ if (ret)
+ goto out_dev_unreg;
+ return ret;
+
+out_dev_unreg:
+ iommu_device_unregister(&data->iommu);
+out_sysfs_remove:
+ iommu_device_sysfs_remove(&data->iommu);
+ return ret;
}
static int mtk_iommu_remove(struct platform_device *pdev)
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [PATCH v5 15/27] iommu/mediatek: Add fail handle for sysfs_add and device_register
2020-12-09 8:00 ` [PATCH v5 15/27] iommu/mediatek: Add fail handle for sysfs_add and device_register Yong Wu
@ 2020-12-23 8:25 ` Tomasz Figa
2020-12-29 11:00 ` Yong Wu
0 siblings, 1 reply; 56+ messages in thread
From: Tomasz Figa @ 2020-12-23 8:25 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, Dec 09, 2020 at 04:00:50PM +0800, Yong Wu wrote:
> Add fail handle for iommu_device_sysfs_add and iommu_device_register.
>
> Fixes: b16c0170b53c ("iommu/mediatek: Make use of iommu_device_register interface")
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 39478cfbe0f1..09c8c58feb78 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -746,7 +746,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>
> ret = iommu_device_register(&data->iommu);
> if (ret)
> - return ret;
> + goto out_sysfs_remove;
>
> spin_lock_init(&data->tlb_lock);
> list_add_tail(&data->list, &m4ulist);
> @@ -754,7 +754,16 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (!iommu_present(&platform_bus_type))
> bus_set_iommu(&platform_bus_type, &mtk_iommu_ops);
>
> - return component_master_add_with_match(dev, &mtk_iommu_com_ops, match);
> + ret = component_master_add_with_match(dev, &mtk_iommu_com_ops, match);
> + if (ret)
> + goto out_dev_unreg;
> + return ret;
> +
> +out_dev_unreg:
Shouldn't other operations be undone as well? I can see that above
bus_set_iommu() is set and an entry is added to m4ulist.
> + iommu_device_unregister(&data->iommu);
> +out_sysfs_remove:
> + iommu_device_sysfs_remove(&data->iommu);
> + return ret;
> }
>
> static int mtk_iommu_remove(struct platform_device *pdev)
> --
> 2.18.0
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [PATCH v5 15/27] iommu/mediatek: Add fail handle for sysfs_add and device_register
2020-12-23 8:25 ` Tomasz Figa
@ 2020-12-29 11:00 ` Yong Wu
0 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-29 11:00 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, 2020-12-23 at 17:25 +0900, Tomasz Figa wrote:
> On Wed, Dec 09, 2020 at 04:00:50PM +0800, Yong Wu wrote:
> > Add fail handle for iommu_device_sysfs_add and iommu_device_register.
> >
> > Fixes: b16c0170b53c ("iommu/mediatek: Make use of iommu_device_register interface")
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 13 +++++++++++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 39478cfbe0f1..09c8c58feb78 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -746,7 +746,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> >
> > ret = iommu_device_register(&data->iommu);
> > if (ret)
> > - return ret;
> > + goto out_sysfs_remove;
> >
> > spin_lock_init(&data->tlb_lock);
> > list_add_tail(&data->list, &m4ulist);
> > @@ -754,7 +754,16 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> > if (!iommu_present(&platform_bus_type))
> > bus_set_iommu(&platform_bus_type, &mtk_iommu_ops);
> >
> > - return component_master_add_with_match(dev, &mtk_iommu_com_ops, match);
> > + ret = component_master_add_with_match(dev, &mtk_iommu_com_ops, match);
> > + if (ret)
> > + goto out_dev_unreg;
> > + return ret;
> > +
> > +out_dev_unreg:
>
> Shouldn't other operations be undone as well? I can see that above
> bus_set_iommu() is set and an entry is added to m4ulist.
Oh. Yes. I will add them. and remove the fixes tag since they are not
introduced by it. these error handle are not added in the first version.
>
> > + iommu_device_unregister(&data->iommu);
> > +out_sysfs_remove:
> > + iommu_device_sysfs_remove(&data->iommu);
> > + return ret;
> > }
> >
> > static int mtk_iommu_remove(struct platform_device *pdev)
> > --
> > 2.18.0
> >
> > _______________________________________________
> > iommu mailing list
> > iommu@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH v5 16/27] iommu/mediatek: Add device link for smi-common and m4u
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (14 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 15/27] iommu/mediatek: Add fail handle for sysfs_add and device_register Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-23 8:29 ` Tomasz Figa
2020-12-09 8:00 ` [PATCH v5 17/27] iommu/mediatek: Add pm runtime callback Yong Wu
` (10 subsequent siblings)
26 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
In the lastest SoC, M4U has its special power domain. thus, If the engine
begin to work, it should help enable the power for M4U firstly.
Currently if the engine work, it always enable the power/clocks for
smi-larbs/smi-common. This patch adds device_link for smi-common and M4U.
then, if smi-common power is enabled, the M4U power also is powered on
automatically.
Normally M4U connect with several smi-larbs and their smi-common always
are the same, In this patch it get smi-common dev from the first smi-larb
device(i==0), then add the device_link only while m4u has power-domain.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 30 ++++++++++++++++++++++++++++--
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 09c8c58feb78..5614015e5b96 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -20,6 +20,7 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -706,7 +707,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return larb_nr;
for (i = 0; i < larb_nr; i++) {
- struct device_node *larbnode;
+ struct device_node *larbnode, *smicomm_node;
struct platform_device *plarbdev;
u32 id;
@@ -732,6 +733,26 @@ static int mtk_iommu_probe(struct platform_device *pdev)
component_match_add_release(dev, &match, release_of,
compare_of, larbnode);
+ if (i != 0)
+ continue;
+ smicomm_node = of_parse_phandle(larbnode, "mediatek,smi", 0);
+ if (!smicomm_node)
+ return -EINVAL;
+
+ plarbdev = of_find_device_by_node(smicomm_node);
+ of_node_put(smicomm_node);
+ data->smicomm_dev = &plarbdev->dev;
+ }
+
+ if (dev->pm_domain) {
+ struct device_link *link;
+
+ link = device_link_add(data->smicomm_dev, dev,
+ DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
+ if (!link) {
+ dev_err(dev, "Unable link %s.\n", dev_name(data->smicomm_dev));
+ return -EINVAL;
+ }
}
platform_set_drvdata(pdev, data);
@@ -739,7 +760,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
ret = iommu_device_sysfs_add(&data->iommu, dev, NULL,
"mtk-iommu.%pa", &ioaddr);
if (ret)
- return ret;
+ goto out_link_remove;
iommu_device_set_ops(&data->iommu, &mtk_iommu_ops);
iommu_device_set_fwnode(&data->iommu, &pdev->dev.of_node->fwnode);
@@ -763,6 +784,9 @@ static int mtk_iommu_probe(struct platform_device *pdev)
iommu_device_unregister(&data->iommu);
out_sysfs_remove:
iommu_device_sysfs_remove(&data->iommu);
+out_link_remove:
+ if (dev->pm_domain)
+ device_link_remove(data->smicomm_dev, dev);
return ret;
}
@@ -777,6 +801,8 @@ static int mtk_iommu_remove(struct platform_device *pdev)
bus_set_iommu(&platform_bus_type, NULL);
clk_disable_unprepare(data->bclk);
+ if (pdev->dev.pm_domain)
+ device_link_remove(data->smicomm_dev, &pdev->dev);
devm_free_irq(&pdev->dev, data->irq, data);
component_master_del(&pdev->dev, &mtk_iommu_com_ops);
return 0;
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index d0c93652bdbe..5e03a029c4dc 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -68,6 +68,7 @@ struct mtk_iommu_data {
struct iommu_device iommu;
const struct mtk_iommu_plat_data *plat_data;
+ struct device *smicomm_dev;
struct dma_iommu_mapping *mapping; /* For mtk_iommu_v1.c */
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [PATCH v5 16/27] iommu/mediatek: Add device link for smi-common and m4u
2020-12-09 8:00 ` [PATCH v5 16/27] iommu/mediatek: Add device link for smi-common and m4u Yong Wu
@ 2020-12-23 8:29 ` Tomasz Figa
2020-12-29 11:25 ` Yong Wu
0 siblings, 1 reply; 56+ messages in thread
From: Tomasz Figa @ 2020-12-23 8:29 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, Dec 09, 2020 at 04:00:51PM +0800, Yong Wu wrote:
> In the lastest SoC, M4U has its special power domain. thus, If the engine
> begin to work, it should help enable the power for M4U firstly.
> Currently if the engine work, it always enable the power/clocks for
> smi-larbs/smi-common. This patch adds device_link for smi-common and M4U.
> then, if smi-common power is enabled, the M4U power also is powered on
> automatically.
>
> Normally M4U connect with several smi-larbs and their smi-common always
> are the same, In this patch it get smi-common dev from the first smi-larb
> device(i==0), then add the device_link only while m4u has power-domain.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 30 ++++++++++++++++++++++++++++--
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 09c8c58feb78..5614015e5b96 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -20,6 +20,7 @@
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> #include <linux/regmap.h>
> #include <linux/slab.h>
> #include <linux/spinlock.h>
> @@ -706,7 +707,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> return larb_nr;
>
> for (i = 0; i < larb_nr; i++) {
> - struct device_node *larbnode;
> + struct device_node *larbnode, *smicomm_node;
> struct platform_device *plarbdev;
> u32 id;
>
> @@ -732,6 +733,26 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>
> component_match_add_release(dev, &match, release_of,
> compare_of, larbnode);
> + if (i != 0)
> + continue;
How about using the last larb instead and moving the code below outside
of the loop?
> + smicomm_node = of_parse_phandle(larbnode, "mediatek,smi", 0);
> + if (!smicomm_node)
> + return -EINVAL;
> +
> + plarbdev = of_find_device_by_node(smicomm_node);
> + of_node_put(smicomm_node);
> + data->smicomm_dev = &plarbdev->dev;
> + }
> +
> + if (dev->pm_domain) {
> + struct device_link *link;
> +
> + link = device_link_add(data->smicomm_dev, dev,
> + DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
> + if (!link) {
> + dev_err(dev, "Unable link %s.\n", dev_name(data->smicomm_dev));
> + return -EINVAL;
> + }
> }
>
> platform_set_drvdata(pdev, data);
> @@ -739,7 +760,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> ret = iommu_device_sysfs_add(&data->iommu, dev, NULL,
> "mtk-iommu.%pa", &ioaddr);
> if (ret)
> - return ret;
> + goto out_link_remove;
>
> iommu_device_set_ops(&data->iommu, &mtk_iommu_ops);
> iommu_device_set_fwnode(&data->iommu, &pdev->dev.of_node->fwnode);
> @@ -763,6 +784,9 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> iommu_device_unregister(&data->iommu);
> out_sysfs_remove:
> iommu_device_sysfs_remove(&data->iommu);
> +out_link_remove:
> + if (dev->pm_domain)
> + device_link_remove(data->smicomm_dev, dev);
> return ret;
> }
>
> @@ -777,6 +801,8 @@ static int mtk_iommu_remove(struct platform_device *pdev)
> bus_set_iommu(&platform_bus_type, NULL);
>
> clk_disable_unprepare(data->bclk);
> + if (pdev->dev.pm_domain)
> + device_link_remove(data->smicomm_dev, &pdev->dev);
> devm_free_irq(&pdev->dev, data->irq, data);
> component_master_del(&pdev->dev, &mtk_iommu_com_ops);
> return 0;
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index d0c93652bdbe..5e03a029c4dc 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -68,6 +68,7 @@ struct mtk_iommu_data {
>
> struct iommu_device iommu;
> const struct mtk_iommu_plat_data *plat_data;
> + struct device *smicomm_dev;
>
> struct dma_iommu_mapping *mapping; /* For mtk_iommu_v1.c */
>
> --
> 2.18.0
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [PATCH v5 16/27] iommu/mediatek: Add device link for smi-common and m4u
2020-12-23 8:29 ` Tomasz Figa
@ 2020-12-29 11:25 ` Yong Wu
0 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-29 11:25 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, 2020-12-23 at 17:29 +0900, Tomasz Figa wrote:
> On Wed, Dec 09, 2020 at 04:00:51PM +0800, Yong Wu wrote:
> > In the lastest SoC, M4U has its special power domain. thus, If the engine
> > begin to work, it should help enable the power for M4U firstly.
> > Currently if the engine work, it always enable the power/clocks for
> > smi-larbs/smi-common. This patch adds device_link for smi-common and M4U.
> > then, if smi-common power is enabled, the M4U power also is powered on
> > automatically.
> >
> > Normally M4U connect with several smi-larbs and their smi-common always
> > are the same, In this patch it get smi-common dev from the first smi-larb
> > device(i==0), then add the device_link only while m4u has power-domain.
> >
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 30 ++++++++++++++++++++++++++++--
> > drivers/iommu/mtk_iommu.h | 1 +
> > 2 files changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 09c8c58feb78..5614015e5b96 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -20,6 +20,7 @@
> > #include <linux/of_irq.h>
> > #include <linux/of_platform.h>
> > #include <linux/platform_device.h>
> > +#include <linux/pm_runtime.h>
> > #include <linux/regmap.h>
> > #include <linux/slab.h>
> > #include <linux/spinlock.h>
> > @@ -706,7 +707,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> > return larb_nr;
> >
> > for (i = 0; i < larb_nr; i++) {
> > - struct device_node *larbnode;
> > + struct device_node *larbnode, *smicomm_node;
> > struct platform_device *plarbdev;
> > u32 id;
> >
> > @@ -732,6 +733,26 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> >
> > component_match_add_release(dev, &match, release_of,
> > compare_of, larbnode);
> > + if (i != 0)
> > + continue;
>
> How about using the last larb instead and moving the code below outside
> of the loop?
Of course OK. Thanks.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH v5 17/27] iommu/mediatek: Add pm runtime callback
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (15 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 16/27] iommu/mediatek: Add device link for smi-common and m4u Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-23 8:32 ` Tomasz Figa
2020-12-09 8:00 ` [PATCH v5 18/27] iommu/mediatek: Add power-domain operation Yong Wu
` (9 subsequent siblings)
26 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
This patch adds pm runtime callback.
In pm runtime case, all the registers backup/restore and bclk are
controlled in the pm_runtime callback, then pm_suspend is not needed in
this case.
runtime PM is disabled when suspend, thus we call
pm_runtime_status_suspended instead of pm_runtime_suspended.
And, m4u doesn't have its special pm runtime domain in previous SoC, in
this case dev->power.runtime_status is RPM_SUSPENDED defaultly, thus add
a "dev->pm_domain" checking for the SoC that has pm runtime domain.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 5614015e5b96..6fe3ee2b2bf5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -808,7 +808,7 @@ static int mtk_iommu_remove(struct platform_device *pdev)
return 0;
}
-static int __maybe_unused mtk_iommu_suspend(struct device *dev)
+static int __maybe_unused mtk_iommu_runtime_suspend(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
struct mtk_iommu_suspend_reg *reg = &data->reg;
@@ -826,7 +826,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
return 0;
}
-static int __maybe_unused mtk_iommu_resume(struct device *dev)
+static int __maybe_unused mtk_iommu_runtime_resume(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
struct mtk_iommu_suspend_reg *reg = &data->reg;
@@ -853,7 +853,25 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
return 0;
}
+static int __maybe_unused mtk_iommu_suspend(struct device *dev)
+{
+ /* runtime PM is disabled when suspend in pm_runtime case. */
+ if (dev->pm_domain && pm_runtime_status_suspended(dev))
+ return 0;
+
+ return mtk_iommu_runtime_suspend(dev);
+}
+
+static int __maybe_unused mtk_iommu_resume(struct device *dev)
+{
+ if (dev->pm_domain && pm_runtime_status_suspended(dev))
+ return 0;
+
+ return mtk_iommu_runtime_resume(dev);
+}
+
static const struct dev_pm_ops mtk_iommu_pm_ops = {
+ SET_RUNTIME_PM_OPS(mtk_iommu_runtime_suspend, mtk_iommu_runtime_resume, NULL)
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_iommu_suspend, mtk_iommu_resume)
};
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [PATCH v5 17/27] iommu/mediatek: Add pm runtime callback
2020-12-09 8:00 ` [PATCH v5 17/27] iommu/mediatek: Add pm runtime callback Yong Wu
@ 2020-12-23 8:32 ` Tomasz Figa
2020-12-29 11:06 ` Yong Wu
0 siblings, 1 reply; 56+ messages in thread
From: Tomasz Figa @ 2020-12-23 8:32 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, Dec 09, 2020 at 04:00:52PM +0800, Yong Wu wrote:
> This patch adds pm runtime callback.
>
> In pm runtime case, all the registers backup/restore and bclk are
> controlled in the pm_runtime callback, then pm_suspend is not needed in
> this case.
>
> runtime PM is disabled when suspend, thus we call
> pm_runtime_status_suspended instead of pm_runtime_suspended.
>
> And, m4u doesn't have its special pm runtime domain in previous SoC, in
> this case dev->power.runtime_status is RPM_SUSPENDED defaultly,
This sounds wrong and could lead to hard to debug errors when the driver
is changed in the future. Would it be possible to make the behavior
consistent across the SoCs instead, so that runtime PM status is ACTIVE
when needed, even on SoCs without an IOMMU PM domain?
> thus add
> a "dev->pm_domain" checking for the SoC that has pm runtime domain.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 5614015e5b96..6fe3ee2b2bf5 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -808,7 +808,7 @@ static int mtk_iommu_remove(struct platform_device *pdev)
> return 0;
> }
>
> -static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> +static int __maybe_unused mtk_iommu_runtime_suspend(struct device *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
> struct mtk_iommu_suspend_reg *reg = &data->reg;
> @@ -826,7 +826,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> return 0;
> }
>
> -static int __maybe_unused mtk_iommu_resume(struct device *dev)
> +static int __maybe_unused mtk_iommu_runtime_resume(struct device *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
> struct mtk_iommu_suspend_reg *reg = &data->reg;
> @@ -853,7 +853,25 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
> return 0;
> }
>
> +static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> +{
> + /* runtime PM is disabled when suspend in pm_runtime case. */
> + if (dev->pm_domain && pm_runtime_status_suspended(dev))
> + return 0;
> +
> + return mtk_iommu_runtime_suspend(dev);
> +}
> +
> +static int __maybe_unused mtk_iommu_resume(struct device *dev)
> +{
> + if (dev->pm_domain && pm_runtime_status_suspended(dev))
> + return 0;
> +
> + return mtk_iommu_runtime_resume(dev);
> +}
Wouldn't it be enough to just use pm_runtime_force_suspend() and
pm_runtime_force_resume() as system sleep ops?
> +
> static const struct dev_pm_ops mtk_iommu_pm_ops = {
> + SET_RUNTIME_PM_OPS(mtk_iommu_runtime_suspend, mtk_iommu_runtime_resume, NULL)
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_iommu_suspend, mtk_iommu_resume)
> };
>
> --
> 2.18.0
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [PATCH v5 17/27] iommu/mediatek: Add pm runtime callback
2020-12-23 8:32 ` Tomasz Figa
@ 2020-12-29 11:06 ` Yong Wu
0 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-29 11:06 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, 2020-12-23 at 17:32 +0900, Tomasz Figa wrote:
> On Wed, Dec 09, 2020 at 04:00:52PM +0800, Yong Wu wrote:
> > This patch adds pm runtime callback.
> >
> > In pm runtime case, all the registers backup/restore and bclk are
> > controlled in the pm_runtime callback, then pm_suspend is not needed in
> > this case.
> >
> > runtime PM is disabled when suspend, thus we call
> > pm_runtime_status_suspended instead of pm_runtime_suspended.
> >
> > And, m4u doesn't have its special pm runtime domain in previous SoC, in
> > this case dev->power.runtime_status is RPM_SUSPENDED defaultly,
>
> This sounds wrong and could lead to hard to debug errors when the driver
> is changed in the future. Would it be possible to make the behavior
> consistent across the SoCs instead, so that runtime PM status is ACTIVE
> when needed, even on SoCs without an IOMMU PM domain?
Appreciate the reviewing so detailly.
I have tested this.
a) always call pm_runtime_enable.
b) always add device_link with smi_common.
Then, the runtime PM status meet expectation.
We don't call pm_runtime_get_sync so often, thus, we don't always touch
dev->power.lock. this is ok for us.
I will use this in the next version.
>
> > thus add
> > a "dev->pm_domain" checking for the SoC that has pm runtime domain.
> >
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 22 ++++++++++++++++++++--
> > 1 file changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 5614015e5b96..6fe3ee2b2bf5 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -808,7 +808,7 @@ static int mtk_iommu_remove(struct platform_device *pdev)
> > return 0;
> > }
> >
> > -static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> > +static int __maybe_unused mtk_iommu_runtime_suspend(struct device *dev)
> > {
> > struct mtk_iommu_data *data = dev_get_drvdata(dev);
> > struct mtk_iommu_suspend_reg *reg = &data->reg;
> > @@ -826,7 +826,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> > return 0;
> > }
> >
> > -static int __maybe_unused mtk_iommu_resume(struct device *dev)
> > +static int __maybe_unused mtk_iommu_runtime_resume(struct device *dev)
> > {
> > struct mtk_iommu_data *data = dev_get_drvdata(dev);
> > struct mtk_iommu_suspend_reg *reg = &data->reg;
> > @@ -853,7 +853,25 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
> > return 0;
> > }
> >
> > +static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> > +{
> > + /* runtime PM is disabled when suspend in pm_runtime case. */
> > + if (dev->pm_domain && pm_runtime_status_suspended(dev))
> > + return 0;
> > +
> > + return mtk_iommu_runtime_suspend(dev);
> > +}
> > +
> > +static int __maybe_unused mtk_iommu_resume(struct device *dev)
> > +{
> > + if (dev->pm_domain && pm_runtime_status_suspended(dev))
> > + return 0;
> > +
> > + return mtk_iommu_runtime_resume(dev);
> > +}
>
> Wouldn't it be enough to just use pm_runtime_force_suspend() and
> pm_runtime_force_resume() as system sleep ops?
After above solution, this is ok.
Thanks.
>
> > +
> > static const struct dev_pm_ops mtk_iommu_pm_ops = {
> > + SET_RUNTIME_PM_OPS(mtk_iommu_runtime_suspend, mtk_iommu_runtime_resume, NULL)
> > SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_iommu_suspend, mtk_iommu_resume)
> > };
> >
> > --
> > 2.18.0
> >
> > _______________________________________________
> > iommu mailing list
> > iommu@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH v5 18/27] iommu/mediatek: Add power-domain operation
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (16 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 17/27] iommu/mediatek: Add pm runtime callback Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-23 8:36 ` Tomasz Figa
2020-12-09 8:00 ` [PATCH v5 19/27] iommu/mediatek: Add iova reserved function Yong Wu
` (8 subsequent siblings)
26 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
In the previous SoC, the M4U HW is in the EMI power domain which is
always on. the latest M4U is in the display power domain which may be
turned on/off, thus we have to add pm_runtime interface for it.
When the engine work, the engine always enable the power and clocks for
smi-larb/smi-common, then the M4U's power will always be powered on
automatically via the device link with smi-common.
Note: we don't enable the M4U power in iommu_map/unmap for tlb flush.
If its power already is on, of course it is ok. if the power is off,
the main tlb will be reset while M4U power on, thus the tlb flush while
m4u power off is unnecessary, just skip it.
There will be one case that pm runctime status is not expected when tlb
flush. After boot, the display may call dma_alloc_attrs before it call
pm_runtime_get(disp-dev), then the m4u's pm status is not active inside
the dma_alloc_attrs. Since it only happens after boot, the tlb is clean
at that time, I also think this is ok.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 41 +++++++++++++++++++++++++++++++++------
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6fe3ee2b2bf5..0e9c03cbab32 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -184,6 +184,8 @@ static void mtk_iommu_tlb_flush_all(void *cookie)
struct mtk_iommu_data *data = cookie;
for_each_m4u(data) {
+ if (!pm_runtime_active(data->dev))
+ continue;
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
data->base + data->plat_data->inv_sel_reg);
writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
@@ -200,6 +202,10 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long iova, size_t size,
u32 tmp;
for_each_m4u(data) {
+ /* skip tlb flush when pm is not active. */
+ if (!pm_runtime_active(data->dev))
+ continue;
+
spin_lock_irqsave(&data->tlb_lock, flags);
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
data->base + data->plat_data->inv_sel_reg);
@@ -384,6 +390,8 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
{
struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+ struct device *m4udev = data->dev;
+ bool pm_enabled = pm_runtime_enabled(m4udev);
int ret;
if (!data)
@@ -391,12 +399,25 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
/* Update the pgtable base address register of the M4U HW */
if (!data->m4u_dom) {
+ if (pm_enabled) {
+ ret = pm_runtime_get_sync(m4udev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(m4udev);
+ return ret;
+ }
+ }
ret = mtk_iommu_hw_init(data);
- if (ret)
+ if (ret) {
+ if (pm_enabled)
+ pm_runtime_put(m4udev);
return ret;
+ }
data->m4u_dom = dom;
writel(dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK,
data->base + REG_MMU_PT_BASE_ADDR);
+
+ if (pm_enabled)
+ pm_runtime_put(m4udev);
}
mtk_iommu_config(data, dev, true);
@@ -747,10 +768,13 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (dev->pm_domain) {
struct device_link *link;
+ pm_runtime_enable(dev);
+
link = device_link_add(data->smicomm_dev, dev,
DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
if (!link) {
dev_err(dev, "Unable link %s.\n", dev_name(data->smicomm_dev));
+ pm_runtime_disable(dev);
return -EINVAL;
}
}
@@ -785,8 +809,10 @@ static int mtk_iommu_probe(struct platform_device *pdev)
out_sysfs_remove:
iommu_device_sysfs_remove(&data->iommu);
out_link_remove:
- if (dev->pm_domain)
+ if (dev->pm_domain) {
device_link_remove(data->smicomm_dev, dev);
+ pm_runtime_disable(dev);
+ }
return ret;
}
@@ -801,8 +827,10 @@ static int mtk_iommu_remove(struct platform_device *pdev)
bus_set_iommu(&platform_bus_type, NULL);
clk_disable_unprepare(data->bclk);
- if (pdev->dev.pm_domain)
+ if (pdev->dev.pm_domain) {
device_link_remove(data->smicomm_dev, &pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ }
devm_free_irq(&pdev->dev, data->irq, data);
component_master_del(&pdev->dev, &mtk_iommu_com_ops);
return 0;
@@ -834,6 +862,9 @@ static int __maybe_unused mtk_iommu_runtime_resume(struct device *dev)
void __iomem *base = data->base;
int ret;
+ /* Avoid first resume to affect the default value of registers below. */
+ if (!m4u_dom)
+ return 0;
ret = clk_prepare_enable(data->bclk);
if (ret) {
dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
@@ -847,9 +878,7 @@ static int __maybe_unused mtk_iommu_runtime_resume(struct device *dev)
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
writel_relaxed(reg->vld_pa_rng, base + REG_MMU_VLD_PA_RNG);
- if (m4u_dom)
- writel(m4u_dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK,
- base + REG_MMU_PT_BASE_ADDR);
+ writel(m4u_dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK, base + REG_MMU_PT_BASE_ADDR);
return 0;
}
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [PATCH v5 18/27] iommu/mediatek: Add power-domain operation
2020-12-09 8:00 ` [PATCH v5 18/27] iommu/mediatek: Add power-domain operation Yong Wu
@ 2020-12-23 8:36 ` Tomasz Figa
2020-12-29 11:06 ` Yong Wu
0 siblings, 1 reply; 56+ messages in thread
From: Tomasz Figa @ 2020-12-23 8:36 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, Dec 09, 2020 at 04:00:53PM +0800, Yong Wu wrote:
> In the previous SoC, the M4U HW is in the EMI power domain which is
> always on. the latest M4U is in the display power domain which may be
> turned on/off, thus we have to add pm_runtime interface for it.
>
> When the engine work, the engine always enable the power and clocks for
> smi-larb/smi-common, then the M4U's power will always be powered on
> automatically via the device link with smi-common.
>
> Note: we don't enable the M4U power in iommu_map/unmap for tlb flush.
> If its power already is on, of course it is ok. if the power is off,
> the main tlb will be reset while M4U power on, thus the tlb flush while
> m4u power off is unnecessary, just skip it.
>
> There will be one case that pm runctime status is not expected when tlb
> flush. After boot, the display may call dma_alloc_attrs before it call
> pm_runtime_get(disp-dev), then the m4u's pm status is not active inside
> the dma_alloc_attrs. Since it only happens after boot, the tlb is clean
> at that time, I also think this is ok.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 41 +++++++++++++++++++++++++++++++++------
> 1 file changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 6fe3ee2b2bf5..0e9c03cbab32 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -184,6 +184,8 @@ static void mtk_iommu_tlb_flush_all(void *cookie)
> struct mtk_iommu_data *data = cookie;
>
> for_each_m4u(data) {
> + if (!pm_runtime_active(data->dev))
> + continue;
Is it guaranteed that the status is active in the check above, but then
the process is preempted and it goes down here?
Shouldn't we do something like below?
ret = pm_runtime_get_if_active();
if (!ret)
continue;
if (ret < 0)
// handle error
// Flush
pm_runtime_put();
Similar comment to the other places being changed by this patch.
> writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
> data->base + data->plat_data->inv_sel_reg);
> writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
> @@ -200,6 +202,10 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long iova, size_t size,
> u32 tmp;
>
> for_each_m4u(data) {
> + /* skip tlb flush when pm is not active. */
> + if (!pm_runtime_active(data->dev))
> + continue;
> +
> spin_lock_irqsave(&data->tlb_lock, flags);
> writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
> data->base + data->plat_data->inv_sel_reg);
> @@ -384,6 +390,8 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
> {
> struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
> struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> + struct device *m4udev = data->dev;
> + bool pm_enabled = pm_runtime_enabled(m4udev);
> int ret;
>
> if (!data)
> @@ -391,12 +399,25 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
>
> /* Update the pgtable base address register of the M4U HW */
> if (!data->m4u_dom) {
> + if (pm_enabled) {
> + ret = pm_runtime_get_sync(m4udev);
> + if (ret < 0) {
> + pm_runtime_put_noidle(m4udev);
> + return ret;
> + }
> + }
> ret = mtk_iommu_hw_init(data);
> - if (ret)
> + if (ret) {
> + if (pm_enabled)
> + pm_runtime_put(m4udev);
> return ret;
> + }
> data->m4u_dom = dom;
> writel(dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK,
> data->base + REG_MMU_PT_BASE_ADDR);
> +
> + if (pm_enabled)
> + pm_runtime_put(m4udev);
> }
>
> mtk_iommu_config(data, dev, true);
> @@ -747,10 +768,13 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (dev->pm_domain) {
> struct device_link *link;
>
> + pm_runtime_enable(dev);
> +
> link = device_link_add(data->smicomm_dev, dev,
> DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
> if (!link) {
> dev_err(dev, "Unable link %s.\n", dev_name(data->smicomm_dev));
> + pm_runtime_disable(dev);
> return -EINVAL;
> }
> }
> @@ -785,8 +809,10 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> out_sysfs_remove:
> iommu_device_sysfs_remove(&data->iommu);
> out_link_remove:
> - if (dev->pm_domain)
> + if (dev->pm_domain) {
> device_link_remove(data->smicomm_dev, dev);
> + pm_runtime_disable(dev);
> + }
> return ret;
> }
>
> @@ -801,8 +827,10 @@ static int mtk_iommu_remove(struct platform_device *pdev)
> bus_set_iommu(&platform_bus_type, NULL);
>
> clk_disable_unprepare(data->bclk);
> - if (pdev->dev.pm_domain)
> + if (pdev->dev.pm_domain) {
> device_link_remove(data->smicomm_dev, &pdev->dev);
> + pm_runtime_disable(&pdev->dev);
> + }
> devm_free_irq(&pdev->dev, data->irq, data);
> component_master_del(&pdev->dev, &mtk_iommu_com_ops);
> return 0;
> @@ -834,6 +862,9 @@ static int __maybe_unused mtk_iommu_runtime_resume(struct device *dev)
> void __iomem *base = data->base;
> int ret;
>
> + /* Avoid first resume to affect the default value of registers below. */
> + if (!m4u_dom)
> + return 0;
> ret = clk_prepare_enable(data->bclk);
> if (ret) {
> dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
> @@ -847,9 +878,7 @@ static int __maybe_unused mtk_iommu_runtime_resume(struct device *dev)
> writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
> writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
> writel_relaxed(reg->vld_pa_rng, base + REG_MMU_VLD_PA_RNG);
> - if (m4u_dom)
> - writel(m4u_dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK,
> - base + REG_MMU_PT_BASE_ADDR);
> + writel(m4u_dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK, base + REG_MMU_PT_BASE_ADDR);
> return 0;
> }
>
> --
> 2.18.0
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [PATCH v5 18/27] iommu/mediatek: Add power-domain operation
2020-12-23 8:36 ` Tomasz Figa
@ 2020-12-29 11:06 ` Yong Wu
2021-01-08 9:54 ` Tomasz Figa
0 siblings, 1 reply; 56+ messages in thread
From: Yong Wu @ 2020-12-29 11:06 UTC (permalink / raw)
To: Tomasz Figa
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
Tomasz Figa, Will Deacon, linux-kernel, Evan Green, chao.hao,
iommu, Rob Herring, linux-mediatek, Krzysztof Kozlowski,
Matthias Brugger, anan.sun, Robin Murphy, linux-arm-kernel
On Wed, 2020-12-23 at 17:36 +0900, Tomasz Figa wrote:
> On Wed, Dec 09, 2020 at 04:00:53PM +0800, Yong Wu wrote:
> > In the previous SoC, the M4U HW is in the EMI power domain which is
> > always on. the latest M4U is in the display power domain which may be
> > turned on/off, thus we have to add pm_runtime interface for it.
> >
> > When the engine work, the engine always enable the power and clocks for
> > smi-larb/smi-common, then the M4U's power will always be powered on
> > automatically via the device link with smi-common.
> >
> > Note: we don't enable the M4U power in iommu_map/unmap for tlb flush.
> > If its power already is on, of course it is ok. if the power is off,
> > the main tlb will be reset while M4U power on, thus the tlb flush while
> > m4u power off is unnecessary, just skip it.
> >
> > There will be one case that pm runctime status is not expected when tlb
> > flush. After boot, the display may call dma_alloc_attrs before it call
> > pm_runtime_get(disp-dev), then the m4u's pm status is not active inside
> > the dma_alloc_attrs. Since it only happens after boot, the tlb is clean
> > at that time, I also think this is ok.
> >
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 41 +++++++++++++++++++++++++++++++++------
> > 1 file changed, 35 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 6fe3ee2b2bf5..0e9c03cbab32 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -184,6 +184,8 @@ static void mtk_iommu_tlb_flush_all(void *cookie)
> > struct mtk_iommu_data *data = cookie;
> >
> > for_each_m4u(data) {
> > + if (!pm_runtime_active(data->dev))
> > + continue;
>
> Is it guaranteed that the status is active in the check above, but then
> the process is preempted and it goes down here?
>
> Shouldn't we do something like below?
>
> ret = pm_runtime_get_if_active();
> if (!ret)
> continue;
> if (ret < 0)
> // handle error
>
> // Flush
>
> pm_runtime_put();
Make sense. Thanks. There is a comment in arm_smmu.c "avoid touching
dev->power.lock in fastpaths". To avoid this here too(we have many SoC
don't have power-domain). then the code will be like:
bool has_pm = !!data->dev->pm_domain;
if (has_pm) {
if (pm_runtime_get_if_in_use(data->dev) <= 0)
continue;
}
xxxx
if (has_pm)
pm_runtime_put(data->dev);
>
> Similar comment to the other places being changed by this patch.
>
> > writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
> > data->base + data->plat_data->inv_sel_reg);
> > writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
> > @@ -200,6 +202,10 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long iova, size_t size,
> > u32 tmp;
> >
> > for_each_m4u(data) {
> > + /* skip tlb flush when pm is not active. */
> > + if (!pm_runtime_active(data->dev))
> > + continue;
> > +
> > spin_lock_irqsave(&data->tlb_lock, flags);
> > writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
> > data->base + data->plat_data->inv_sel_reg);
[snip]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [PATCH v5 18/27] iommu/mediatek: Add power-domain operation
2020-12-29 11:06 ` Yong Wu
@ 2021-01-08 9:54 ` Tomasz Figa
0 siblings, 0 replies; 56+ messages in thread
From: Tomasz Figa @ 2021-01-08 9:54 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, linux-devicetree, Nicolas Boichat, srv_heupstream,
Will Deacon, Linux Kernel Mailing List, Evan Green, chao.hao,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Rob Herring, moderated list:ARM/Mediatek SoC support,
Krzysztof Kozlowski, Matthias Brugger, anan.sun, Robin Murphy,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
On Tue, Dec 29, 2020 at 8:06 PM Yong Wu <yong.wu@mediatek.com> wrote:
>
> On Wed, 2020-12-23 at 17:36 +0900, Tomasz Figa wrote:
> > On Wed, Dec 09, 2020 at 04:00:53PM +0800, Yong Wu wrote:
> > > In the previous SoC, the M4U HW is in the EMI power domain which is
> > > always on. the latest M4U is in the display power domain which may be
> > > turned on/off, thus we have to add pm_runtime interface for it.
> > >
> > > When the engine work, the engine always enable the power and clocks for
> > > smi-larb/smi-common, then the M4U's power will always be powered on
> > > automatically via the device link with smi-common.
> > >
> > > Note: we don't enable the M4U power in iommu_map/unmap for tlb flush.
> > > If its power already is on, of course it is ok. if the power is off,
> > > the main tlb will be reset while M4U power on, thus the tlb flush while
> > > m4u power off is unnecessary, just skip it.
> > >
> > > There will be one case that pm runctime status is not expected when tlb
> > > flush. After boot, the display may call dma_alloc_attrs before it call
> > > pm_runtime_get(disp-dev), then the m4u's pm status is not active inside
> > > the dma_alloc_attrs. Since it only happens after boot, the tlb is clean
> > > at that time, I also think this is ok.
> > >
> > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > ---
> > > drivers/iommu/mtk_iommu.c | 41 +++++++++++++++++++++++++++++++++------
> > > 1 file changed, 35 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > > index 6fe3ee2b2bf5..0e9c03cbab32 100644
> > > --- a/drivers/iommu/mtk_iommu.c
> > > +++ b/drivers/iommu/mtk_iommu.c
> > > @@ -184,6 +184,8 @@ static void mtk_iommu_tlb_flush_all(void *cookie)
> > > struct mtk_iommu_data *data = cookie;
> > >
> > > for_each_m4u(data) {
> > > + if (!pm_runtime_active(data->dev))
> > > + continue;
> >
> > Is it guaranteed that the status is active in the check above, but then
> > the process is preempted and it goes down here?
> >
> > Shouldn't we do something like below?
> >
> > ret = pm_runtime_get_if_active();
> > if (!ret)
> > continue;
> > if (ret < 0)
> > // handle error
> >
> > // Flush
> >
> > pm_runtime_put();
>
> Make sense. Thanks. There is a comment in arm_smmu.c "avoid touching
> dev->power.lock in fastpaths". To avoid this here too(we have many SoC
> don't have power-domain). then the code will be like:
>
> bool has_pm = !!data->dev->pm_domain;
>
> if (has_pm) {
> if (pm_runtime_get_if_in_use(data->dev) <= 0)
> continue;
> }
>
> xxxx
>
> if (has_pm)
> pm_runtime_put(data->dev);
Looks good to me, thanks.
> >
> > Similar comment to the other places being changed by this patch.
> >
> > > writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
> > > data->base + data->plat_data->inv_sel_reg);
> > > writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
> > > @@ -200,6 +202,10 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long iova, size_t size,
> > > u32 tmp;
> > >
> > > for_each_m4u(data) {
> > > + /* skip tlb flush when pm is not active. */
> > > + if (!pm_runtime_active(data->dev))
> > > + continue;
> > > +
> > > spin_lock_irqsave(&data->tlb_lock, flags);
> > > writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
> > > data->base + data->plat_data->inv_sel_reg);
> [snip]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH v5 19/27] iommu/mediatek: Add iova reserved function
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (17 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 18/27] iommu/mediatek: Add power-domain operation Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 20/27] iommu/mediatek: Add single domain Yong Wu
` (7 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
For multiple iommu_domains, we need to reserve some iova regions. Take a
example, If the default iova region is 0 ~ 4G, but the 0x4000_0000 ~
0x43ff_ffff is only for the special CCU0 domain. Thus we should exclude
this region for the default iova region.
This patch adds iova reserved flow. It's a preparing patch for supporting
multi-domain.
Signed-off-by: Anan sun <anan.sun@mediatek.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 28 ++++++++++++++++++++++++++++
drivers/iommu/mtk_iommu.h | 5 +++++
2 files changed, 33 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 0e9c03cbab32..6a909efc984f 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -157,6 +157,11 @@ static LIST_HEAD(m4ulist); /* List all the M4U HWs */
#define for_each_m4u(data) list_for_each_entry(data, &m4ulist, list)
+struct mtk_iommu_iova_region {
+ dma_addr_t iova_base;
+ unsigned long long size;
+};
+
/*
* There may be 1 or 2 M4U HWs, But we always expect they are in the same domain
* for the performance.
@@ -553,6 +558,27 @@ static int mtk_iommu_of_xlate(struct device *dev, struct of_phandle_args *args)
return iommu_fwspec_add_ids(dev, args->args, 1);
}
+static void mtk_iommu_get_resv_regions(struct device *dev,
+ struct list_head *head)
+{
+ struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
+ const struct mtk_iommu_iova_region *resv;
+ struct iommu_resv_region *region;
+ int prot = IOMMU_WRITE | IOMMU_READ;
+ unsigned int i;
+
+ for (i = 0; i < data->plat_data->iova_region_nr; i++) {
+ resv = data->plat_data->iova_region + i;
+
+ region = iommu_alloc_resv_region(resv->iova_base, resv->size,
+ prot, IOMMU_RESV_RESERVED);
+ if (!region)
+ return;
+
+ list_add_tail(®ion->list, head);
+ }
+}
+
static const struct iommu_ops mtk_iommu_ops = {
.domain_alloc = mtk_iommu_domain_alloc,
.domain_free = mtk_iommu_domain_free,
@@ -567,6 +593,8 @@ static const struct iommu_ops mtk_iommu_ops = {
.release_device = mtk_iommu_release_device,
.device_group = mtk_iommu_device_group,
.of_xlate = mtk_iommu_of_xlate,
+ .get_resv_regions = mtk_iommu_get_resv_regions,
+ .put_resv_regions = generic_iommu_put_resv_regions,
.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M,
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 5e03a029c4dc..e867cd3aeeac 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -45,10 +45,15 @@ enum mtk_iommu_plat {
M4U_MT8183,
};
+struct mtk_iommu_iova_region;
+
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
u32 flags;
u32 inv_sel_reg;
+
+ unsigned int iova_region_nr;
+ const struct mtk_iommu_iova_region *iova_region;
unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
};
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 20/27] iommu/mediatek: Add single domain
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (18 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 19/27] iommu/mediatek: Add iova reserved function Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 21/27] iommu/mediatek: Support master use iova over 32bit Yong Wu
` (6 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Defaultly the iova range is 0-4G. here we add a single-domain(0-4G)
for the previous SoC. this also is a preparing patch for supporting
multi-domains.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6a909efc984f..c3a6712c497b 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -162,6 +162,10 @@ struct mtk_iommu_iova_region {
unsigned long long size;
};
+static const struct mtk_iommu_iova_region single_domain[] = {
+ {.iova_base = 0, .size = SZ_4G},
+};
+
/*
* There may be 1 or 2 M4U HWs, But we always expect they are in the same domain
* for the performance.
@@ -936,6 +940,8 @@ static const struct mtk_iommu_plat_data mt2712_data = {
.m4u_plat = M4U_MT2712,
.flags = HAS_4GB_MODE | HAS_BCLK | HAS_VLD_PA_RNG,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
.larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
};
@@ -943,6 +949,8 @@ static const struct mtk_iommu_plat_data mt6779_data = {
.m4u_plat = M4U_MT6779,
.flags = HAS_SUB_COMM | OUT_ORDER_WR_EN | WR_THROT_EN,
.inv_sel_reg = REG_MMU_INV_SEL_GEN2,
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
.larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
};
@@ -950,6 +958,8 @@ static const struct mtk_iommu_plat_data mt8167_data = {
.m4u_plat = M4U_MT8167,
.flags = RESET_AXI | HAS_LEGACY_IVRP_PADDR,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
.larbid_remap = {{0}, {1}, {2}}, /* Linear mapping. */
};
@@ -958,6 +968,8 @@ static const struct mtk_iommu_plat_data mt8173_data = {
.flags = HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
HAS_LEGACY_IVRP_PADDR,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
.larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
};
@@ -965,6 +977,8 @@ static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
.flags = RESET_AXI,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
.larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
};
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 21/27] iommu/mediatek: Support master use iova over 32bit
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (19 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 20/27] iommu/mediatek: Add single domain Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 22/27] iommu/mediatek: Support up to 34bit iova in tlb flush Yong Wu
` (5 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
After extending v7s, our pagetable already support iova reach
16GB(34bit). the master got the iova via dma_alloc_attrs may reach
34bits, but its HW register still is 32bit. then how to set the
bit32/bit33 iova? this depend on a SMI larb setting(bank_sel).
we separate whole 16GB iova to four banks:
bank: 0: 0~4G; 1: 4~8G; 2: 8-12G; 3: 12-16G;
The bank number is (iova >> 32).
We will preassign which bank the larbs belong to. currently we don't
have a interface for master to adjust its bank number.
Each a bank is a iova_region which is a independent iommu-domain.
the iova range for each iommu-domain can't cross 4G.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/iommu/mtk_iommu.c | 12 +++++++++---
drivers/memory/mtk-smi.c | 7 +++++++
include/soc/mediatek/smi.h | 1 +
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c3a6712c497b..f206275230b3 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -309,17 +309,23 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
struct device *dev, bool enable)
{
struct mtk_smi_larb_iommu *larb_mmu;
- unsigned int larbid, portid;
+ unsigned int larbid, portid, domid;
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ const struct mtk_iommu_iova_region *region;
int i;
for (i = 0; i < fwspec->num_ids; ++i) {
larbid = MTK_M4U_TO_LARB(fwspec->ids[i]);
portid = MTK_M4U_TO_PORT(fwspec->ids[i]);
+ domid = MTK_M4U_TO_DOM(fwspec->ids[i]);
+
larb_mmu = &data->larb_imu[larbid];
+ region = data->plat_data->iova_region + domid;
+ larb_mmu->bank[portid] = upper_32_bits(region->iova_base);
- dev_dbg(dev, "%s iommu port: %d\n",
- enable ? "enable" : "disable", portid);
+ dev_dbg(dev, "%s iommu for larb(%s) port %d dom %d bank %d.\n",
+ enable ? "enable" : "disable", dev_name(larb_mmu->dev),
+ portid, domid, larb_mmu->bank[portid]);
if (enable)
larb_mmu->mmu |= MTK_SMI_MMU_EN(portid);
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 2beb67908f3c..2094e4b4eb10 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -44,6 +44,10 @@
/* mt2712 */
#define SMI_LARB_NONSEC_CON(id) (0x380 + ((id) * 4))
#define F_MMU_EN BIT(0)
+#define BANK_SEL(id) ({ \
+ u32 _id = (id) & 0x3; \
+ (_id << 8 | _id << 10 | _id << 12 | _id << 14); \
+})
/* SMI COMMON */
#define SMI_BUS_SEL 0x220
@@ -88,6 +92,7 @@ struct mtk_smi_larb { /* larb: local arbiter */
const struct mtk_smi_larb_gen *larb_gen;
int larbid;
u32 *mmu;
+ unsigned char *bank;
};
static int mtk_smi_clk_enable(const struct mtk_smi *smi)
@@ -154,6 +159,7 @@ mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
if (dev == larb_mmu[i].dev) {
larb->larbid = i;
larb->mmu = &larb_mmu[i].mmu;
+ larb->bank = larb_mmu[i].bank;
return 0;
}
}
@@ -172,6 +178,7 @@ static void mtk_smi_larb_config_port_gen2_general(struct device *dev)
for_each_set_bit(i, (unsigned long *)larb->mmu, 32) {
reg = readl_relaxed(larb->base + SMI_LARB_NONSEC_CON(i));
reg |= F_MMU_EN;
+ reg |= BANK_SEL(larb->bank[i]);
writel(reg, larb->base + SMI_LARB_NONSEC_CON(i));
}
}
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 9371bf572ab8..4cf445dbbdaa 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -16,6 +16,7 @@
struct mtk_smi_larb_iommu {
struct device *dev;
unsigned int mmu;
+ unsigned char bank[32];
};
/*
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 22/27] iommu/mediatek: Support up to 34bit iova in tlb flush
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (20 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 21/27] iommu/mediatek: Support master use iova over 32bit Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 23/27] iommu/mediatek: Support report iova 34bit translation fault in ISR Yong Wu
` (4 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
If the iova is 34bit, the iova[32][33] is the bit0/1 in the tlb flush
register. Add a new macro for this.
there is a minor change unrelated with this patch. it also use the new
macro.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index f206275230b3..164479e1f5c5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -129,6 +129,9 @@ static const struct iommu_ops mtk_iommu_ops;
static int mtk_iommu_hw_init(const struct mtk_iommu_data *data);
+#define MTK_IOMMU_ADDR(addr) ({unsigned long _addr = addr; \
+ (lower_32_bits(_addr) | upper_32_bits(_addr)); })
+
/*
* In M4U 4GB mode, the physical address is remapped as below:
*
@@ -219,8 +222,9 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long iova, size_t size,
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
data->base + data->plat_data->inv_sel_reg);
- writel_relaxed(iova, data->base + REG_MMU_INVLD_START_A);
- writel_relaxed(iova + size - 1,
+ writel_relaxed(MTK_IOMMU_ADDR(iova),
+ data->base + REG_MMU_INVLD_START_A);
+ writel_relaxed(MTK_IOMMU_ADDR(iova + size - 1),
data->base + REG_MMU_INVLD_END_A);
writel_relaxed(F_MMU_INV_RANGE,
data->base + REG_MMU_INVALIDATE);
@@ -648,8 +652,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_LEGACY_IVRP_PADDR))
regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
else
- regval = lower_32_bits(data->protect_base) |
- upper_32_bits(data->protect_base);
+ regval = MTK_IOMMU_ADDR(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
if (data->enable_4GB &&
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 23/27] iommu/mediatek: Support report iova 34bit translation fault in ISR
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (21 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 22/27] iommu/mediatek: Support up to 34bit iova in tlb flush Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:00 ` [PATCH v5 24/27] iommu/mediatek: Add support for multi domain Yong Wu
` (3 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
If the iova is over 32bit, the fault status register bit is a little
different.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 164479e1f5c5..ed771133643d 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -3,6 +3,7 @@
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu <yong.wu@mediatek.com>
*/
+#include <linux/bitfield.h>
#include <linux/bug.h>
#include <linux/clk.h>
#include <linux/component.h>
@@ -89,6 +90,9 @@
#define F_REG_MMU1_FAULT_MASK GENMASK(13, 7)
#define REG_MMU0_FAULT_VA 0x13c
+#define F_MMU_INVAL_VA_31_12_MASK GENMASK(31, 12)
+#define F_MMU_INVAL_VA_34_32_MASK GENMASK(11, 9)
+#define F_MMU_INVAL_PA_34_32_MASK GENMASK(8, 6)
#define F_MMU_FAULT_VA_WRITE_BIT BIT(1)
#define F_MMU_FAULT_VA_LAYER_BIT BIT(0)
@@ -264,8 +268,9 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
{
struct mtk_iommu_data *data = dev_id;
struct mtk_iommu_domain *dom = data->m4u_dom;
- u32 int_state, regval, fault_iova, fault_pa;
unsigned int fault_larb, fault_port, sub_comm = 0;
+ u32 int_state, regval, va34_32, pa34_32;
+ u64 fault_iova, fault_pa;
bool layer, write;
/* Read error info from registers */
@@ -281,6 +286,14 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
}
layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, IOVA_34_EN)) {
+ va34_32 = FIELD_GET(F_MMU_INVAL_VA_34_32_MASK, fault_iova);
+ pa34_32 = FIELD_GET(F_MMU_INVAL_PA_34_32_MASK, fault_iova);
+ fault_iova = fault_iova & F_MMU_INVAL_VA_31_12_MASK;
+ fault_iova |= (u64)va34_32 << 32;
+ fault_pa |= (u64)pa34_32 << 32;
+ }
+
fault_port = F_MMU_INT_ID_PORT_ID(regval);
if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_SUB_COMM)) {
fault_larb = F_MMU_INT_ID_COMM_ID(regval);
@@ -294,7 +307,7 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
dev_err_ratelimited(
data->dev,
- "fault type=0x%x iova=0x%x pa=0x%x larb=%d port=%d layer=%d %s\n",
+ "fault type=0x%x iova=0x%llx pa=0x%llx larb=%d port=%d layer=%d %s\n",
int_state, fault_iova, fault_pa, fault_larb, fault_port,
layer, write ? "write" : "read");
}
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 24/27] iommu/mediatek: Add support for multi domain
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (22 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 23/27] iommu/mediatek: Support report iova 34bit translation fault in ISR Yong Wu
@ 2020-12-09 8:00 ` Yong Wu
2020-12-09 8:01 ` [PATCH v5 25/27] iommu/mediatek: Adjust the structure Yong Wu
` (2 subsequent siblings)
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:00 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Some HW IP(ex: CCU) require the special iova range. That means the
iova got from dma_alloc_attrs for that devices must locate in his
special range. In this patch, we allocate a special iova_range for
each a special requirement and create each a iommu domain for each
a iova_range.
meanwhile we still use one pagetable which support 16GB iova.
After this patch, If the iova range of a master is over 4G, the master
should:
a) Declare its special dma_ranges in its dtsi node. For example, If we
preassign the iova 4G-8G for vcodec, then the vcodec dtsi node should
add this:
/*
* iova start at 0x1_0000_0000, pa still start at 0x4000_0000
* size is 0x1_0000_0000.
*/
dma-ranges = <0x1 0x0 0x0 0x40000000 0x1 0x0>; /* 4G ~ 8G */
Note: we don't have a actual bus concept here. the master doesn't have its
special parent node, thus this dma-ranges can only be put in the master's
node.
b) Update the dma_mask:
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(33));
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 47 +++++++++++++++++++++++++++++++--------
drivers/iommu/mtk_iommu.h | 3 ++-
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index ed771133643d..160690d56bd2 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -355,6 +355,14 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom)
{
struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
+ /* Use the exist domain as there is only one m4u pgtable here. */
+ if (data->m4u_dom) {
+ dom->iop = data->m4u_dom->iop;
+ dom->cfg = data->m4u_dom->cfg;
+ dom->domain.pgsize_bitmap = data->m4u_dom->cfg.pgsize_bitmap;
+ return 0;
+ }
+
dom->cfg = (struct io_pgtable_cfg) {
.quirks = IO_PGTABLE_QUIRK_ARM_NS |
IO_PGTABLE_QUIRK_NO_PERMS |
@@ -380,6 +388,8 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom)
static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type)
{
+ struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
+ const struct mtk_iommu_iova_region *region;
struct mtk_iommu_domain *dom;
if (type != IOMMU_DOMAIN_DMA)
@@ -395,8 +405,9 @@ static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type)
if (mtk_iommu_domain_finalise(dom))
goto put_dma_cookie;
- dom->domain.geometry.aperture_start = 0;
- dom->domain.geometry.aperture_end = DMA_BIT_MASK(32);
+ region = data->plat_data->iova_region + data->cur_domid;
+ dom->domain.geometry.aperture_start = region->iova_base;
+ dom->domain.geometry.aperture_end = region->iova_base + region->size - 1;
dom->domain.geometry.force_aperture = true;
return &dom->domain;
@@ -548,19 +559,31 @@ static void mtk_iommu_release_device(struct device *dev)
static struct iommu_group *mtk_iommu_device_group(struct device *dev)
{
struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct iommu_group *group;
+ int domid;
if (!data)
return ERR_PTR(-ENODEV);
- /* All the client devices are in the same m4u iommu-group */
- if (!data->m4u_group) {
- data->m4u_group = iommu_group_alloc();
- if (IS_ERR(data->m4u_group))
+ domid = MTK_M4U_TO_DOM(fwspec->ids[0]);
+ if (domid >= data->plat_data->iova_region_nr) {
+ dev_err(dev, "iommu domain id(%d/%d) is error.\n", domid,
+ data->plat_data->iova_region_nr);
+ return ERR_PTR(-EINVAL);
+ }
+
+ group = data->m4u_group[domid];
+ if (!group) {
+ group = iommu_group_alloc();
+ if (IS_ERR(group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ data->m4u_group[domid] = group;
} else {
- iommu_group_ref_get(data->m4u_group);
+ iommu_group_ref_get(group);
}
- return data->m4u_group;
+ data->cur_domid = domid;
+ return group;
}
static int mtk_iommu_of_xlate(struct device *dev, struct of_phandle_args *args)
@@ -589,14 +612,20 @@ static void mtk_iommu_get_resv_regions(struct device *dev,
struct list_head *head)
{
struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
- const struct mtk_iommu_iova_region *resv;
+ const struct mtk_iommu_iova_region *resv, *curdom;
struct iommu_resv_region *region;
int prot = IOMMU_WRITE | IOMMU_READ;
unsigned int i;
+ curdom = data->plat_data->iova_region + data->cur_domid;
for (i = 0; i < data->plat_data->iova_region_nr; i++) {
resv = data->plat_data->iova_region + i;
+ /* Only reserve when the region is in the current domain */
+ if (resv->iova_base <= curdom->iova_base ||
+ resv->iova_base + resv->size >= curdom->iova_base + curdom->size)
+ continue;
+
region = iommu_alloc_resv_region(resv->iova_base, resv->size,
prot, IOMMU_RESV_RESERVED);
if (!region)
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index e867cd3aeeac..b54862307128 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -67,7 +67,7 @@ struct mtk_iommu_data {
phys_addr_t protect_base; /* protect memory base */
struct mtk_iommu_suspend_reg reg;
struct mtk_iommu_domain *m4u_dom;
- struct iommu_group *m4u_group;
+ struct iommu_group *m4u_group[MTK_M4U_DOM_NR_MAX];
bool enable_4GB;
spinlock_t tlb_lock; /* lock for tlb range flush */
@@ -77,6 +77,7 @@ struct mtk_iommu_data {
struct dma_iommu_mapping *mapping; /* For mtk_iommu_v1.c */
+ unsigned int cur_domid;
struct list_head list;
struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
};
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 25/27] iommu/mediatek: Adjust the structure
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (23 preceding siblings ...)
2020-12-09 8:00 ` [PATCH v5 24/27] iommu/mediatek: Add support for multi domain Yong Wu
@ 2020-12-09 8:01 ` Yong Wu
2020-12-09 8:01 ` [PATCH v5 26/27] iommu/mediatek: Add mt8192 support Yong Wu
2020-12-09 8:01 ` [PATCH v5 27/27] MAINTAINERS: Add entry for MediaTek IOMMU Yong Wu
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:01 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Add "struct mtk_iommu_data *" in the "struct mtk_iommu_domain",
reduce the call mtk_iommu_get_m4u_data().
No functional change.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 160690d56bd2..92c1e2f0af89 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -126,6 +126,7 @@ struct mtk_iommu_domain {
struct io_pgtable_cfg cfg;
struct io_pgtable_ops *iop;
+ struct mtk_iommu_data *data;
struct iommu_domain domain;
};
@@ -353,7 +354,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom)
{
- struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
+ struct mtk_iommu_data *data = dom->data;
/* Use the exist domain as there is only one m4u pgtable here. */
if (data->m4u_dom) {
@@ -402,6 +403,7 @@ static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type)
if (iommu_get_dma_cookie(&dom->domain))
goto free_dom;
+ dom->data = data;
if (mtk_iommu_domain_finalise(dom))
goto put_dma_cookie;
@@ -482,10 +484,9 @@ static int mtk_iommu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
- struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
/* The "4GB mode" M4U physically can not use the lower remap of Dram. */
- if (data->enable_4GB)
+ if (dom->data->enable_4GB)
paddr |= BIT_ULL(32);
/* Synchronize with the tlb_lock */
@@ -503,31 +504,32 @@ static size_t mtk_iommu_unmap(struct iommu_domain *domain,
static void mtk_iommu_flush_iotlb_all(struct iommu_domain *domain)
{
- mtk_iommu_tlb_flush_all(mtk_iommu_get_m4u_data());
+ struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+
+ mtk_iommu_tlb_flush_all(dom->data);
}
static void mtk_iommu_iotlb_sync(struct iommu_domain *domain,
struct iommu_iotlb_gather *gather)
{
- struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
+ struct mtk_iommu_domain *dom = to_mtk_domain(domain);
size_t length = gather->end - gather->start;
if (gather->start == ULONG_MAX)
return;
mtk_iommu_tlb_flush_range_sync(gather->start, length, gather->pgsize,
- data);
+ dom->data);
}
static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
dma_addr_t iova)
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
- struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
phys_addr_t pa;
pa = dom->iop->iova_to_phys(dom->iop, iova);
- if (data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE)
+ if (dom->data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE)
pa &= ~BIT_ULL(32);
return pa;
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 26/27] iommu/mediatek: Add mt8192 support
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (24 preceding siblings ...)
2020-12-09 8:01 ` [PATCH v5 25/27] iommu/mediatek: Adjust the structure Yong Wu
@ 2020-12-09 8:01 ` Yong Wu
2020-12-09 8:01 ` [PATCH v5 27/27] MAINTAINERS: Add entry for MediaTek IOMMU Yong Wu
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:01 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
Add mt8192 iommu support.
For multi domain, Add 1M gap for the vdec domain size. That is because
vdec HW has a end address register which require (start_addr +
len) rather than (start_addr + len - 1). Take a example, if the start_addr
is 0xfff00000, size is 0x100000, then the end_address is 0xfff00000 +
0x100000 = 0x1 0000 0000. but the register only is 32bit. thus HW will get
the end address is 0. To avoid this issue, I add 1M gap for this.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 22 ++++++++++++++++++++++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 92c1e2f0af89..799adf7b39d3 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -174,6 +174,16 @@ static const struct mtk_iommu_iova_region single_domain[] = {
{.iova_base = 0, .size = SZ_4G},
};
+static const struct mtk_iommu_iova_region mt8192_multi_dom[] = {
+ { .iova_base = 0x0, .size = SZ_4G}, /* disp: 0 ~ 4G */
+ #if IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT)
+ { .iova_base = SZ_4G, .size = SZ_4G - SZ_1M}, /* vdec: 4G ~ 8G gap: 1M */
+ { .iova_base = SZ_4G * 2, .size = SZ_4G - SZ_1M}, /* CAM/MDP: 8G ~ 12G */
+ { .iova_base = 0x240000000ULL, .size = 0x4000000}, /* CCU0 */
+ { .iova_base = 0x244000000ULL, .size = 0x4000000}, /* CCU1 */
+ #endif
+};
+
/*
* There may be 1 or 2 M4U HWs, But we always expect they are in the same domain
* for the performance.
@@ -1035,12 +1045,24 @@ static const struct mtk_iommu_plat_data mt8183_data = {
.larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
};
+static const struct mtk_iommu_plat_data mt8192_data = {
+ .m4u_plat = M4U_MT8192,
+ .flags = HAS_BCLK | HAS_SUB_COMM | OUT_ORDER_WR_EN |
+ WR_THROT_EN | IOVA_34_EN,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
+ .iova_region = mt8192_multi_dom,
+ .iova_region_nr = ARRAY_SIZE(mt8192_multi_dom),
+ .larbid_remap = {{0}, {1}, {4, 5}, {7}, {2}, {9, 11, 19, 20},
+ {0, 14, 16}, {0, 13, 18, 17}},
+};
+
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,mt8167-m4u", .data = &mt8167_data},
{ .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
{ .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
+ { .compatible = "mediatek,mt8192-m4u", .data = &mt8192_data},
{}
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index b54862307128..e96b1b8639f4 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -43,6 +43,7 @@ enum mtk_iommu_plat {
M4U_MT8167,
M4U_MT8173,
M4U_MT8183,
+ M4U_MT8192,
};
struct mtk_iommu_iova_region;
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread* [PATCH v5 27/27] MAINTAINERS: Add entry for MediaTek IOMMU
2020-12-09 8:00 [PATCH v5 00/27] MT8192 IOMMU support Yong Wu
` (25 preceding siblings ...)
2020-12-09 8:01 ` [PATCH v5 26/27] iommu/mediatek: Add mt8192 support Yong Wu
@ 2020-12-09 8:01 ` Yong Wu
26 siblings, 0 replies; 56+ messages in thread
From: Yong Wu @ 2020-12-09 8:01 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Rob Herring, Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, srv_heupstream,
chao.hao, linux-kernel, Evan Green, Tomasz Figa, iommu,
linux-mediatek, Krzysztof Kozlowski, anan.sun, linux-arm-kernel
I am the author of MediaTek iommu driver, and will to maintain and
develop it further.
Add myself to cover these items.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e73636b75f29..462a87ee19c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11056,6 +11056,15 @@ S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
F: drivers/i2c/busses/i2c-mt65xx.c
+MEDIATEK IOMMU DRIVER
+M: Yong Wu <yong.wu@mediatek.com>
+L: iommu@lists.linux-foundation.org
+L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
+S: Supported
+F: Documentation/devicetree/bindings/iommu/mediatek*
+F: drivers/iommu/mtk-iommu*
+F: include/dt-bindings/memory/mt*-larb-port.h
+
MEDIATEK JPEG DRIVER
M: Rick Chang <rick.chang@mediatek.com>
M: Bin Liu <bin.liu@mediatek.com>
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 56+ messages in thread