* [PATCH v5 00/10] MT6779 IOMMU SUPPORT
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
This patchset adds mt6779 iommu support.
mt6779 has two iommus, they are MM_IOMMU(M4U) and APU_IOMMU which used ARM Short-Descriptor translation format.
The mt6779's MM_IOMMU-SMI and APU_IOMMU HW diagram is as below, it is only a brief diagram:
EMI
|
--------------------------------------
| |
MM_IOMMU APU_IOMMU
| |
SMI_COMMOM----------- APU_BUS
| | |
SMI_LARB(0~11) | |
| | |
| | --------------
| | | | |
Multimedia engine CCU VPU MDLA EMDA
All the connections are hardware fixed, software can not adjust it.
Compared with mt8183, SMI_BUS_ID width has changed from 10 to 12. SMI Larb number is described in bit[11:7],
Port number is described in bit[6:2]. In addition, there are some registers has changed in mt6779, so we need
to redefine and reuse them.
The patchset only used MM_IOMMU, so we only add MM_IOMMU basic function, such as smi_larb port definition, registers
definition and hardware initialization.
change notes:
v5:
1. Split "iommu/mediatek: Add mt6779 IOMMU basic support(patch v4)" to three patches(from PATCH v5 08/10 to PATCH v5 10/10).
2. Use macro definitions to replace bool values in mtk_iommu_plat_data structure
v4:
1. Rebase on v5.8-rc1.
2. Fix coding style.
3. Add F_MMU_IN_DRDER_WR_EN definition in MISC_CTRL to improve performance.
https://lkml.org/lkml/2020/6/16/1741
v3:
1. Rebase on v5.7-rc1.
2. Remove unused port definition,ex:APU and CCU port in mt6779-larb-port.h.
3. Remove "change single domain to multiple domain" part(from PATCH v2 09/19 to PATCH v2 19/19).
4. Redesign mt6779 basic part
(1)Add some register definition and reuse them.
(2)Redesign smi larb bus ID to analyze IOMMU translation fault.
(3)Only init MM_IOMMU and not use APU_IOMMU.
http://lists.infradead.org/pipermail/linux-mediatek/2020-May/029811.html
v2:
1. Rebase on v5.5-rc1.
2. Delete M4U_PORT_UNKNOWN define because of not use it.
3. Correct coding format.
4. Rename offset=0x48 register.
5. Split "iommu/mediatek: Add mt6779 IOMMU basic support(patch v1)" to several patches(patch v2).
http://lists.infradead.org/pipermail/linux-mediatek/2020-January/026131.html
v1:
http://lists.infradead.org/pipermail/linux-mediatek/2019-November/024567.html
Chao Hao (10):
dt-bindings: mediatek: Add bindings for MT6779
iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
iommu/mediatek: Setting MISC_CTRL register
iommu/mediatek: Move inv_sel_reg into the plat_data
iommu/mediatek: Add sub_comm id in translation fault
iommu/mediatek: Add REG_MMU_WR_LEN register definition
iommu/mediatek: Extend protect pa alignment value
iommu/mediatek: Modify MMU_CTRL register setting
iommu/mediatek: Add mt6779 basic support
.../bindings/iommu/mediatek,iommu.txt | 2 +
drivers/iommu/mtk_iommu.c | 100 ++++++---
drivers/iommu/mtk_iommu.h | 26 ++-
include/dt-bindings/memory/mt6779-larb-port.h | 206 ++++++++++++++++++
include/soc/mediatek/smi.h | 2 +
5 files changed, 299 insertions(+), 37 deletions(-)
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* [PATCH v5 00/10] MT6779 IOMMU SUPPORT
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
This patchset adds mt6779 iommu support.
mt6779 has two iommus, they are MM_IOMMU(M4U) and APU_IOMMU which used ARM Short-Descriptor translation format.
The mt6779's MM_IOMMU-SMI and APU_IOMMU HW diagram is as below, it is only a brief diagram:
EMI
|
--------------------------------------
| |
MM_IOMMU APU_IOMMU
| |
SMI_COMMOM----------- APU_BUS
| | |
SMI_LARB(0~11) | |
| | |
| | --------------
| | | | |
Multimedia engine CCU VPU MDLA EMDA
All the connections are hardware fixed, software can not adjust it.
Compared with mt8183, SMI_BUS_ID width has changed from 10 to 12. SMI Larb number is described in bit[11:7],
Port number is described in bit[6:2]. In addition, there are some registers has changed in mt6779, so we need
to redefine and reuse them.
The patchset only used MM_IOMMU, so we only add MM_IOMMU basic function, such as smi_larb port definition, registers
definition and hardware initialization.
change notes:
v5:
1. Split "iommu/mediatek: Add mt6779 IOMMU basic support(patch v4)" to three patches(from PATCH v5 08/10 to PATCH v5 10/10).
2. Use macro definitions to replace bool values in mtk_iommu_plat_data structure
v4:
1. Rebase on v5.8-rc1.
2. Fix coding style.
3. Add F_MMU_IN_DRDER_WR_EN definition in MISC_CTRL to improve performance.
https://lkml.org/lkml/2020/6/16/1741
v3:
1. Rebase on v5.7-rc1.
2. Remove unused port definition,ex:APU and CCU port in mt6779-larb-port.h.
3. Remove "change single domain to multiple domain" part(from PATCH v2 09/19 to PATCH v2 19/19).
4. Redesign mt6779 basic part
(1)Add some register definition and reuse them.
(2)Redesign smi larb bus ID to analyze IOMMU translation fault.
(3)Only init MM_IOMMU and not use APU_IOMMU.
http://lists.infradead.org/pipermail/linux-mediatek/2020-May/029811.html
v2:
1. Rebase on v5.5-rc1.
2. Delete M4U_PORT_UNKNOWN define because of not use it.
3. Correct coding format.
4. Rename offset=0x48 register.
5. Split "iommu/mediatek: Add mt6779 IOMMU basic support(patch v1)" to several patches(patch v2).
http://lists.infradead.org/pipermail/linux-mediatek/2020-January/026131.html
v1:
http://lists.infradead.org/pipermail/linux-mediatek/2019-November/024567.html
Chao Hao (10):
dt-bindings: mediatek: Add bindings for MT6779
iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
iommu/mediatek: Setting MISC_CTRL register
iommu/mediatek: Move inv_sel_reg into the plat_data
iommu/mediatek: Add sub_comm id in translation fault
iommu/mediatek: Add REG_MMU_WR_LEN register definition
iommu/mediatek: Extend protect pa alignment value
iommu/mediatek: Modify MMU_CTRL register setting
iommu/mediatek: Add mt6779 basic support
.../bindings/iommu/mediatek,iommu.txt | 2 +
drivers/iommu/mtk_iommu.c | 100 ++++++---
drivers/iommu/mtk_iommu.h | 26 ++-
include/dt-bindings/memory/mt6779-larb-port.h | 206 ++++++++++++++++++
include/soc/mediatek/smi.h | 2 +
5 files changed, 299 insertions(+), 37 deletions(-)
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* [PATCH v5 00/10] MT6779 IOMMU SUPPORT
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
This patchset adds mt6779 iommu support.
mt6779 has two iommus, they are MM_IOMMU(M4U) and APU_IOMMU which used ARM Short-Descriptor translation format.
The mt6779's MM_IOMMU-SMI and APU_IOMMU HW diagram is as below, it is only a brief diagram:
EMI
|
--------------------------------------
| |
MM_IOMMU APU_IOMMU
| |
SMI_COMMOM----------- APU_BUS
| | |
SMI_LARB(0~11) | |
| | |
| | --------------
| | | | |
Multimedia engine CCU VPU MDLA EMDA
All the connections are hardware fixed, software can not adjust it.
Compared with mt8183, SMI_BUS_ID width has changed from 10 to 12. SMI Larb number is described in bit[11:7],
Port number is described in bit[6:2]. In addition, there are some registers has changed in mt6779, so we need
to redefine and reuse them.
The patchset only used MM_IOMMU, so we only add MM_IOMMU basic function, such as smi_larb port definition, registers
definition and hardware initialization.
change notes:
v5:
1. Split "iommu/mediatek: Add mt6779 IOMMU basic support(patch v4)" to three patches(from PATCH v5 08/10 to PATCH v5 10/10).
2. Use macro definitions to replace bool values in mtk_iommu_plat_data structure
v4:
1. Rebase on v5.8-rc1.
2. Fix coding style.
3. Add F_MMU_IN_DRDER_WR_EN definition in MISC_CTRL to improve performance.
https://lkml.org/lkml/2020/6/16/1741
v3:
1. Rebase on v5.7-rc1.
2. Remove unused port definition,ex:APU and CCU port in mt6779-larb-port.h.
3. Remove "change single domain to multiple domain" part(from PATCH v2 09/19 to PATCH v2 19/19).
4. Redesign mt6779 basic part
(1)Add some register definition and reuse them.
(2)Redesign smi larb bus ID to analyze IOMMU translation fault.
(3)Only init MM_IOMMU and not use APU_IOMMU.
http://lists.infradead.org/pipermail/linux-mediatek/2020-May/029811.html
v2:
1. Rebase on v5.5-rc1.
2. Delete M4U_PORT_UNKNOWN define because of not use it.
3. Correct coding format.
4. Rename offset=0x48 register.
5. Split "iommu/mediatek: Add mt6779 IOMMU basic support(patch v1)" to several patches(patch v2).
http://lists.infradead.org/pipermail/linux-mediatek/2020-January/026131.html
v1:
http://lists.infradead.org/pipermail/linux-mediatek/2019-November/024567.html
Chao Hao (10):
dt-bindings: mediatek: Add bindings for MT6779
iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
iommu/mediatek: Setting MISC_CTRL register
iommu/mediatek: Move inv_sel_reg into the plat_data
iommu/mediatek: Add sub_comm id in translation fault
iommu/mediatek: Add REG_MMU_WR_LEN register definition
iommu/mediatek: Extend protect pa alignment value
iommu/mediatek: Modify MMU_CTRL register setting
iommu/mediatek: Add mt6779 basic support
.../bindings/iommu/mediatek,iommu.txt | 2 +
drivers/iommu/mtk_iommu.c | 100 ++++++---
drivers/iommu/mtk_iommu.h | 26 ++-
include/dt-bindings/memory/mt6779-larb-port.h | 206 ++++++++++++++++++
include/soc/mediatek/smi.h | 2 +
5 files changed, 299 insertions(+), 37 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* [PATCH v5 01/10] dt-bindings: mediatek: Add bindings for MT6779
2020-06-29 7:13 ` Chao Hao
(?)
@ 2020-06-29 7:13 ` Chao Hao
-1 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
This patch adds description for MT6779 IOMMU.
MT6779 has two iommus, they are mm_iommu and apu_iommu which
both use ARM Short-Descriptor translation format.
In addition, mm_iommu and apu_iommu are two independent HW instance
, we need to set them separately.
The MT6779 IOMMU hardware diagram is as below, it is only a brief
diagram about iommu, it don't focus on the part of smi_larb, so
I don't describe the smi_larb detailedly.
EMI
|
--------------------------------------
| |
MM_IOMMU APU_IOMMU
| |
SMI_COMMOM----------- APU_BUS
| | |
SMI_LARB(0~11) | |
| | |
| | --------------
| | | | |
Multimedia engine CCU VPU MDLA EMDA
All the connections are hardware fixed, software can not adjust it.
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Rob Herring <robh+dt@kernel.org>
---
.../bindings/iommu/mediatek,iommu.txt | 2 +
include/dt-bindings/memory/mt6779-larb-port.h | 206 ++++++++++++++++++
2 files changed, 208 insertions(+)
create mode 100644 include/dt-bindings/memory/mt6779-larb-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
index ce59a505f5a4..c1ccd8582eb2 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -58,6 +58,7 @@ 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,mt8173-m4u" for mt8173 which uses generation two m4u HW.
@@ -78,6 +79,7 @@ Required properties:
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/mt8173-larb-port.h for mt8173, and
dt-binding/memory/mt8183-larb-port.h for mt8183.
diff --git a/include/dt-bindings/memory/mt6779-larb-port.h b/include/dt-bindings/memory/mt6779-larb-port.h
new file mode 100644
index 000000000000..2ad0899fbf2f
--- /dev/null
+++ b/include/dt-bindings/memory/mt6779-larb-port.h
@@ -0,0 +1,206 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Chao Hao <chao.hao@mediatek.com>
+ */
+
+#ifndef _DTS_IOMMU_PORT_MT6779_H_
+#define _DTS_IOMMU_PORT_MT6779_H_
+
+#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+
+#define M4U_LARB0_ID 0
+#define M4U_LARB1_ID 1
+#define M4U_LARB2_ID 2
+#define M4U_LARB3_ID 3
+#define M4U_LARB4_ID 4
+#define M4U_LARB5_ID 5
+#define M4U_LARB6_ID 6
+#define M4U_LARB7_ID 7
+#define M4U_LARB8_ID 8
+#define M4U_LARB9_ID 9
+#define M4U_LARB10_ID 10
+#define M4U_LARB11_ID 11
+
+/* larb0 */
+#define M4U_PORT_DISP_POSTMASK0 MTK_M4U_ID(M4U_LARB0_ID, 0)
+#define M4U_PORT_DISP_OVL0_HDR MTK_M4U_ID(M4U_LARB0_ID, 1)
+#define M4U_PORT_DISP_OVL1_HDR MTK_M4U_ID(M4U_LARB0_ID, 2)
+#define M4U_PORT_DISP_OVL0 MTK_M4U_ID(M4U_LARB0_ID, 3)
+#define M4U_PORT_DISP_OVL1 MTK_M4U_ID(M4U_LARB0_ID, 4)
+#define M4U_PORT_DISP_PVRIC0 MTK_M4U_ID(M4U_LARB0_ID, 5)
+#define M4U_PORT_DISP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 6)
+#define M4U_PORT_DISP_WDMA0 MTK_M4U_ID(M4U_LARB0_ID, 7)
+#define M4U_PORT_DISP_FAKE0 MTK_M4U_ID(M4U_LARB0_ID, 8)
+
+/* larb1 */
+#define M4U_PORT_DISP_OVL0_2L_HDR MTK_M4U_ID(M4U_LARB1_ID, 0)
+#define M4U_PORT_DISP_OVL1_2L_HDR MTK_M4U_ID(M4U_LARB1_ID, 1)
+#define M4U_PORT_DISP_OVL0_2L MTK_M4U_ID(M4U_LARB1_ID, 2)
+#define M4U_PORT_DISP_OVL1_2L MTK_M4U_ID(M4U_LARB1_ID, 3)
+#define M4U_PORT_DISP_RDMA1 MTK_M4U_ID(M4U_LARB1_ID, 4)
+#define M4U_PORT_MDP_PVRIC0 MTK_M4U_ID(M4U_LARB1_ID, 5)
+#define M4U_PORT_MDP_PVRIC1 MTK_M4U_ID(M4U_LARB1_ID, 6)
+#define M4U_PORT_MDP_RDMA0 MTK_M4U_ID(M4U_LARB1_ID, 7)
+#define M4U_PORT_MDP_RDMA1 MTK_M4U_ID(M4U_LARB1_ID, 8)
+#define M4U_PORT_MDP_WROT0_R MTK_M4U_ID(M4U_LARB1_ID, 9)
+#define M4U_PORT_MDP_WROT0_W MTK_M4U_ID(M4U_LARB1_ID, 10)
+#define M4U_PORT_MDP_WROT1_R MTK_M4U_ID(M4U_LARB1_ID, 11)
+#define M4U_PORT_MDP_WROT1_W MTK_M4U_ID(M4U_LARB1_ID, 12)
+#define M4U_PORT_DISP_FAKE1 MTK_M4U_ID(M4U_LARB1_ID, 13)
+
+/* larb2-VDEC */
+#define M4U_PORT_HW_VDEC_MC_EXT MTK_M4U_ID(M4U_LARB2_ID, 0)
+#define M4U_PORT_HW_VDEC_UFO_EXT MTK_M4U_ID(M4U_LARB2_ID, 1)
+#define M4U_PORT_HW_VDEC_PP_EXT MTK_M4U_ID(M4U_LARB2_ID, 2)
+#define M4U_PORT_HW_VDEC_PRED_RD_EXT MTK_M4U_ID(M4U_LARB2_ID, 3)
+#define M4U_PORT_HW_VDEC_PRED_WR_EXT MTK_M4U_ID(M4U_LARB2_ID, 4)
+#define M4U_PORT_HW_VDEC_PPWRAP_EXT MTK_M4U_ID(M4U_LARB2_ID, 5)
+#define M4U_PORT_HW_VDEC_TILE_EXT MTK_M4U_ID(M4U_LARB2_ID, 6)
+#define M4U_PORT_HW_VDEC_VLD_EXT MTK_M4U_ID(M4U_LARB2_ID, 7)
+#define M4U_PORT_HW_VDEC_VLD2_EXT MTK_M4U_ID(M4U_LARB2_ID, 8)
+#define M4U_PORT_HW_VDEC_AVC_MV_EXT MTK_M4U_ID(M4U_LARB2_ID, 9)
+#define M4U_PORT_HW_VDEC_UFO_ENC_EXT MTK_M4U_ID(M4U_LARB2_ID, 10)
+#define M4U_PORT_HW_VDEC_RG_CTRL_DMA_EXT MTK_M4U_ID(M4U_LARB2_ID, 11)
+
+/* larb3-VENC */
+#define M4U_PORT_VENC_RCPU MTK_M4U_ID(M4U_LARB3_ID, 0)
+#define M4U_PORT_VENC_REC MTK_M4U_ID(M4U_LARB3_ID, 1)
+#define M4U_PORT_VENC_BSDMA MTK_M4U_ID(M4U_LARB3_ID, 2)
+#define M4U_PORT_VENC_SV_COMV MTK_M4U_ID(M4U_LARB3_ID, 3)
+#define M4U_PORT_VENC_RD_COMV MTK_M4U_ID(M4U_LARB3_ID, 4)
+#define M4U_PORT_VENC_NBM_RDMA MTK_M4U_ID(M4U_LARB3_ID, 5)
+#define M4U_PORT_VENC_NBM_RDMA_LITE MTK_M4U_ID(M4U_LARB3_ID, 6)
+#define M4U_PORT_JPGENC_Y_RDMA MTK_M4U_ID(M4U_LARB3_ID, 7)
+#define M4U_PORT_JPGENC_C_RDMA MTK_M4U_ID(M4U_LARB3_ID, 8)
+#define M4U_PORT_JPGENC_Q_TABLE MTK_M4U_ID(M4U_LARB3_ID, 9)
+#define M4U_PORT_JPGENC_BSDMA MTK_M4U_ID(M4U_LARB3_ID, 10)
+#define M4U_PORT_JPGDEC_WDMA MTK_M4U_ID(M4U_LARB3_ID, 11)
+#define M4U_PORT_JPGDEC_BSDMA MTK_M4U_ID(M4U_LARB3_ID, 12)
+#define M4U_PORT_VENC_NBM_WDMA MTK_M4U_ID(M4U_LARB3_ID, 13)
+#define M4U_PORT_VENC_NBM_WDMA_LITE MTK_M4U_ID(M4U_LARB3_ID, 14)
+#define M4U_PORT_VENC_CUR_LUMA MTK_M4U_ID(M4U_LARB3_ID, 15)
+#define M4U_PORT_VENC_CUR_CHROMA MTK_M4U_ID(M4U_LARB3_ID, 16)
+#define M4U_PORT_VENC_REF_LUMA MTK_M4U_ID(M4U_LARB3_ID, 17)
+#define M4U_PORT_VENC_REF_CHROMA MTK_M4U_ID(M4U_LARB3_ID, 18)
+
+/* larb4-dummy */
+
+/* larb5-IMG */
+#define M4U_PORT_IMGI_D1 MTK_M4U_ID(M4U_LARB5_ID, 0)
+#define M4U_PORT_IMGBI_D1 MTK_M4U_ID(M4U_LARB5_ID, 1)
+#define M4U_PORT_DMGI_D1 MTK_M4U_ID(M4U_LARB5_ID, 2)
+#define M4U_PORT_DEPI_D1 MTK_M4U_ID(M4U_LARB5_ID, 3)
+#define M4U_PORT_LCEI_D1 MTK_M4U_ID(M4U_LARB5_ID, 4)
+#define M4U_PORT_SMTI_D1 MTK_M4U_ID(M4U_LARB5_ID, 5)
+#define M4U_PORT_SMTO_D2 MTK_M4U_ID(M4U_LARB5_ID, 6)
+#define M4U_PORT_SMTO_D1 MTK_M4U_ID(M4U_LARB5_ID, 7)
+#define M4U_PORT_CRZO_D1 MTK_M4U_ID(M4U_LARB5_ID, 8)
+#define M4U_PORT_IMG3O_D1 MTK_M4U_ID(M4U_LARB5_ID, 9)
+#define M4U_PORT_VIPI_D1 MTK_M4U_ID(M4U_LARB5_ID, 10)
+#define M4U_PORT_WPE_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 11)
+#define M4U_PORT_WPE_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 12)
+#define M4U_PORT_WPE_WDMA MTK_M4U_ID(M4U_LARB5_ID, 13)
+#define M4U_PORT_TIMGO_D1 MTK_M4U_ID(M4U_LARB5_ID, 14)
+#define M4U_PORT_MFB_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 15)
+#define M4U_PORT_MFB_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 16)
+#define M4U_PORT_MFB_RDMA2 MTK_M4U_ID(M4U_LARB5_ID, 17)
+#define M4U_PORT_MFB_RDMA3 MTK_M4U_ID(M4U_LARB5_ID, 18)
+#define M4U_PORT_MFB_WDMA MTK_M4U_ID(M4U_LARB5_ID, 19)
+#define M4U_PORT_RESERVE1 MTK_M4U_ID(M4U_LARB5_ID, 20)
+#define M4U_PORT_RESERVE2 MTK_M4U_ID(M4U_LARB5_ID, 21)
+#define M4U_PORT_RESERVE3 MTK_M4U_ID(M4U_LARB5_ID, 22)
+#define M4U_PORT_RESERVE4 MTK_M4U_ID(M4U_LARB5_ID, 23)
+#define M4U_PORT_RESERVE5 MTK_M4U_ID(M4U_LARB5_ID, 24)
+#define M4U_PORT_RESERVE6 MTK_M4U_ID(M4U_LARB5_ID, 25)
+
+/* larb6-IMG-VPU */
+#define M4U_PORT_IMG_IPUO MTK_M4U_ID(M4U_LARB6_ID, 0)
+#define M4U_PORT_IMG_IPU3O MTK_M4U_ID(M4U_LARB6_ID, 1)
+#define M4U_PORT_IMG_IPUI MTK_M4U_ID(M4U_LARB6_ID, 2)
+
+/* larb7-DVS */
+#define M4U_PORT_DVS_RDMA MTK_M4U_ID(M4U_LARB7_ID, 0)
+#define M4U_PORT_DVS_WDMA MTK_M4U_ID(M4U_LARB7_ID, 1)
+#define M4U_PORT_DVP_RDMA MTK_M4U_ID(M4U_LARB7_ID, 2)
+#define M4U_PORT_DVP_WDMA MTK_M4U_ID(M4U_LARB7_ID, 3)
+
+/* larb8-IPESYS */
+#define M4U_PORT_FDVT_RDA MTK_M4U_ID(M4U_LARB8_ID, 0)
+#define M4U_PORT_FDVT_RDB MTK_M4U_ID(M4U_LARB8_ID, 1)
+#define M4U_PORT_FDVT_WRA MTK_M4U_ID(M4U_LARB8_ID, 2)
+#define M4U_PORT_FDVT_WRB MTK_M4U_ID(M4U_LARB8_ID, 3)
+#define M4U_PORT_FE_RD0 MTK_M4U_ID(M4U_LARB8_ID, 4)
+#define M4U_PORT_FE_RD1 MTK_M4U_ID(M4U_LARB8_ID, 5)
+#define M4U_PORT_FE_WR0 MTK_M4U_ID(M4U_LARB8_ID, 6)
+#define M4U_PORT_FE_WR1 MTK_M4U_ID(M4U_LARB8_ID, 7)
+#define M4U_PORT_RSC_RDMA0 MTK_M4U_ID(M4U_LARB8_ID, 8)
+#define M4U_PORT_RSC_WDMA MTK_M4U_ID(M4U_LARB8_ID, 9)
+
+/* larb9-CAM */
+#define M4U_PORT_CAM_IMGO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 0)
+#define M4U_PORT_CAM_RRZO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 1)
+#define M4U_PORT_CAM_LSCI_R1_C MTK_M4U_ID(M4U_LARB9_ID, 2)
+#define M4U_PORT_CAM_BPCI_R1_C MTK_M4U_ID(M4U_LARB9_ID, 3)
+#define M4U_PORT_CAM_YUVO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 4)
+#define M4U_PORT_CAM_UFDI_R2_C MTK_M4U_ID(M4U_LARB9_ID, 5)
+#define M4U_PORT_CAM_RAWI_R2_C MTK_M4U_ID(M4U_LARB9_ID, 6)
+#define M4U_PORT_CAM_RAWI_R5_C MTK_M4U_ID(M4U_LARB9_ID, 7)
+#define M4U_PORT_CAM_CAMSV_1 MTK_M4U_ID(M4U_LARB9_ID, 8)
+#define M4U_PORT_CAM_CAMSV_2 MTK_M4U_ID(M4U_LARB9_ID, 9)
+#define M4U_PORT_CAM_CAMSV_3 MTK_M4U_ID(M4U_LARB9_ID, 10)
+#define M4U_PORT_CAM_CAMSV_4 MTK_M4U_ID(M4U_LARB9_ID, 11)
+#define M4U_PORT_CAM_CAMSV_5 MTK_M4U_ID(M4U_LARB9_ID, 12)
+#define M4U_PORT_CAM_CAMSV_6 MTK_M4U_ID(M4U_LARB9_ID, 13)
+#define M4U_PORT_CAM_AAO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 14)
+#define M4U_PORT_CAM_AFO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 15)
+#define M4U_PORT_CAM_FLKO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 16)
+#define M4U_PORT_CAM_LCESO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 17)
+#define M4U_PORT_CAM_CRZO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 18)
+#define M4U_PORT_CAM_LTMSO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 19)
+#define M4U_PORT_CAM_RSSO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 20)
+#define M4U_PORT_CAM_CCUI MTK_M4U_ID(M4U_LARB9_ID, 21)
+#define M4U_PORT_CAM_CCUO MTK_M4U_ID(M4U_LARB9_ID, 22)
+#define M4U_PORT_CAM_FAKE MTK_M4U_ID(M4U_LARB9_ID, 23)
+
+/* larb10-CAM_A */
+#define M4U_PORT_CAM_IMGO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 0)
+#define M4U_PORT_CAM_RRZO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 1)
+#define M4U_PORT_CAM_LSCI_R1_A MTK_M4U_ID(M4U_LARB10_ID, 2)
+#define M4U_PORT_CAM_BPCI_R1_A MTK_M4U_ID(M4U_LARB10_ID, 3)
+#define M4U_PORT_CAM_YUVO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 4)
+#define M4U_PORT_CAM_UFDI_R2_A MTK_M4U_ID(M4U_LARB10_ID, 5)
+#define M4U_PORT_CAM_RAWI_R2_A MTK_M4U_ID(M4U_LARB10_ID, 6)
+#define M4U_PORT_CAM_RAWI_R5_A MTK_M4U_ID(M4U_LARB10_ID, 7)
+#define M4U_PORT_CAM_IMGO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 8)
+#define M4U_PORT_CAM_RRZO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 9)
+#define M4U_PORT_CAM_LSCI_R1_B MTK_M4U_ID(M4U_LARB10_ID, 10)
+#define M4U_PORT_CAM_BPCI_R1_B MTK_M4U_ID(M4U_LARB10_ID, 11)
+#define M4U_PORT_CAM_YUVO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 12)
+#define M4U_PORT_CAM_UFDI_R2_B MTK_M4U_ID(M4U_LARB10_ID, 13)
+#define M4U_PORT_CAM_RAWI_R2_B MTK_M4U_ID(M4U_LARB10_ID, 14)
+#define M4U_PORT_CAM_RAWI_R5_B MTK_M4U_ID(M4U_LARB10_ID, 15)
+#define M4U_PORT_CAM_CAMSV_0 MTK_M4U_ID(M4U_LARB10_ID, 16)
+#define M4U_PORT_CAM_AAO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 17)
+#define M4U_PORT_CAM_AFO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 18)
+#define M4U_PORT_CAM_FLKO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 19)
+#define M4U_PORT_CAM_LCESO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 20)
+#define M4U_PORT_CAM_CRZO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 21)
+#define M4U_PORT_CAM_AAO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 22)
+#define M4U_PORT_CAM_AFO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 23)
+#define M4U_PORT_CAM_FLKO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 24)
+#define M4U_PORT_CAM_LCESO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 25)
+#define M4U_PORT_CAM_CRZO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 26)
+#define M4U_PORT_CAM_LTMSO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 27)
+#define M4U_PORT_CAM_RSSO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 28)
+#define M4U_PORT_CAM_LTMSO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 29)
+#define M4U_PORT_CAM_RSSO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 30)
+
+/* larb11-CAM-VPU */
+#define M4U_PORT_CAM_IPUO MTK_M4U_ID(M4U_LARB11_ID, 0)
+#define M4U_PORT_CAM_IPU2O MTK_M4U_ID(M4U_LARB11_ID, 1)
+#define M4U_PORT_CAM_IPU3O MTK_M4U_ID(M4U_LARB11_ID, 2)
+#define M4U_PORT_CAM_IPUI MTK_M4U_ID(M4U_LARB11_ID, 3)
+#define M4U_PORT_CAM_IPU2I MTK_M4U_ID(M4U_LARB11_ID, 4)
+
+#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] 101+ messages in thread
* [PATCH v5 01/10] dt-bindings: mediatek: Add bindings for MT6779
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
This patch adds description for MT6779 IOMMU.
MT6779 has two iommus, they are mm_iommu and apu_iommu which
both use ARM Short-Descriptor translation format.
In addition, mm_iommu and apu_iommu are two independent HW instance
, we need to set them separately.
The MT6779 IOMMU hardware diagram is as below, it is only a brief
diagram about iommu, it don't focus on the part of smi_larb, so
I don't describe the smi_larb detailedly.
EMI
|
--------------------------------------
| |
MM_IOMMU APU_IOMMU
| |
SMI_COMMOM----------- APU_BUS
| | |
SMI_LARB(0~11) | |
| | |
| | --------------
| | | | |
Multimedia engine CCU VPU MDLA EMDA
All the connections are hardware fixed, software can not adjust it.
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Rob Herring <robh+dt@kernel.org>
---
.../bindings/iommu/mediatek,iommu.txt | 2 +
include/dt-bindings/memory/mt6779-larb-port.h | 206 ++++++++++++++++++
2 files changed, 208 insertions(+)
create mode 100644 include/dt-bindings/memory/mt6779-larb-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
index ce59a505f5a4..c1ccd8582eb2 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -58,6 +58,7 @@ 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,mt8173-m4u" for mt8173 which uses generation two m4u HW.
@@ -78,6 +79,7 @@ Required properties:
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/mt8173-larb-port.h for mt8173, and
dt-binding/memory/mt8183-larb-port.h for mt8183.
diff --git a/include/dt-bindings/memory/mt6779-larb-port.h b/include/dt-bindings/memory/mt6779-larb-port.h
new file mode 100644
index 000000000000..2ad0899fbf2f
--- /dev/null
+++ b/include/dt-bindings/memory/mt6779-larb-port.h
@@ -0,0 +1,206 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Chao Hao <chao.hao@mediatek.com>
+ */
+
+#ifndef _DTS_IOMMU_PORT_MT6779_H_
+#define _DTS_IOMMU_PORT_MT6779_H_
+
+#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+
+#define M4U_LARB0_ID 0
+#define M4U_LARB1_ID 1
+#define M4U_LARB2_ID 2
+#define M4U_LARB3_ID 3
+#define M4U_LARB4_ID 4
+#define M4U_LARB5_ID 5
+#define M4U_LARB6_ID 6
+#define M4U_LARB7_ID 7
+#define M4U_LARB8_ID 8
+#define M4U_LARB9_ID 9
+#define M4U_LARB10_ID 10
+#define M4U_LARB11_ID 11
+
+/* larb0 */
+#define M4U_PORT_DISP_POSTMASK0 MTK_M4U_ID(M4U_LARB0_ID, 0)
+#define M4U_PORT_DISP_OVL0_HDR MTK_M4U_ID(M4U_LARB0_ID, 1)
+#define M4U_PORT_DISP_OVL1_HDR MTK_M4U_ID(M4U_LARB0_ID, 2)
+#define M4U_PORT_DISP_OVL0 MTK_M4U_ID(M4U_LARB0_ID, 3)
+#define M4U_PORT_DISP_OVL1 MTK_M4U_ID(M4U_LARB0_ID, 4)
+#define M4U_PORT_DISP_PVRIC0 MTK_M4U_ID(M4U_LARB0_ID, 5)
+#define M4U_PORT_DISP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 6)
+#define M4U_PORT_DISP_WDMA0 MTK_M4U_ID(M4U_LARB0_ID, 7)
+#define M4U_PORT_DISP_FAKE0 MTK_M4U_ID(M4U_LARB0_ID, 8)
+
+/* larb1 */
+#define M4U_PORT_DISP_OVL0_2L_HDR MTK_M4U_ID(M4U_LARB1_ID, 0)
+#define M4U_PORT_DISP_OVL1_2L_HDR MTK_M4U_ID(M4U_LARB1_ID, 1)
+#define M4U_PORT_DISP_OVL0_2L MTK_M4U_ID(M4U_LARB1_ID, 2)
+#define M4U_PORT_DISP_OVL1_2L MTK_M4U_ID(M4U_LARB1_ID, 3)
+#define M4U_PORT_DISP_RDMA1 MTK_M4U_ID(M4U_LARB1_ID, 4)
+#define M4U_PORT_MDP_PVRIC0 MTK_M4U_ID(M4U_LARB1_ID, 5)
+#define M4U_PORT_MDP_PVRIC1 MTK_M4U_ID(M4U_LARB1_ID, 6)
+#define M4U_PORT_MDP_RDMA0 MTK_M4U_ID(M4U_LARB1_ID, 7)
+#define M4U_PORT_MDP_RDMA1 MTK_M4U_ID(M4U_LARB1_ID, 8)
+#define M4U_PORT_MDP_WROT0_R MTK_M4U_ID(M4U_LARB1_ID, 9)
+#define M4U_PORT_MDP_WROT0_W MTK_M4U_ID(M4U_LARB1_ID, 10)
+#define M4U_PORT_MDP_WROT1_R MTK_M4U_ID(M4U_LARB1_ID, 11)
+#define M4U_PORT_MDP_WROT1_W MTK_M4U_ID(M4U_LARB1_ID, 12)
+#define M4U_PORT_DISP_FAKE1 MTK_M4U_ID(M4U_LARB1_ID, 13)
+
+/* larb2-VDEC */
+#define M4U_PORT_HW_VDEC_MC_EXT MTK_M4U_ID(M4U_LARB2_ID, 0)
+#define M4U_PORT_HW_VDEC_UFO_EXT MTK_M4U_ID(M4U_LARB2_ID, 1)
+#define M4U_PORT_HW_VDEC_PP_EXT MTK_M4U_ID(M4U_LARB2_ID, 2)
+#define M4U_PORT_HW_VDEC_PRED_RD_EXT MTK_M4U_ID(M4U_LARB2_ID, 3)
+#define M4U_PORT_HW_VDEC_PRED_WR_EXT MTK_M4U_ID(M4U_LARB2_ID, 4)
+#define M4U_PORT_HW_VDEC_PPWRAP_EXT MTK_M4U_ID(M4U_LARB2_ID, 5)
+#define M4U_PORT_HW_VDEC_TILE_EXT MTK_M4U_ID(M4U_LARB2_ID, 6)
+#define M4U_PORT_HW_VDEC_VLD_EXT MTK_M4U_ID(M4U_LARB2_ID, 7)
+#define M4U_PORT_HW_VDEC_VLD2_EXT MTK_M4U_ID(M4U_LARB2_ID, 8)
+#define M4U_PORT_HW_VDEC_AVC_MV_EXT MTK_M4U_ID(M4U_LARB2_ID, 9)
+#define M4U_PORT_HW_VDEC_UFO_ENC_EXT MTK_M4U_ID(M4U_LARB2_ID, 10)
+#define M4U_PORT_HW_VDEC_RG_CTRL_DMA_EXT MTK_M4U_ID(M4U_LARB2_ID, 11)
+
+/* larb3-VENC */
+#define M4U_PORT_VENC_RCPU MTK_M4U_ID(M4U_LARB3_ID, 0)
+#define M4U_PORT_VENC_REC MTK_M4U_ID(M4U_LARB3_ID, 1)
+#define M4U_PORT_VENC_BSDMA MTK_M4U_ID(M4U_LARB3_ID, 2)
+#define M4U_PORT_VENC_SV_COMV MTK_M4U_ID(M4U_LARB3_ID, 3)
+#define M4U_PORT_VENC_RD_COMV MTK_M4U_ID(M4U_LARB3_ID, 4)
+#define M4U_PORT_VENC_NBM_RDMA MTK_M4U_ID(M4U_LARB3_ID, 5)
+#define M4U_PORT_VENC_NBM_RDMA_LITE MTK_M4U_ID(M4U_LARB3_ID, 6)
+#define M4U_PORT_JPGENC_Y_RDMA MTK_M4U_ID(M4U_LARB3_ID, 7)
+#define M4U_PORT_JPGENC_C_RDMA MTK_M4U_ID(M4U_LARB3_ID, 8)
+#define M4U_PORT_JPGENC_Q_TABLE MTK_M4U_ID(M4U_LARB3_ID, 9)
+#define M4U_PORT_JPGENC_BSDMA MTK_M4U_ID(M4U_LARB3_ID, 10)
+#define M4U_PORT_JPGDEC_WDMA MTK_M4U_ID(M4U_LARB3_ID, 11)
+#define M4U_PORT_JPGDEC_BSDMA MTK_M4U_ID(M4U_LARB3_ID, 12)
+#define M4U_PORT_VENC_NBM_WDMA MTK_M4U_ID(M4U_LARB3_ID, 13)
+#define M4U_PORT_VENC_NBM_WDMA_LITE MTK_M4U_ID(M4U_LARB3_ID, 14)
+#define M4U_PORT_VENC_CUR_LUMA MTK_M4U_ID(M4U_LARB3_ID, 15)
+#define M4U_PORT_VENC_CUR_CHROMA MTK_M4U_ID(M4U_LARB3_ID, 16)
+#define M4U_PORT_VENC_REF_LUMA MTK_M4U_ID(M4U_LARB3_ID, 17)
+#define M4U_PORT_VENC_REF_CHROMA MTK_M4U_ID(M4U_LARB3_ID, 18)
+
+/* larb4-dummy */
+
+/* larb5-IMG */
+#define M4U_PORT_IMGI_D1 MTK_M4U_ID(M4U_LARB5_ID, 0)
+#define M4U_PORT_IMGBI_D1 MTK_M4U_ID(M4U_LARB5_ID, 1)
+#define M4U_PORT_DMGI_D1 MTK_M4U_ID(M4U_LARB5_ID, 2)
+#define M4U_PORT_DEPI_D1 MTK_M4U_ID(M4U_LARB5_ID, 3)
+#define M4U_PORT_LCEI_D1 MTK_M4U_ID(M4U_LARB5_ID, 4)
+#define M4U_PORT_SMTI_D1 MTK_M4U_ID(M4U_LARB5_ID, 5)
+#define M4U_PORT_SMTO_D2 MTK_M4U_ID(M4U_LARB5_ID, 6)
+#define M4U_PORT_SMTO_D1 MTK_M4U_ID(M4U_LARB5_ID, 7)
+#define M4U_PORT_CRZO_D1 MTK_M4U_ID(M4U_LARB5_ID, 8)
+#define M4U_PORT_IMG3O_D1 MTK_M4U_ID(M4U_LARB5_ID, 9)
+#define M4U_PORT_VIPI_D1 MTK_M4U_ID(M4U_LARB5_ID, 10)
+#define M4U_PORT_WPE_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 11)
+#define M4U_PORT_WPE_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 12)
+#define M4U_PORT_WPE_WDMA MTK_M4U_ID(M4U_LARB5_ID, 13)
+#define M4U_PORT_TIMGO_D1 MTK_M4U_ID(M4U_LARB5_ID, 14)
+#define M4U_PORT_MFB_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 15)
+#define M4U_PORT_MFB_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 16)
+#define M4U_PORT_MFB_RDMA2 MTK_M4U_ID(M4U_LARB5_ID, 17)
+#define M4U_PORT_MFB_RDMA3 MTK_M4U_ID(M4U_LARB5_ID, 18)
+#define M4U_PORT_MFB_WDMA MTK_M4U_ID(M4U_LARB5_ID, 19)
+#define M4U_PORT_RESERVE1 MTK_M4U_ID(M4U_LARB5_ID, 20)
+#define M4U_PORT_RESERVE2 MTK_M4U_ID(M4U_LARB5_ID, 21)
+#define M4U_PORT_RESERVE3 MTK_M4U_ID(M4U_LARB5_ID, 22)
+#define M4U_PORT_RESERVE4 MTK_M4U_ID(M4U_LARB5_ID, 23)
+#define M4U_PORT_RESERVE5 MTK_M4U_ID(M4U_LARB5_ID, 24)
+#define M4U_PORT_RESERVE6 MTK_M4U_ID(M4U_LARB5_ID, 25)
+
+/* larb6-IMG-VPU */
+#define M4U_PORT_IMG_IPUO MTK_M4U_ID(M4U_LARB6_ID, 0)
+#define M4U_PORT_IMG_IPU3O MTK_M4U_ID(M4U_LARB6_ID, 1)
+#define M4U_PORT_IMG_IPUI MTK_M4U_ID(M4U_LARB6_ID, 2)
+
+/* larb7-DVS */
+#define M4U_PORT_DVS_RDMA MTK_M4U_ID(M4U_LARB7_ID, 0)
+#define M4U_PORT_DVS_WDMA MTK_M4U_ID(M4U_LARB7_ID, 1)
+#define M4U_PORT_DVP_RDMA MTK_M4U_ID(M4U_LARB7_ID, 2)
+#define M4U_PORT_DVP_WDMA MTK_M4U_ID(M4U_LARB7_ID, 3)
+
+/* larb8-IPESYS */
+#define M4U_PORT_FDVT_RDA MTK_M4U_ID(M4U_LARB8_ID, 0)
+#define M4U_PORT_FDVT_RDB MTK_M4U_ID(M4U_LARB8_ID, 1)
+#define M4U_PORT_FDVT_WRA MTK_M4U_ID(M4U_LARB8_ID, 2)
+#define M4U_PORT_FDVT_WRB MTK_M4U_ID(M4U_LARB8_ID, 3)
+#define M4U_PORT_FE_RD0 MTK_M4U_ID(M4U_LARB8_ID, 4)
+#define M4U_PORT_FE_RD1 MTK_M4U_ID(M4U_LARB8_ID, 5)
+#define M4U_PORT_FE_WR0 MTK_M4U_ID(M4U_LARB8_ID, 6)
+#define M4U_PORT_FE_WR1 MTK_M4U_ID(M4U_LARB8_ID, 7)
+#define M4U_PORT_RSC_RDMA0 MTK_M4U_ID(M4U_LARB8_ID, 8)
+#define M4U_PORT_RSC_WDMA MTK_M4U_ID(M4U_LARB8_ID, 9)
+
+/* larb9-CAM */
+#define M4U_PORT_CAM_IMGO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 0)
+#define M4U_PORT_CAM_RRZO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 1)
+#define M4U_PORT_CAM_LSCI_R1_C MTK_M4U_ID(M4U_LARB9_ID, 2)
+#define M4U_PORT_CAM_BPCI_R1_C MTK_M4U_ID(M4U_LARB9_ID, 3)
+#define M4U_PORT_CAM_YUVO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 4)
+#define M4U_PORT_CAM_UFDI_R2_C MTK_M4U_ID(M4U_LARB9_ID, 5)
+#define M4U_PORT_CAM_RAWI_R2_C MTK_M4U_ID(M4U_LARB9_ID, 6)
+#define M4U_PORT_CAM_RAWI_R5_C MTK_M4U_ID(M4U_LARB9_ID, 7)
+#define M4U_PORT_CAM_CAMSV_1 MTK_M4U_ID(M4U_LARB9_ID, 8)
+#define M4U_PORT_CAM_CAMSV_2 MTK_M4U_ID(M4U_LARB9_ID, 9)
+#define M4U_PORT_CAM_CAMSV_3 MTK_M4U_ID(M4U_LARB9_ID, 10)
+#define M4U_PORT_CAM_CAMSV_4 MTK_M4U_ID(M4U_LARB9_ID, 11)
+#define M4U_PORT_CAM_CAMSV_5 MTK_M4U_ID(M4U_LARB9_ID, 12)
+#define M4U_PORT_CAM_CAMSV_6 MTK_M4U_ID(M4U_LARB9_ID, 13)
+#define M4U_PORT_CAM_AAO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 14)
+#define M4U_PORT_CAM_AFO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 15)
+#define M4U_PORT_CAM_FLKO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 16)
+#define M4U_PORT_CAM_LCESO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 17)
+#define M4U_PORT_CAM_CRZO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 18)
+#define M4U_PORT_CAM_LTMSO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 19)
+#define M4U_PORT_CAM_RSSO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 20)
+#define M4U_PORT_CAM_CCUI MTK_M4U_ID(M4U_LARB9_ID, 21)
+#define M4U_PORT_CAM_CCUO MTK_M4U_ID(M4U_LARB9_ID, 22)
+#define M4U_PORT_CAM_FAKE MTK_M4U_ID(M4U_LARB9_ID, 23)
+
+/* larb10-CAM_A */
+#define M4U_PORT_CAM_IMGO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 0)
+#define M4U_PORT_CAM_RRZO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 1)
+#define M4U_PORT_CAM_LSCI_R1_A MTK_M4U_ID(M4U_LARB10_ID, 2)
+#define M4U_PORT_CAM_BPCI_R1_A MTK_M4U_ID(M4U_LARB10_ID, 3)
+#define M4U_PORT_CAM_YUVO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 4)
+#define M4U_PORT_CAM_UFDI_R2_A MTK_M4U_ID(M4U_LARB10_ID, 5)
+#define M4U_PORT_CAM_RAWI_R2_A MTK_M4U_ID(M4U_LARB10_ID, 6)
+#define M4U_PORT_CAM_RAWI_R5_A MTK_M4U_ID(M4U_LARB10_ID, 7)
+#define M4U_PORT_CAM_IMGO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 8)
+#define M4U_PORT_CAM_RRZO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 9)
+#define M4U_PORT_CAM_LSCI_R1_B MTK_M4U_ID(M4U_LARB10_ID, 10)
+#define M4U_PORT_CAM_BPCI_R1_B MTK_M4U_ID(M4U_LARB10_ID, 11)
+#define M4U_PORT_CAM_YUVO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 12)
+#define M4U_PORT_CAM_UFDI_R2_B MTK_M4U_ID(M4U_LARB10_ID, 13)
+#define M4U_PORT_CAM_RAWI_R2_B MTK_M4U_ID(M4U_LARB10_ID, 14)
+#define M4U_PORT_CAM_RAWI_R5_B MTK_M4U_ID(M4U_LARB10_ID, 15)
+#define M4U_PORT_CAM_CAMSV_0 MTK_M4U_ID(M4U_LARB10_ID, 16)
+#define M4U_PORT_CAM_AAO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 17)
+#define M4U_PORT_CAM_AFO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 18)
+#define M4U_PORT_CAM_FLKO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 19)
+#define M4U_PORT_CAM_LCESO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 20)
+#define M4U_PORT_CAM_CRZO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 21)
+#define M4U_PORT_CAM_AAO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 22)
+#define M4U_PORT_CAM_AFO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 23)
+#define M4U_PORT_CAM_FLKO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 24)
+#define M4U_PORT_CAM_LCESO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 25)
+#define M4U_PORT_CAM_CRZO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 26)
+#define M4U_PORT_CAM_LTMSO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 27)
+#define M4U_PORT_CAM_RSSO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 28)
+#define M4U_PORT_CAM_LTMSO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 29)
+#define M4U_PORT_CAM_RSSO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 30)
+
+/* larb11-CAM-VPU */
+#define M4U_PORT_CAM_IPUO MTK_M4U_ID(M4U_LARB11_ID, 0)
+#define M4U_PORT_CAM_IPU2O MTK_M4U_ID(M4U_LARB11_ID, 1)
+#define M4U_PORT_CAM_IPU3O MTK_M4U_ID(M4U_LARB11_ID, 2)
+#define M4U_PORT_CAM_IPUI MTK_M4U_ID(M4U_LARB11_ID, 3)
+#define M4U_PORT_CAM_IPU2I MTK_M4U_ID(M4U_LARB11_ID, 4)
+
+#endif
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 01/10] dt-bindings: mediatek: Add bindings for MT6779
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
This patch adds description for MT6779 IOMMU.
MT6779 has two iommus, they are mm_iommu and apu_iommu which
both use ARM Short-Descriptor translation format.
In addition, mm_iommu and apu_iommu are two independent HW instance
, we need to set them separately.
The MT6779 IOMMU hardware diagram is as below, it is only a brief
diagram about iommu, it don't focus on the part of smi_larb, so
I don't describe the smi_larb detailedly.
EMI
|
--------------------------------------
| |
MM_IOMMU APU_IOMMU
| |
SMI_COMMOM----------- APU_BUS
| | |
SMI_LARB(0~11) | |
| | |
| | --------------
| | | | |
Multimedia engine CCU VPU MDLA EMDA
All the connections are hardware fixed, software can not adjust it.
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Rob Herring <robh+dt@kernel.org>
---
.../bindings/iommu/mediatek,iommu.txt | 2 +
include/dt-bindings/memory/mt6779-larb-port.h | 206 ++++++++++++++++++
2 files changed, 208 insertions(+)
create mode 100644 include/dt-bindings/memory/mt6779-larb-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
index ce59a505f5a4..c1ccd8582eb2 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -58,6 +58,7 @@ 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,mt8173-m4u" for mt8173 which uses generation two m4u HW.
@@ -78,6 +79,7 @@ Required properties:
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/mt8173-larb-port.h for mt8173, and
dt-binding/memory/mt8183-larb-port.h for mt8183.
diff --git a/include/dt-bindings/memory/mt6779-larb-port.h b/include/dt-bindings/memory/mt6779-larb-port.h
new file mode 100644
index 000000000000..2ad0899fbf2f
--- /dev/null
+++ b/include/dt-bindings/memory/mt6779-larb-port.h
@@ -0,0 +1,206 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Chao Hao <chao.hao@mediatek.com>
+ */
+
+#ifndef _DTS_IOMMU_PORT_MT6779_H_
+#define _DTS_IOMMU_PORT_MT6779_H_
+
+#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+
+#define M4U_LARB0_ID 0
+#define M4U_LARB1_ID 1
+#define M4U_LARB2_ID 2
+#define M4U_LARB3_ID 3
+#define M4U_LARB4_ID 4
+#define M4U_LARB5_ID 5
+#define M4U_LARB6_ID 6
+#define M4U_LARB7_ID 7
+#define M4U_LARB8_ID 8
+#define M4U_LARB9_ID 9
+#define M4U_LARB10_ID 10
+#define M4U_LARB11_ID 11
+
+/* larb0 */
+#define M4U_PORT_DISP_POSTMASK0 MTK_M4U_ID(M4U_LARB0_ID, 0)
+#define M4U_PORT_DISP_OVL0_HDR MTK_M4U_ID(M4U_LARB0_ID, 1)
+#define M4U_PORT_DISP_OVL1_HDR MTK_M4U_ID(M4U_LARB0_ID, 2)
+#define M4U_PORT_DISP_OVL0 MTK_M4U_ID(M4U_LARB0_ID, 3)
+#define M4U_PORT_DISP_OVL1 MTK_M4U_ID(M4U_LARB0_ID, 4)
+#define M4U_PORT_DISP_PVRIC0 MTK_M4U_ID(M4U_LARB0_ID, 5)
+#define M4U_PORT_DISP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 6)
+#define M4U_PORT_DISP_WDMA0 MTK_M4U_ID(M4U_LARB0_ID, 7)
+#define M4U_PORT_DISP_FAKE0 MTK_M4U_ID(M4U_LARB0_ID, 8)
+
+/* larb1 */
+#define M4U_PORT_DISP_OVL0_2L_HDR MTK_M4U_ID(M4U_LARB1_ID, 0)
+#define M4U_PORT_DISP_OVL1_2L_HDR MTK_M4U_ID(M4U_LARB1_ID, 1)
+#define M4U_PORT_DISP_OVL0_2L MTK_M4U_ID(M4U_LARB1_ID, 2)
+#define M4U_PORT_DISP_OVL1_2L MTK_M4U_ID(M4U_LARB1_ID, 3)
+#define M4U_PORT_DISP_RDMA1 MTK_M4U_ID(M4U_LARB1_ID, 4)
+#define M4U_PORT_MDP_PVRIC0 MTK_M4U_ID(M4U_LARB1_ID, 5)
+#define M4U_PORT_MDP_PVRIC1 MTK_M4U_ID(M4U_LARB1_ID, 6)
+#define M4U_PORT_MDP_RDMA0 MTK_M4U_ID(M4U_LARB1_ID, 7)
+#define M4U_PORT_MDP_RDMA1 MTK_M4U_ID(M4U_LARB1_ID, 8)
+#define M4U_PORT_MDP_WROT0_R MTK_M4U_ID(M4U_LARB1_ID, 9)
+#define M4U_PORT_MDP_WROT0_W MTK_M4U_ID(M4U_LARB1_ID, 10)
+#define M4U_PORT_MDP_WROT1_R MTK_M4U_ID(M4U_LARB1_ID, 11)
+#define M4U_PORT_MDP_WROT1_W MTK_M4U_ID(M4U_LARB1_ID, 12)
+#define M4U_PORT_DISP_FAKE1 MTK_M4U_ID(M4U_LARB1_ID, 13)
+
+/* larb2-VDEC */
+#define M4U_PORT_HW_VDEC_MC_EXT MTK_M4U_ID(M4U_LARB2_ID, 0)
+#define M4U_PORT_HW_VDEC_UFO_EXT MTK_M4U_ID(M4U_LARB2_ID, 1)
+#define M4U_PORT_HW_VDEC_PP_EXT MTK_M4U_ID(M4U_LARB2_ID, 2)
+#define M4U_PORT_HW_VDEC_PRED_RD_EXT MTK_M4U_ID(M4U_LARB2_ID, 3)
+#define M4U_PORT_HW_VDEC_PRED_WR_EXT MTK_M4U_ID(M4U_LARB2_ID, 4)
+#define M4U_PORT_HW_VDEC_PPWRAP_EXT MTK_M4U_ID(M4U_LARB2_ID, 5)
+#define M4U_PORT_HW_VDEC_TILE_EXT MTK_M4U_ID(M4U_LARB2_ID, 6)
+#define M4U_PORT_HW_VDEC_VLD_EXT MTK_M4U_ID(M4U_LARB2_ID, 7)
+#define M4U_PORT_HW_VDEC_VLD2_EXT MTK_M4U_ID(M4U_LARB2_ID, 8)
+#define M4U_PORT_HW_VDEC_AVC_MV_EXT MTK_M4U_ID(M4U_LARB2_ID, 9)
+#define M4U_PORT_HW_VDEC_UFO_ENC_EXT MTK_M4U_ID(M4U_LARB2_ID, 10)
+#define M4U_PORT_HW_VDEC_RG_CTRL_DMA_EXT MTK_M4U_ID(M4U_LARB2_ID, 11)
+
+/* larb3-VENC */
+#define M4U_PORT_VENC_RCPU MTK_M4U_ID(M4U_LARB3_ID, 0)
+#define M4U_PORT_VENC_REC MTK_M4U_ID(M4U_LARB3_ID, 1)
+#define M4U_PORT_VENC_BSDMA MTK_M4U_ID(M4U_LARB3_ID, 2)
+#define M4U_PORT_VENC_SV_COMV MTK_M4U_ID(M4U_LARB3_ID, 3)
+#define M4U_PORT_VENC_RD_COMV MTK_M4U_ID(M4U_LARB3_ID, 4)
+#define M4U_PORT_VENC_NBM_RDMA MTK_M4U_ID(M4U_LARB3_ID, 5)
+#define M4U_PORT_VENC_NBM_RDMA_LITE MTK_M4U_ID(M4U_LARB3_ID, 6)
+#define M4U_PORT_JPGENC_Y_RDMA MTK_M4U_ID(M4U_LARB3_ID, 7)
+#define M4U_PORT_JPGENC_C_RDMA MTK_M4U_ID(M4U_LARB3_ID, 8)
+#define M4U_PORT_JPGENC_Q_TABLE MTK_M4U_ID(M4U_LARB3_ID, 9)
+#define M4U_PORT_JPGENC_BSDMA MTK_M4U_ID(M4U_LARB3_ID, 10)
+#define M4U_PORT_JPGDEC_WDMA MTK_M4U_ID(M4U_LARB3_ID, 11)
+#define M4U_PORT_JPGDEC_BSDMA MTK_M4U_ID(M4U_LARB3_ID, 12)
+#define M4U_PORT_VENC_NBM_WDMA MTK_M4U_ID(M4U_LARB3_ID, 13)
+#define M4U_PORT_VENC_NBM_WDMA_LITE MTK_M4U_ID(M4U_LARB3_ID, 14)
+#define M4U_PORT_VENC_CUR_LUMA MTK_M4U_ID(M4U_LARB3_ID, 15)
+#define M4U_PORT_VENC_CUR_CHROMA MTK_M4U_ID(M4U_LARB3_ID, 16)
+#define M4U_PORT_VENC_REF_LUMA MTK_M4U_ID(M4U_LARB3_ID, 17)
+#define M4U_PORT_VENC_REF_CHROMA MTK_M4U_ID(M4U_LARB3_ID, 18)
+
+/* larb4-dummy */
+
+/* larb5-IMG */
+#define M4U_PORT_IMGI_D1 MTK_M4U_ID(M4U_LARB5_ID, 0)
+#define M4U_PORT_IMGBI_D1 MTK_M4U_ID(M4U_LARB5_ID, 1)
+#define M4U_PORT_DMGI_D1 MTK_M4U_ID(M4U_LARB5_ID, 2)
+#define M4U_PORT_DEPI_D1 MTK_M4U_ID(M4U_LARB5_ID, 3)
+#define M4U_PORT_LCEI_D1 MTK_M4U_ID(M4U_LARB5_ID, 4)
+#define M4U_PORT_SMTI_D1 MTK_M4U_ID(M4U_LARB5_ID, 5)
+#define M4U_PORT_SMTO_D2 MTK_M4U_ID(M4U_LARB5_ID, 6)
+#define M4U_PORT_SMTO_D1 MTK_M4U_ID(M4U_LARB5_ID, 7)
+#define M4U_PORT_CRZO_D1 MTK_M4U_ID(M4U_LARB5_ID, 8)
+#define M4U_PORT_IMG3O_D1 MTK_M4U_ID(M4U_LARB5_ID, 9)
+#define M4U_PORT_VIPI_D1 MTK_M4U_ID(M4U_LARB5_ID, 10)
+#define M4U_PORT_WPE_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 11)
+#define M4U_PORT_WPE_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 12)
+#define M4U_PORT_WPE_WDMA MTK_M4U_ID(M4U_LARB5_ID, 13)
+#define M4U_PORT_TIMGO_D1 MTK_M4U_ID(M4U_LARB5_ID, 14)
+#define M4U_PORT_MFB_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 15)
+#define M4U_PORT_MFB_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 16)
+#define M4U_PORT_MFB_RDMA2 MTK_M4U_ID(M4U_LARB5_ID, 17)
+#define M4U_PORT_MFB_RDMA3 MTK_M4U_ID(M4U_LARB5_ID, 18)
+#define M4U_PORT_MFB_WDMA MTK_M4U_ID(M4U_LARB5_ID, 19)
+#define M4U_PORT_RESERVE1 MTK_M4U_ID(M4U_LARB5_ID, 20)
+#define M4U_PORT_RESERVE2 MTK_M4U_ID(M4U_LARB5_ID, 21)
+#define M4U_PORT_RESERVE3 MTK_M4U_ID(M4U_LARB5_ID, 22)
+#define M4U_PORT_RESERVE4 MTK_M4U_ID(M4U_LARB5_ID, 23)
+#define M4U_PORT_RESERVE5 MTK_M4U_ID(M4U_LARB5_ID, 24)
+#define M4U_PORT_RESERVE6 MTK_M4U_ID(M4U_LARB5_ID, 25)
+
+/* larb6-IMG-VPU */
+#define M4U_PORT_IMG_IPUO MTK_M4U_ID(M4U_LARB6_ID, 0)
+#define M4U_PORT_IMG_IPU3O MTK_M4U_ID(M4U_LARB6_ID, 1)
+#define M4U_PORT_IMG_IPUI MTK_M4U_ID(M4U_LARB6_ID, 2)
+
+/* larb7-DVS */
+#define M4U_PORT_DVS_RDMA MTK_M4U_ID(M4U_LARB7_ID, 0)
+#define M4U_PORT_DVS_WDMA MTK_M4U_ID(M4U_LARB7_ID, 1)
+#define M4U_PORT_DVP_RDMA MTK_M4U_ID(M4U_LARB7_ID, 2)
+#define M4U_PORT_DVP_WDMA MTK_M4U_ID(M4U_LARB7_ID, 3)
+
+/* larb8-IPESYS */
+#define M4U_PORT_FDVT_RDA MTK_M4U_ID(M4U_LARB8_ID, 0)
+#define M4U_PORT_FDVT_RDB MTK_M4U_ID(M4U_LARB8_ID, 1)
+#define M4U_PORT_FDVT_WRA MTK_M4U_ID(M4U_LARB8_ID, 2)
+#define M4U_PORT_FDVT_WRB MTK_M4U_ID(M4U_LARB8_ID, 3)
+#define M4U_PORT_FE_RD0 MTK_M4U_ID(M4U_LARB8_ID, 4)
+#define M4U_PORT_FE_RD1 MTK_M4U_ID(M4U_LARB8_ID, 5)
+#define M4U_PORT_FE_WR0 MTK_M4U_ID(M4U_LARB8_ID, 6)
+#define M4U_PORT_FE_WR1 MTK_M4U_ID(M4U_LARB8_ID, 7)
+#define M4U_PORT_RSC_RDMA0 MTK_M4U_ID(M4U_LARB8_ID, 8)
+#define M4U_PORT_RSC_WDMA MTK_M4U_ID(M4U_LARB8_ID, 9)
+
+/* larb9-CAM */
+#define M4U_PORT_CAM_IMGO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 0)
+#define M4U_PORT_CAM_RRZO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 1)
+#define M4U_PORT_CAM_LSCI_R1_C MTK_M4U_ID(M4U_LARB9_ID, 2)
+#define M4U_PORT_CAM_BPCI_R1_C MTK_M4U_ID(M4U_LARB9_ID, 3)
+#define M4U_PORT_CAM_YUVO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 4)
+#define M4U_PORT_CAM_UFDI_R2_C MTK_M4U_ID(M4U_LARB9_ID, 5)
+#define M4U_PORT_CAM_RAWI_R2_C MTK_M4U_ID(M4U_LARB9_ID, 6)
+#define M4U_PORT_CAM_RAWI_R5_C MTK_M4U_ID(M4U_LARB9_ID, 7)
+#define M4U_PORT_CAM_CAMSV_1 MTK_M4U_ID(M4U_LARB9_ID, 8)
+#define M4U_PORT_CAM_CAMSV_2 MTK_M4U_ID(M4U_LARB9_ID, 9)
+#define M4U_PORT_CAM_CAMSV_3 MTK_M4U_ID(M4U_LARB9_ID, 10)
+#define M4U_PORT_CAM_CAMSV_4 MTK_M4U_ID(M4U_LARB9_ID, 11)
+#define M4U_PORT_CAM_CAMSV_5 MTK_M4U_ID(M4U_LARB9_ID, 12)
+#define M4U_PORT_CAM_CAMSV_6 MTK_M4U_ID(M4U_LARB9_ID, 13)
+#define M4U_PORT_CAM_AAO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 14)
+#define M4U_PORT_CAM_AFO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 15)
+#define M4U_PORT_CAM_FLKO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 16)
+#define M4U_PORT_CAM_LCESO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 17)
+#define M4U_PORT_CAM_CRZO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 18)
+#define M4U_PORT_CAM_LTMSO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 19)
+#define M4U_PORT_CAM_RSSO_R1_C MTK_M4U_ID(M4U_LARB9_ID, 20)
+#define M4U_PORT_CAM_CCUI MTK_M4U_ID(M4U_LARB9_ID, 21)
+#define M4U_PORT_CAM_CCUO MTK_M4U_ID(M4U_LARB9_ID, 22)
+#define M4U_PORT_CAM_FAKE MTK_M4U_ID(M4U_LARB9_ID, 23)
+
+/* larb10-CAM_A */
+#define M4U_PORT_CAM_IMGO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 0)
+#define M4U_PORT_CAM_RRZO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 1)
+#define M4U_PORT_CAM_LSCI_R1_A MTK_M4U_ID(M4U_LARB10_ID, 2)
+#define M4U_PORT_CAM_BPCI_R1_A MTK_M4U_ID(M4U_LARB10_ID, 3)
+#define M4U_PORT_CAM_YUVO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 4)
+#define M4U_PORT_CAM_UFDI_R2_A MTK_M4U_ID(M4U_LARB10_ID, 5)
+#define M4U_PORT_CAM_RAWI_R2_A MTK_M4U_ID(M4U_LARB10_ID, 6)
+#define M4U_PORT_CAM_RAWI_R5_A MTK_M4U_ID(M4U_LARB10_ID, 7)
+#define M4U_PORT_CAM_IMGO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 8)
+#define M4U_PORT_CAM_RRZO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 9)
+#define M4U_PORT_CAM_LSCI_R1_B MTK_M4U_ID(M4U_LARB10_ID, 10)
+#define M4U_PORT_CAM_BPCI_R1_B MTK_M4U_ID(M4U_LARB10_ID, 11)
+#define M4U_PORT_CAM_YUVO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 12)
+#define M4U_PORT_CAM_UFDI_R2_B MTK_M4U_ID(M4U_LARB10_ID, 13)
+#define M4U_PORT_CAM_RAWI_R2_B MTK_M4U_ID(M4U_LARB10_ID, 14)
+#define M4U_PORT_CAM_RAWI_R5_B MTK_M4U_ID(M4U_LARB10_ID, 15)
+#define M4U_PORT_CAM_CAMSV_0 MTK_M4U_ID(M4U_LARB10_ID, 16)
+#define M4U_PORT_CAM_AAO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 17)
+#define M4U_PORT_CAM_AFO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 18)
+#define M4U_PORT_CAM_FLKO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 19)
+#define M4U_PORT_CAM_LCESO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 20)
+#define M4U_PORT_CAM_CRZO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 21)
+#define M4U_PORT_CAM_AAO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 22)
+#define M4U_PORT_CAM_AFO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 23)
+#define M4U_PORT_CAM_FLKO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 24)
+#define M4U_PORT_CAM_LCESO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 25)
+#define M4U_PORT_CAM_CRZO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 26)
+#define M4U_PORT_CAM_LTMSO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 27)
+#define M4U_PORT_CAM_RSSO_R1_A MTK_M4U_ID(M4U_LARB10_ID, 28)
+#define M4U_PORT_CAM_LTMSO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 29)
+#define M4U_PORT_CAM_RSSO_R1_B MTK_M4U_ID(M4U_LARB10_ID, 30)
+
+/* larb11-CAM-VPU */
+#define M4U_PORT_CAM_IPUO MTK_M4U_ID(M4U_LARB11_ID, 0)
+#define M4U_PORT_CAM_IPU2O MTK_M4U_ID(M4U_LARB11_ID, 1)
+#define M4U_PORT_CAM_IPU3O MTK_M4U_ID(M4U_LARB11_ID, 2)
+#define M4U_PORT_CAM_IPUI MTK_M4U_ID(M4U_LARB11_ID, 3)
+#define M4U_PORT_CAM_IPU2I MTK_M4U_ID(M4U_LARB11_ID, 4)
+
+#endif
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 02/10] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
2020-06-29 7:13 ` Chao Hao
(?)
@ 2020-06-29 7:13 ` Chao Hao
-1 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
name STANDARD_AXI_MODE, all the latest SoC extend the register more
feature by different bits, for example: axi_mode, in_order_en, coherent_en
and so on. So rename REG_MMU_MISC_CTRL may be more proper.
This patch only rename the register name, no functional change.
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 14 +++++++-------
drivers/iommu/mtk_iommu.h | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 2be96f1cdbd2..88d3df5b91c2 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -41,7 +41,7 @@
#define F_INVLD_EN0 BIT(0)
#define F_INVLD_EN1 BIT(1)
-#define REG_MMU_STANDARD_AXI_MODE 0x048
+#define REG_MMU_MISC_CTRL 0x048
#define REG_MMU_DCM_DIS 0x050
#define REG_MMU_CTRL_REG 0x110
@@ -573,8 +573,10 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
- if (data->plat_data->reset_axi)
- writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
+ if (data->plat_data->reset_axi) {
+ /* The register is called STANDARD_AXI_MODE in this case */
+ writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
+ }
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
dev_name(data->dev), (void *)data)) {
@@ -718,8 +720,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
struct mtk_iommu_suspend_reg *reg = &data->reg;
void __iomem *base = data->base;
- reg->standard_axi_mode = readl_relaxed(base +
- REG_MMU_STANDARD_AXI_MODE);
+ reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
@@ -743,8 +744,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
return ret;
}
- writel_relaxed(reg->standard_axi_mode,
- base + REG_MMU_STANDARD_AXI_MODE);
+ writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index ea949a324e33..1b6ea839b92c 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -18,7 +18,7 @@
#include <soc/mediatek/smi.h>
struct mtk_iommu_suspend_reg {
- u32 standard_axi_mode;
+ u32 misc_ctrl;
u32 dcm_dis;
u32 ctrl_reg;
u32 int_control0;
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 02/10] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
name STANDARD_AXI_MODE, all the latest SoC extend the register more
feature by different bits, for example: axi_mode, in_order_en, coherent_en
and so on. So rename REG_MMU_MISC_CTRL may be more proper.
This patch only rename the register name, no functional change.
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 14 +++++++-------
drivers/iommu/mtk_iommu.h | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 2be96f1cdbd2..88d3df5b91c2 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -41,7 +41,7 @@
#define F_INVLD_EN0 BIT(0)
#define F_INVLD_EN1 BIT(1)
-#define REG_MMU_STANDARD_AXI_MODE 0x048
+#define REG_MMU_MISC_CTRL 0x048
#define REG_MMU_DCM_DIS 0x050
#define REG_MMU_CTRL_REG 0x110
@@ -573,8 +573,10 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
- if (data->plat_data->reset_axi)
- writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
+ if (data->plat_data->reset_axi) {
+ /* The register is called STANDARD_AXI_MODE in this case */
+ writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
+ }
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
dev_name(data->dev), (void *)data)) {
@@ -718,8 +720,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
struct mtk_iommu_suspend_reg *reg = &data->reg;
void __iomem *base = data->base;
- reg->standard_axi_mode = readl_relaxed(base +
- REG_MMU_STANDARD_AXI_MODE);
+ reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
@@ -743,8 +744,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
return ret;
}
- writel_relaxed(reg->standard_axi_mode,
- base + REG_MMU_STANDARD_AXI_MODE);
+ writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index ea949a324e33..1b6ea839b92c 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -18,7 +18,7 @@
#include <soc/mediatek/smi.h>
struct mtk_iommu_suspend_reg {
- u32 standard_axi_mode;
+ u32 misc_ctrl;
u32 dcm_dis;
u32 ctrl_reg;
u32 int_control0;
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 02/10] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
name STANDARD_AXI_MODE, all the latest SoC extend the register more
feature by different bits, for example: axi_mode, in_order_en, coherent_en
and so on. So rename REG_MMU_MISC_CTRL may be more proper.
This patch only rename the register name, no functional change.
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 14 +++++++-------
drivers/iommu/mtk_iommu.h | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 2be96f1cdbd2..88d3df5b91c2 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -41,7 +41,7 @@
#define F_INVLD_EN0 BIT(0)
#define F_INVLD_EN1 BIT(1)
-#define REG_MMU_STANDARD_AXI_MODE 0x048
+#define REG_MMU_MISC_CTRL 0x048
#define REG_MMU_DCM_DIS 0x050
#define REG_MMU_CTRL_REG 0x110
@@ -573,8 +573,10 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
- if (data->plat_data->reset_axi)
- writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
+ if (data->plat_data->reset_axi) {
+ /* The register is called STANDARD_AXI_MODE in this case */
+ writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
+ }
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
dev_name(data->dev), (void *)data)) {
@@ -718,8 +720,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
struct mtk_iommu_suspend_reg *reg = &data->reg;
void __iomem *base = data->base;
- reg->standard_axi_mode = readl_relaxed(base +
- REG_MMU_STANDARD_AXI_MODE);
+ reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
@@ -743,8 +744,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
return ret;
}
- writel_relaxed(reg->standard_axi_mode,
- base + REG_MMU_STANDARD_AXI_MODE);
+ writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index ea949a324e33..1b6ea839b92c 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -18,7 +18,7 @@
#include <soc/mediatek/smi.h>
struct mtk_iommu_suspend_reg {
- u32 standard_axi_mode;
+ u32 misc_ctrl;
u32 dcm_dis;
u32 ctrl_reg;
u32 int_control0;
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
2020-06-29 7:13 ` Chao Hao
(?)
@ 2020-06-29 7:13 ` Chao Hao
-1 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
Given the fact that we are adding more and more plat_data bool values,
it would make sense to use a u32 flags register and add the appropriate
macro definitions to set and check for a flag present.
No functional change.
Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 23 ++++++++++++-----------
drivers/iommu/mtk_iommu.h | 16 ++++++++++------
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 88d3df5b91c2..8f81df6cbe51 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -563,7 +563,8 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
upper_32_bits(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
- if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
+ if (data->enable_4GB &&
+ MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_VLD_PA_RNG)) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
@@ -573,7 +574,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
- if (data->plat_data->reset_axi) {
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
/* The register is called STANDARD_AXI_MODE in this case */
writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
}
@@ -618,7 +619,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
/* Whether the current dram is over 4GB */
data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
- if (!data->plat_data->has_4gb_mode)
+ if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
data->enable_4GB = false;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -631,7 +632,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (data->irq < 0)
return data->irq;
- if (data->plat_data->has_bclk) {
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_BCLK)) {
data->bclk = devm_clk_get(dev, "bclk");
if (IS_ERR(data->bclk))
return PTR_ERR(data->bclk);
@@ -763,23 +764,23 @@ static const struct dev_pm_ops mtk_iommu_pm_ops = {
static const struct mtk_iommu_plat_data mt2712_data = {
.m4u_plat = M4U_MT2712,
- .has_4gb_mode = true,
- .has_bclk = true,
- .has_vld_pa_rng = true,
+ .flags = HAS_4GB_MODE |
+ HAS_BCLK |
+ HAS_VLD_PA_RNG,
.larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
- .has_4gb_mode = true,
- .has_bclk = true,
- .reset_axi = true,
+ .flags = HAS_4GB_MODE |
+ HAS_BCLK |
+ RESET_AXI,
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
- .reset_axi = true,
+ .flags = RESET_AXI,
.larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 1b6ea839b92c..7cc39f729263 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -17,6 +17,15 @@
#include <linux/spinlock.h>
#include <soc/mediatek/smi.h>
+#define HAS_4GB_MODE BIT(0)
+/* HW will use the EMI clock if there isn't the "bclk". */
+#define HAS_BCLK BIT(1)
+#define HAS_VLD_PA_RNG BIT(2)
+#define RESET_AXI BIT(3)
+
+#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
+ ((((pdata)->flags) & (_x)) == (_x))
+
struct mtk_iommu_suspend_reg {
u32 misc_ctrl;
u32 dcm_dis;
@@ -36,12 +45,7 @@ enum mtk_iommu_plat {
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
- bool has_4gb_mode;
-
- /* HW will use the EMI clock if there isn't the "bclk". */
- bool has_bclk;
- bool has_vld_pa_rng;
- bool reset_axi;
+ u32 flags;
unsigned char larbid_remap[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] 101+ messages in thread
* [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
Given the fact that we are adding more and more plat_data bool values,
it would make sense to use a u32 flags register and add the appropriate
macro definitions to set and check for a flag present.
No functional change.
Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 23 ++++++++++++-----------
drivers/iommu/mtk_iommu.h | 16 ++++++++++------
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 88d3df5b91c2..8f81df6cbe51 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -563,7 +563,8 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
upper_32_bits(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
- if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
+ if (data->enable_4GB &&
+ MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_VLD_PA_RNG)) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
@@ -573,7 +574,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
- if (data->plat_data->reset_axi) {
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
/* The register is called STANDARD_AXI_MODE in this case */
writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
}
@@ -618,7 +619,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
/* Whether the current dram is over 4GB */
data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
- if (!data->plat_data->has_4gb_mode)
+ if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
data->enable_4GB = false;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -631,7 +632,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (data->irq < 0)
return data->irq;
- if (data->plat_data->has_bclk) {
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_BCLK)) {
data->bclk = devm_clk_get(dev, "bclk");
if (IS_ERR(data->bclk))
return PTR_ERR(data->bclk);
@@ -763,23 +764,23 @@ static const struct dev_pm_ops mtk_iommu_pm_ops = {
static const struct mtk_iommu_plat_data mt2712_data = {
.m4u_plat = M4U_MT2712,
- .has_4gb_mode = true,
- .has_bclk = true,
- .has_vld_pa_rng = true,
+ .flags = HAS_4GB_MODE |
+ HAS_BCLK |
+ HAS_VLD_PA_RNG,
.larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
- .has_4gb_mode = true,
- .has_bclk = true,
- .reset_axi = true,
+ .flags = HAS_4GB_MODE |
+ HAS_BCLK |
+ RESET_AXI,
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
- .reset_axi = true,
+ .flags = RESET_AXI,
.larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 1b6ea839b92c..7cc39f729263 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -17,6 +17,15 @@
#include <linux/spinlock.h>
#include <soc/mediatek/smi.h>
+#define HAS_4GB_MODE BIT(0)
+/* HW will use the EMI clock if there isn't the "bclk". */
+#define HAS_BCLK BIT(1)
+#define HAS_VLD_PA_RNG BIT(2)
+#define RESET_AXI BIT(3)
+
+#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
+ ((((pdata)->flags) & (_x)) == (_x))
+
struct mtk_iommu_suspend_reg {
u32 misc_ctrl;
u32 dcm_dis;
@@ -36,12 +45,7 @@ enum mtk_iommu_plat {
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
- bool has_4gb_mode;
-
- /* HW will use the EMI clock if there isn't the "bclk". */
- bool has_bclk;
- bool has_vld_pa_rng;
- bool reset_axi;
+ u32 flags;
unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
Given the fact that we are adding more and more plat_data bool values,
it would make sense to use a u32 flags register and add the appropriate
macro definitions to set and check for a flag present.
No functional change.
Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 23 ++++++++++++-----------
drivers/iommu/mtk_iommu.h | 16 ++++++++++------
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 88d3df5b91c2..8f81df6cbe51 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -563,7 +563,8 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
upper_32_bits(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
- if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
+ if (data->enable_4GB &&
+ MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_VLD_PA_RNG)) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
@@ -573,7 +574,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
- if (data->plat_data->reset_axi) {
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
/* The register is called STANDARD_AXI_MODE in this case */
writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
}
@@ -618,7 +619,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
/* Whether the current dram is over 4GB */
data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
- if (!data->plat_data->has_4gb_mode)
+ if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
data->enable_4GB = false;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -631,7 +632,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (data->irq < 0)
return data->irq;
- if (data->plat_data->has_bclk) {
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_BCLK)) {
data->bclk = devm_clk_get(dev, "bclk");
if (IS_ERR(data->bclk))
return PTR_ERR(data->bclk);
@@ -763,23 +764,23 @@ static const struct dev_pm_ops mtk_iommu_pm_ops = {
static const struct mtk_iommu_plat_data mt2712_data = {
.m4u_plat = M4U_MT2712,
- .has_4gb_mode = true,
- .has_bclk = true,
- .has_vld_pa_rng = true,
+ .flags = HAS_4GB_MODE |
+ HAS_BCLK |
+ HAS_VLD_PA_RNG,
.larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
- .has_4gb_mode = true,
- .has_bclk = true,
- .reset_axi = true,
+ .flags = HAS_4GB_MODE |
+ HAS_BCLK |
+ RESET_AXI,
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
- .reset_axi = true,
+ .flags = RESET_AXI,
.larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 1b6ea839b92c..7cc39f729263 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -17,6 +17,15 @@
#include <linux/spinlock.h>
#include <soc/mediatek/smi.h>
+#define HAS_4GB_MODE BIT(0)
+/* HW will use the EMI clock if there isn't the "bclk". */
+#define HAS_BCLK BIT(1)
+#define HAS_VLD_PA_RNG BIT(2)
+#define RESET_AXI BIT(3)
+
+#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
+ ((((pdata)->flags) & (_x)) == (_x))
+
struct mtk_iommu_suspend_reg {
u32 misc_ctrl;
u32 dcm_dis;
@@ -36,12 +45,7 @@ enum mtk_iommu_plat {
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
- bool has_4gb_mode;
-
- /* HW will use the EMI clock if there isn't the "bclk". */
- bool has_bclk;
- bool has_vld_pa_rng;
- bool reset_axi;
+ u32 flags;
unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
2020-06-29 7:13 ` Chao Hao
(?)
@ 2020-06-29 7:13 ` Chao Hao
-1 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
in MISC_CTRL register.
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
standard AXI protocol), iommu will send urgent read command firstly
compare with normal read command to improve performance.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
will re-order write command and send more higher priority write command
instead of sending write command in order. The feature be controlled
by OUT_ORDER_EN macro definition.
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Suggested-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 12 +++++++++++-
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 8f81df6cbe51..67b46b5d83d9 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -42,6 +42,9 @@
#define F_INVLD_EN1 BIT(1)
#define REG_MMU_MISC_CTRL 0x048
+#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
+#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
+
#define REG_MMU_DCM_DIS 0x050
#define REG_MMU_CTRL_REG 0x110
@@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
+ regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
/* The register is called STANDARD_AXI_MODE in this case */
- writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
+ regval = 0;
+ } else {
+ /* For mm_iommu, it can improve performance by the setting */
+ regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
+ regval &= ~F_MMU_IN_ORDER_WR_EN;
}
+ writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
dev_name(data->dev), (void *)data)) {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 7cc39f729263..4b780b651ef4 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -22,6 +22,7 @@
#define HAS_BCLK BIT(1)
#define HAS_VLD_PA_RNG BIT(2)
#define RESET_AXI BIT(3)
+#define OUT_ORDER_EN BIT(4)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
((((pdata)->flags) & (_x)) == (_x))
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
in MISC_CTRL register.
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
standard AXI protocol), iommu will send urgent read command firstly
compare with normal read command to improve performance.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
will re-order write command and send more higher priority write command
instead of sending write command in order. The feature be controlled
by OUT_ORDER_EN macro definition.
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Suggested-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 12 +++++++++++-
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 8f81df6cbe51..67b46b5d83d9 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -42,6 +42,9 @@
#define F_INVLD_EN1 BIT(1)
#define REG_MMU_MISC_CTRL 0x048
+#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
+#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
+
#define REG_MMU_DCM_DIS 0x050
#define REG_MMU_CTRL_REG 0x110
@@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
+ regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
/* The register is called STANDARD_AXI_MODE in this case */
- writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
+ regval = 0;
+ } else {
+ /* For mm_iommu, it can improve performance by the setting */
+ regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
+ regval &= ~F_MMU_IN_ORDER_WR_EN;
}
+ writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
dev_name(data->dev), (void *)data)) {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 7cc39f729263..4b780b651ef4 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -22,6 +22,7 @@
#define HAS_BCLK BIT(1)
#define HAS_VLD_PA_RNG BIT(2)
#define RESET_AXI BIT(3)
+#define OUT_ORDER_EN BIT(4)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
((((pdata)->flags) & (_x)) == (_x))
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
in MISC_CTRL register.
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
standard AXI protocol), iommu will send urgent read command firstly
compare with normal read command to improve performance.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
will re-order write command and send more higher priority write command
instead of sending write command in order. The feature be controlled
by OUT_ORDER_EN macro definition.
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Suggested-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 12 +++++++++++-
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 8f81df6cbe51..67b46b5d83d9 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -42,6 +42,9 @@
#define F_INVLD_EN1 BIT(1)
#define REG_MMU_MISC_CTRL 0x048
+#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
+#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
+
#define REG_MMU_DCM_DIS 0x050
#define REG_MMU_CTRL_REG 0x110
@@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
+ regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
/* The register is called STANDARD_AXI_MODE in this case */
- writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
+ regval = 0;
+ } else {
+ /* For mm_iommu, it can improve performance by the setting */
+ regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
+ regval &= ~F_MMU_IN_ORDER_WR_EN;
}
+ writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
dev_name(data->dev), (void *)data)) {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 7cc39f729263..4b780b651ef4 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -22,6 +22,7 @@
#define HAS_BCLK BIT(1)
#define HAS_VLD_PA_RNG BIT(2)
#define RESET_AXI BIT(3)
+#define OUT_ORDER_EN BIT(4)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
((((pdata)->flags) & (_x)) == (_x))
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 05/10] iommu/mediatek: Move inv_sel_reg into the plat_data
2020-06-29 7:13 ` Chao Hao
(?)
@ 2020-06-29 7:13 ` Chao Hao
-1 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
For mt6779, MMU_INV_SEL register's offset is changed from
0x38 to 0x2c, so we can put inv_sel_reg in the plat_data to
use it.
In addition, we renamed it to REG_MMU_INV_SEL_GEN1 and use it
before mt6779.
Cc: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 9 ++++++---
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 67b46b5d83d9..116418cc1cf8 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -37,7 +37,7 @@
#define REG_MMU_INVLD_START_A 0x024
#define REG_MMU_INVLD_END_A 0x028
-#define REG_MMU_INV_SEL 0x038
+#define REG_MMU_INV_SEL_GEN1 0x038
#define F_INVLD_EN0 BIT(0)
#define F_INVLD_EN1 BIT(1)
@@ -168,7 +168,7 @@ static void mtk_iommu_tlb_flush_all(void *cookie)
for_each_m4u(data) {
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
- data->base + REG_MMU_INV_SEL);
+ data->base + data->plat_data->inv_sel_reg);
writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
wmb(); /* Make sure the tlb flush all done */
}
@@ -185,7 +185,7 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long iova, size_t size,
for_each_m4u(data) {
spin_lock_irqsave(&data->tlb_lock, flags);
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
- data->base + REG_MMU_INV_SEL);
+ data->base + data->plat_data->inv_sel_reg);
writel_relaxed(iova, data->base + REG_MMU_INVLD_START_A);
writel_relaxed(iova + size - 1,
@@ -777,6 +777,7 @@ static const struct mtk_iommu_plat_data mt2712_data = {
.flags = HAS_4GB_MODE |
HAS_BCLK |
HAS_VLD_PA_RNG,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
@@ -785,12 +786,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
.flags = HAS_4GB_MODE |
HAS_BCLK |
RESET_AXI,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
.flags = RESET_AXI,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 4b780b651ef4..ae70296af2b4 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -47,6 +47,7 @@ enum mtk_iommu_plat {
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
u32 flags;
+ u32 inv_sel_reg;
unsigned char larbid_remap[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] 101+ messages in thread
* [PATCH v5 05/10] iommu/mediatek: Move inv_sel_reg into the plat_data
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
For mt6779, MMU_INV_SEL register's offset is changed from
0x38 to 0x2c, so we can put inv_sel_reg in the plat_data to
use it.
In addition, we renamed it to REG_MMU_INV_SEL_GEN1 and use it
before mt6779.
Cc: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 9 ++++++---
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 67b46b5d83d9..116418cc1cf8 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -37,7 +37,7 @@
#define REG_MMU_INVLD_START_A 0x024
#define REG_MMU_INVLD_END_A 0x028
-#define REG_MMU_INV_SEL 0x038
+#define REG_MMU_INV_SEL_GEN1 0x038
#define F_INVLD_EN0 BIT(0)
#define F_INVLD_EN1 BIT(1)
@@ -168,7 +168,7 @@ static void mtk_iommu_tlb_flush_all(void *cookie)
for_each_m4u(data) {
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
- data->base + REG_MMU_INV_SEL);
+ data->base + data->plat_data->inv_sel_reg);
writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
wmb(); /* Make sure the tlb flush all done */
}
@@ -185,7 +185,7 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long iova, size_t size,
for_each_m4u(data) {
spin_lock_irqsave(&data->tlb_lock, flags);
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
- data->base + REG_MMU_INV_SEL);
+ data->base + data->plat_data->inv_sel_reg);
writel_relaxed(iova, data->base + REG_MMU_INVLD_START_A);
writel_relaxed(iova + size - 1,
@@ -777,6 +777,7 @@ static const struct mtk_iommu_plat_data mt2712_data = {
.flags = HAS_4GB_MODE |
HAS_BCLK |
HAS_VLD_PA_RNG,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
@@ -785,12 +786,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
.flags = HAS_4GB_MODE |
HAS_BCLK |
RESET_AXI,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
.flags = RESET_AXI,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 4b780b651ef4..ae70296af2b4 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -47,6 +47,7 @@ enum mtk_iommu_plat {
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
u32 flags;
+ u32 inv_sel_reg;
unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 05/10] iommu/mediatek: Move inv_sel_reg into the plat_data
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
For mt6779, MMU_INV_SEL register's offset is changed from
0x38 to 0x2c, so we can put inv_sel_reg in the plat_data to
use it.
In addition, we renamed it to REG_MMU_INV_SEL_GEN1 and use it
before mt6779.
Cc: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 9 ++++++---
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 67b46b5d83d9..116418cc1cf8 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -37,7 +37,7 @@
#define REG_MMU_INVLD_START_A 0x024
#define REG_MMU_INVLD_END_A 0x028
-#define REG_MMU_INV_SEL 0x038
+#define REG_MMU_INV_SEL_GEN1 0x038
#define F_INVLD_EN0 BIT(0)
#define F_INVLD_EN1 BIT(1)
@@ -168,7 +168,7 @@ static void mtk_iommu_tlb_flush_all(void *cookie)
for_each_m4u(data) {
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
- data->base + REG_MMU_INV_SEL);
+ data->base + data->plat_data->inv_sel_reg);
writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
wmb(); /* Make sure the tlb flush all done */
}
@@ -185,7 +185,7 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long iova, size_t size,
for_each_m4u(data) {
spin_lock_irqsave(&data->tlb_lock, flags);
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
- data->base + REG_MMU_INV_SEL);
+ data->base + data->plat_data->inv_sel_reg);
writel_relaxed(iova, data->base + REG_MMU_INVLD_START_A);
writel_relaxed(iova + size - 1,
@@ -777,6 +777,7 @@ static const struct mtk_iommu_plat_data mt2712_data = {
.flags = HAS_4GB_MODE |
HAS_BCLK |
HAS_VLD_PA_RNG,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
@@ -785,12 +786,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
.flags = HAS_4GB_MODE |
HAS_BCLK |
RESET_AXI,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
.flags = RESET_AXI,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 4b780b651ef4..ae70296af2b4 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -47,6 +47,7 @@ enum mtk_iommu_plat {
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
u32 flags;
+ u32 inv_sel_reg;
unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
2020-06-29 7:13 ` Chao Hao
(?)
@ 2020-06-29 7:13 ` Chao Hao
-1 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
The max larb number that a iommu HW support is 8(larb0~larb7 in the below
diagram).
If the larb's number is over 8, we use a sub_common for merging
several larbs into one larb. At this case, we will extend larb_id:
bit[11:9] means common-id;
bit[8:7] means subcommon-id;
From these two variables, we could get the real larb number when
translation fault happen.
The diagram is as below:
EMI
|
IOMMU
|
-----------------
| |
common1 common0
| |
-----------------
|
smi common
|
------------------------------------
| | | | | |
3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
| | | | | |
Larb0 Larb1 | Larb3 ... Larb7
|
smi sub common
|
--------------------------
| | | |
2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
| | | |
Larb8 Larb9 Larb10 Larb11
In this patch we extend larb_remap[] to larb_remap[8][4] for this.
larb_remap[x][y]: x means common-id above, y means subcommon_id above.
We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
macro.
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
drivers/iommu/mtk_iommu.h | 3 ++-
include/soc/mediatek/smi.h | 2 ++
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 116418cc1cf8..ec1f86913739 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -91,6 +91,8 @@
#define REG_MMU1_INVLD_PA 0x148
#define REG_MMU0_INT_ID 0x150
#define REG_MMU1_INT_ID 0x154
+#define F_MMU_INT_ID_COMM_ID(a) (((a) >> 9) & 0x7)
+#define F_MMU_INT_ID_SUB_COMM_ID(a) (((a) >> 7) & 0x3)
#define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
#define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
@@ -229,7 +231,7 @@ 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;
+ unsigned int fault_larb, fault_port, sub_comm = 0;
bool layer, write;
/* Read error info from registers */
@@ -245,10 +247,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;
- fault_larb = F_MMU_INT_ID_LARB_ID(regval);
fault_port = F_MMU_INT_ID_PORT_ID(regval);
-
- fault_larb = data->plat_data->larbid_remap[fault_larb];
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_SUB_COMM)) {
+ fault_larb = F_MMU_INT_ID_COMM_ID(regval);
+ sub_comm = F_MMU_INT_ID_SUB_COMM_ID(regval);
+ } else {
+ fault_larb = F_MMU_INT_ID_LARB_ID(regval);
+ }
+ fault_larb = data->plat_data->larbid_remap[fault_larb][sub_comm];
if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
@@ -778,7 +784,7 @@ static const struct mtk_iommu_plat_data mt2712_data = {
HAS_BCLK |
HAS_VLD_PA_RNG,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
- .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
+ .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
};
static const struct mtk_iommu_plat_data mt8173_data = {
@@ -787,14 +793,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
HAS_BCLK |
RESET_AXI,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
- .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
+ .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
};
static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
.flags = RESET_AXI,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
- .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
+ .larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
};
static const struct of_device_id mtk_iommu_of_ids[] = {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index ae70296af2b4..be6d32ee5bda 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -23,6 +23,7 @@
#define HAS_VLD_PA_RNG BIT(2)
#define RESET_AXI BIT(3)
#define OUT_ORDER_EN BIT(4)
+#define HAS_SUB_COMM BIT(5)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
((((pdata)->flags) & (_x)) == (_x))
@@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
u32 flags;
u32 inv_sel_reg;
- unsigned char larbid_remap[MTK_LARB_NR_MAX];
+ unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
};
struct mtk_iommu_domain;
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 5a34b87d89e3..fa65a55468e2 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -12,6 +12,8 @@
#ifdef CONFIG_MTK_SMI
#define MTK_LARB_NR_MAX 16
+#define MTK_LARB_COM_MAX 8
+#define MTK_LARB_SUBCOM_MAX 4
#define MTK_SMI_MMU_EN(port) BIT(port)
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
The max larb number that a iommu HW support is 8(larb0~larb7 in the below
diagram).
If the larb's number is over 8, we use a sub_common for merging
several larbs into one larb. At this case, we will extend larb_id:
bit[11:9] means common-id;
bit[8:7] means subcommon-id;
From these two variables, we could get the real larb number when
translation fault happen.
The diagram is as below:
EMI
|
IOMMU
|
-----------------
| |
common1 common0
| |
-----------------
|
smi common
|
------------------------------------
| | | | | |
3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
| | | | | |
Larb0 Larb1 | Larb3 ... Larb7
|
smi sub common
|
--------------------------
| | | |
2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
| | | |
Larb8 Larb9 Larb10 Larb11
In this patch we extend larb_remap[] to larb_remap[8][4] for this.
larb_remap[x][y]: x means common-id above, y means subcommon_id above.
We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
macro.
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
drivers/iommu/mtk_iommu.h | 3 ++-
include/soc/mediatek/smi.h | 2 ++
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 116418cc1cf8..ec1f86913739 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -91,6 +91,8 @@
#define REG_MMU1_INVLD_PA 0x148
#define REG_MMU0_INT_ID 0x150
#define REG_MMU1_INT_ID 0x154
+#define F_MMU_INT_ID_COMM_ID(a) (((a) >> 9) & 0x7)
+#define F_MMU_INT_ID_SUB_COMM_ID(a) (((a) >> 7) & 0x3)
#define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
#define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
@@ -229,7 +231,7 @@ 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;
+ unsigned int fault_larb, fault_port, sub_comm = 0;
bool layer, write;
/* Read error info from registers */
@@ -245,10 +247,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;
- fault_larb = F_MMU_INT_ID_LARB_ID(regval);
fault_port = F_MMU_INT_ID_PORT_ID(regval);
-
- fault_larb = data->plat_data->larbid_remap[fault_larb];
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_SUB_COMM)) {
+ fault_larb = F_MMU_INT_ID_COMM_ID(regval);
+ sub_comm = F_MMU_INT_ID_SUB_COMM_ID(regval);
+ } else {
+ fault_larb = F_MMU_INT_ID_LARB_ID(regval);
+ }
+ fault_larb = data->plat_data->larbid_remap[fault_larb][sub_comm];
if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
@@ -778,7 +784,7 @@ static const struct mtk_iommu_plat_data mt2712_data = {
HAS_BCLK |
HAS_VLD_PA_RNG,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
- .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
+ .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
};
static const struct mtk_iommu_plat_data mt8173_data = {
@@ -787,14 +793,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
HAS_BCLK |
RESET_AXI,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
- .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
+ .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
};
static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
.flags = RESET_AXI,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
- .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
+ .larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
};
static const struct of_device_id mtk_iommu_of_ids[] = {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index ae70296af2b4..be6d32ee5bda 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -23,6 +23,7 @@
#define HAS_VLD_PA_RNG BIT(2)
#define RESET_AXI BIT(3)
#define OUT_ORDER_EN BIT(4)
+#define HAS_SUB_COMM BIT(5)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
((((pdata)->flags) & (_x)) == (_x))
@@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
u32 flags;
u32 inv_sel_reg;
- unsigned char larbid_remap[MTK_LARB_NR_MAX];
+ unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
};
struct mtk_iommu_domain;
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 5a34b87d89e3..fa65a55468e2 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -12,6 +12,8 @@
#ifdef CONFIG_MTK_SMI
#define MTK_LARB_NR_MAX 16
+#define MTK_LARB_COM_MAX 8
+#define MTK_LARB_SUBCOM_MAX 4
#define MTK_SMI_MMU_EN(port) BIT(port)
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
The max larb number that a iommu HW support is 8(larb0~larb7 in the below
diagram).
If the larb's number is over 8, we use a sub_common for merging
several larbs into one larb. At this case, we will extend larb_id:
bit[11:9] means common-id;
bit[8:7] means subcommon-id;
From these two variables, we could get the real larb number when
translation fault happen.
The diagram is as below:
EMI
|
IOMMU
|
-----------------
| |
common1 common0
| |
-----------------
|
smi common
|
------------------------------------
| | | | | |
3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
| | | | | |
Larb0 Larb1 | Larb3 ... Larb7
|
smi sub common
|
--------------------------
| | | |
2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
| | | |
Larb8 Larb9 Larb10 Larb11
In this patch we extend larb_remap[] to larb_remap[8][4] for this.
larb_remap[x][y]: x means common-id above, y means subcommon_id above.
We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
macro.
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
drivers/iommu/mtk_iommu.h | 3 ++-
include/soc/mediatek/smi.h | 2 ++
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 116418cc1cf8..ec1f86913739 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -91,6 +91,8 @@
#define REG_MMU1_INVLD_PA 0x148
#define REG_MMU0_INT_ID 0x150
#define REG_MMU1_INT_ID 0x154
+#define F_MMU_INT_ID_COMM_ID(a) (((a) >> 9) & 0x7)
+#define F_MMU_INT_ID_SUB_COMM_ID(a) (((a) >> 7) & 0x3)
#define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
#define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
@@ -229,7 +231,7 @@ 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;
+ unsigned int fault_larb, fault_port, sub_comm = 0;
bool layer, write;
/* Read error info from registers */
@@ -245,10 +247,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;
- fault_larb = F_MMU_INT_ID_LARB_ID(regval);
fault_port = F_MMU_INT_ID_PORT_ID(regval);
-
- fault_larb = data->plat_data->larbid_remap[fault_larb];
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_SUB_COMM)) {
+ fault_larb = F_MMU_INT_ID_COMM_ID(regval);
+ sub_comm = F_MMU_INT_ID_SUB_COMM_ID(regval);
+ } else {
+ fault_larb = F_MMU_INT_ID_LARB_ID(regval);
+ }
+ fault_larb = data->plat_data->larbid_remap[fault_larb][sub_comm];
if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
@@ -778,7 +784,7 @@ static const struct mtk_iommu_plat_data mt2712_data = {
HAS_BCLK |
HAS_VLD_PA_RNG,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
- .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
+ .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
};
static const struct mtk_iommu_plat_data mt8173_data = {
@@ -787,14 +793,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
HAS_BCLK |
RESET_AXI,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
- .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
+ .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
};
static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
.flags = RESET_AXI,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
- .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
+ .larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
};
static const struct of_device_id mtk_iommu_of_ids[] = {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index ae70296af2b4..be6d32ee5bda 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -23,6 +23,7 @@
#define HAS_VLD_PA_RNG BIT(2)
#define RESET_AXI BIT(3)
#define OUT_ORDER_EN BIT(4)
+#define HAS_SUB_COMM BIT(5)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
((((pdata)->flags) & (_x)) == (_x))
@@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
u32 flags;
u32 inv_sel_reg;
- unsigned char larbid_remap[MTK_LARB_NR_MAX];
+ unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
};
struct mtk_iommu_domain;
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 5a34b87d89e3..fa65a55468e2 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -12,6 +12,8 @@
#ifdef CONFIG_MTK_SMI
#define MTK_LARB_NR_MAX 16
+#define MTK_LARB_COM_MAX 8
+#define MTK_LARB_SUBCOM_MAX 4
#define MTK_SMI_MMU_EN(port) BIT(port)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
2020-06-29 7:13 ` Chao Hao
(?)
@ 2020-06-29 7:13 ` Chao Hao
-1 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
Some platforms(ex: mt6779) need to improve performance by setting
REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
whether we need to set the register. If the register uses default value,
iommu will send command to EMI without restriction, when the number of
commands become more and more, it will drop the EMI performance. So when
more than ten_commands(default value) don't be handled for EMI, iommu will
stop send command to EMI for keeping EMI's performace by enabling write
throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 10 ++++++++++
drivers/iommu/mtk_iommu.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index ec1f86913739..92316c4175a9 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -46,6 +46,8 @@
#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
#define REG_MMU_DCM_DIS 0x050
+#define REG_MMU_WR_LEN 0x054
+#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
#define REG_MMU_CTRL_REG 0x110
#define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
@@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
+ /* write command throttling mode */
+ regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
+ regval &= ~F_MMU_WR_THROT_DIS_BIT;
+ writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
+ }
regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
@@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
struct mtk_iommu_suspend_reg *reg = &data->reg;
void __iomem *base = data->base;
+ reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
@@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
return ret;
}
+ writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index be6d32ee5bda..ce4f4e8f03aa 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -24,6 +24,7 @@
#define RESET_AXI BIT(3)
#define OUT_ORDER_EN BIT(4)
#define HAS_SUB_COMM BIT(5)
+#define WR_THROT_EN BIT(6)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
((((pdata)->flags) & (_x)) == (_x))
@@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
u32 int_main_control;
u32 ivrp_paddr;
u32 vld_pa_rng;
+ u32 wr_len;
};
enum mtk_iommu_plat {
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
Some platforms(ex: mt6779) need to improve performance by setting
REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
whether we need to set the register. If the register uses default value,
iommu will send command to EMI without restriction, when the number of
commands become more and more, it will drop the EMI performance. So when
more than ten_commands(default value) don't be handled for EMI, iommu will
stop send command to EMI for keeping EMI's performace by enabling write
throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 10 ++++++++++
drivers/iommu/mtk_iommu.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index ec1f86913739..92316c4175a9 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -46,6 +46,8 @@
#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
#define REG_MMU_DCM_DIS 0x050
+#define REG_MMU_WR_LEN 0x054
+#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
#define REG_MMU_CTRL_REG 0x110
#define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
@@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
+ /* write command throttling mode */
+ regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
+ regval &= ~F_MMU_WR_THROT_DIS_BIT;
+ writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
+ }
regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
@@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
struct mtk_iommu_suspend_reg *reg = &data->reg;
void __iomem *base = data->base;
+ reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
@@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
return ret;
}
+ writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index be6d32ee5bda..ce4f4e8f03aa 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -24,6 +24,7 @@
#define RESET_AXI BIT(3)
#define OUT_ORDER_EN BIT(4)
#define HAS_SUB_COMM BIT(5)
+#define WR_THROT_EN BIT(6)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
((((pdata)->flags) & (_x)) == (_x))
@@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
u32 int_main_control;
u32 ivrp_paddr;
u32 vld_pa_rng;
+ u32 wr_len;
};
enum mtk_iommu_plat {
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
Some platforms(ex: mt6779) need to improve performance by setting
REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
whether we need to set the register. If the register uses default value,
iommu will send command to EMI without restriction, when the number of
commands become more and more, it will drop the EMI performance. So when
more than ten_commands(default value) don't be handled for EMI, iommu will
stop send command to EMI for keeping EMI's performace by enabling write
throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 10 ++++++++++
drivers/iommu/mtk_iommu.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index ec1f86913739..92316c4175a9 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -46,6 +46,8 @@
#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
#define REG_MMU_DCM_DIS 0x050
+#define REG_MMU_WR_LEN 0x054
+#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
#define REG_MMU_CTRL_REG 0x110
#define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
@@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
+ /* write command throttling mode */
+ regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
+ regval &= ~F_MMU_WR_THROT_DIS_BIT;
+ writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
+ }
regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
@@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
struct mtk_iommu_suspend_reg *reg = &data->reg;
void __iomem *base = data->base;
+ reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
@@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
return ret;
}
+ writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index be6d32ee5bda..ce4f4e8f03aa 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -24,6 +24,7 @@
#define RESET_AXI BIT(3)
#define OUT_ORDER_EN BIT(4)
#define HAS_SUB_COMM BIT(5)
+#define WR_THROT_EN BIT(6)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
((((pdata)->flags) & (_x)) == (_x))
@@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
u32 int_main_control;
u32 ivrp_paddr;
u32 vld_pa_rng;
+ u32 wr_len;
};
enum mtk_iommu_plat {
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value
2020-06-29 7:13 ` Chao Hao
(?)
@ 2020-06-29 7:13 ` Chao Hao
-1 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
Starting with mt6779, iommu needs to extend to 256 bytes from 128
bytes which can send the max number of data for memory protection
pa alignment. So we can use a separate patch to modify it.
Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 92316c4175a9..8299a3299090 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -98,7 +98,7 @@
#define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
#define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
-#define MTK_PROTECT_PA_ALIGN 128
+#define MTK_PROTECT_PA_ALIGN 256
/*
* Get the local arbiter ID and the portid within the larb arbiter
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
Starting with mt6779, iommu needs to extend to 256 bytes from 128
bytes which can send the max number of data for memory protection
pa alignment. So we can use a separate patch to modify it.
Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 92316c4175a9..8299a3299090 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -98,7 +98,7 @@
#define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
#define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
-#define MTK_PROTECT_PA_ALIGN 128
+#define MTK_PROTECT_PA_ALIGN 256
/*
* Get the local arbiter ID and the portid within the larb arbiter
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
Starting with mt6779, iommu needs to extend to 256 bytes from 128
bytes which can send the max number of data for memory protection
pa alignment. So we can use a separate patch to modify it.
Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 92316c4175a9..8299a3299090 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -98,7 +98,7 @@
#define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
#define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
-#define MTK_PROTECT_PA_ALIGN 128
+#define MTK_PROTECT_PA_ALIGN 256
/*
* Get the local arbiter ID and the portid within the larb arbiter
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
2020-06-29 7:13 ` Chao Hao
(?)
@ 2020-06-29 7:13 ` Chao Hao
-1 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
MT8173 is different from other SoCs for MMU_CTRL register.
For mt8173, its bit9 is in_order_write_en and doesn't use its
default 1'b1.
For other SoCs, bit[12] represents victim_tlb_en feature and
victim_tlb is enable defaultly(bit[12]=1), if we use
"regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
disabled, it will drop iommu performace.
So we need to deal with the setting of MMU_CTRL separately
for mt8173 and others.
Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
Suggested-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
return ret;
}
+ regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
if (data->plat_data->m4u_plat == M4U_MT8173)
regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
else
- regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
+ regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
regval = F_L2_MULIT_HIT_EN |
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
MT8173 is different from other SoCs for MMU_CTRL register.
For mt8173, its bit9 is in_order_write_en and doesn't use its
default 1'b1.
For other SoCs, bit[12] represents victim_tlb_en feature and
victim_tlb is enable defaultly(bit[12]=1), if we use
"regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
disabled, it will drop iommu performace.
So we need to deal with the setting of MMU_CTRL separately
for mt8173 and others.
Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
Suggested-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
return ret;
}
+ regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
if (data->plat_data->m4u_plat == M4U_MT8173)
regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
else
- regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
+ regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
regval = F_L2_MULIT_HIT_EN |
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
MT8173 is different from other SoCs for MMU_CTRL register.
For mt8173, its bit9 is in_order_write_en and doesn't use its
default 1'b1.
For other SoCs, bit[12] represents victim_tlb_en feature and
victim_tlb is enable defaultly(bit[12]=1), if we use
"regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
disabled, it will drop iommu performace.
So we need to deal with the setting of MMU_CTRL separately
for mt8173 and others.
Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
Suggested-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
return ret;
}
+ regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
if (data->plat_data->m4u_plat == M4U_MT8173)
regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
else
- regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
+ regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
regval = F_L2_MULIT_HIT_EN |
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support
2020-06-29 7:13 ` Chao Hao
(?)
@ 2020-06-29 7:13 ` Chao Hao
-1 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, linux-arm-kernel
1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
2. Add mt6779_data to support mm_iommu HW init.
Cc: Yong Wu <yong.wu@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 11 +++++++++++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index e46e2deee3fd..1575196d9cd5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -37,6 +37,7 @@
#define REG_MMU_INVLD_START_A 0x024
#define REG_MMU_INVLD_END_A 0x028
+#define REG_MMU_INV_SEL_GEN2 0x02c
#define REG_MMU_INV_SEL_GEN1 0x038
#define F_INVLD_EN0 BIT(0)
#define F_INVLD_EN1 BIT(1)
@@ -798,6 +799,15 @@ static const struct mtk_iommu_plat_data mt2712_data = {
.larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
};
+static const struct mtk_iommu_plat_data mt6779_data = {
+ .m4u_plat = M4U_MT6779,
+ .flags = HAS_SUB_COMM |
+ OUT_ORDER_EN |
+ WR_THROT_EN,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
+ .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
+};
+
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
.flags = HAS_4GB_MODE |
@@ -816,6 +826,7 @@ static const struct mtk_iommu_plat_data mt8183_data = {
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,mt8173-m4u", .data = &mt8173_data},
{ .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
{}
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index ce4f4e8f03aa..a080db2e8a93 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -43,6 +43,7 @@ struct mtk_iommu_suspend_reg {
enum mtk_iommu_plat {
M4U_MT2701,
M4U_MT2712,
+ M4U_MT6779,
M4U_MT8173,
M4U_MT8183,
};
--
2.18.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
2. Add mt6779_data to support mm_iommu HW init.
Cc: Yong Wu <yong.wu@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 11 +++++++++++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index e46e2deee3fd..1575196d9cd5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -37,6 +37,7 @@
#define REG_MMU_INVLD_START_A 0x024
#define REG_MMU_INVLD_END_A 0x028
+#define REG_MMU_INV_SEL_GEN2 0x02c
#define REG_MMU_INV_SEL_GEN1 0x038
#define F_INVLD_EN0 BIT(0)
#define F_INVLD_EN1 BIT(1)
@@ -798,6 +799,15 @@ static const struct mtk_iommu_plat_data mt2712_data = {
.larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
};
+static const struct mtk_iommu_plat_data mt6779_data = {
+ .m4u_plat = M4U_MT6779,
+ .flags = HAS_SUB_COMM |
+ OUT_ORDER_EN |
+ WR_THROT_EN,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
+ .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
+};
+
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
.flags = HAS_4GB_MODE |
@@ -816,6 +826,7 @@ static const struct mtk_iommu_plat_data mt8183_data = {
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,mt8173-m4u", .data = &mt8173_data},
{ .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
{}
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index ce4f4e8f03aa..a080db2e8a93 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -43,6 +43,7 @@ struct mtk_iommu_suspend_reg {
enum mtk_iommu_plat {
M4U_MT2701,
M4U_MT2712,
+ M4U_MT6779,
M4U_MT8173,
M4U_MT8183,
};
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 101+ messages in thread
* [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support
@ 2020-06-29 7:13 ` Chao Hao
0 siblings, 0 replies; 101+ messages in thread
From: Chao Hao @ 2020-06-29 7:13 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, linux-mediatek, Yong Wu, linux-arm-kernel
1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
2. Add mt6779_data to support mm_iommu HW init.
Cc: Yong Wu <yong.wu@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 11 +++++++++++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index e46e2deee3fd..1575196d9cd5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -37,6 +37,7 @@
#define REG_MMU_INVLD_START_A 0x024
#define REG_MMU_INVLD_END_A 0x028
+#define REG_MMU_INV_SEL_GEN2 0x02c
#define REG_MMU_INV_SEL_GEN1 0x038
#define F_INVLD_EN0 BIT(0)
#define F_INVLD_EN1 BIT(1)
@@ -798,6 +799,15 @@ static const struct mtk_iommu_plat_data mt2712_data = {
.larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
};
+static const struct mtk_iommu_plat_data mt6779_data = {
+ .m4u_plat = M4U_MT6779,
+ .flags = HAS_SUB_COMM |
+ OUT_ORDER_EN |
+ WR_THROT_EN,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
+ .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
+};
+
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
.flags = HAS_4GB_MODE |
@@ -816,6 +826,7 @@ static const struct mtk_iommu_plat_data mt8183_data = {
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,mt8173-m4u", .data = &mt8173_data},
{ .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
{}
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index ce4f4e8f03aa..a080db2e8a93 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -43,6 +43,7 @@ struct mtk_iommu_suspend_reg {
enum mtk_iommu_plat {
M4U_MT2701,
M4U_MT2712,
+ M4U_MT6779,
M4U_MT8173,
M4U_MT8183,
};
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
2020-06-29 7:13 ` Chao Hao
(?)
(?)
@ 2020-06-29 9:11 ` Matthias Brugger
-1 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 9:11 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: Yong Wu, Evan Green, iommu, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, FY Yang
On 29/06/2020 09:13, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for a flag present.
> No functional change.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 23 ++++++++++++-----------
> drivers/iommu/mtk_iommu.h | 16 ++++++++++------
> 2 files changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 88d3df5b91c2..8f81df6cbe51 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -563,7 +563,8 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> upper_32_bits(data->protect_base);
> writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
>
> - if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
> + if (data->enable_4GB &&
> + MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_VLD_PA_RNG)) {
> /*
> * If 4GB mode is enabled, the validate PA range is from
> * 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
> @@ -573,7 +574,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> - if (data->plat_data->reset_axi) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> /* The register is called STANDARD_AXI_MODE in this case */
> writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> }
> @@ -618,7 +619,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>
> /* Whether the current dram is over 4GB */
> data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> - if (!data->plat_data->has_4gb_mode)
> + if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
> data->enable_4GB = false;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -631,7 +632,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (data->irq < 0)
> return data->irq;
>
> - if (data->plat_data->has_bclk) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_BCLK)) {
> data->bclk = devm_clk_get(dev, "bclk");
> if (IS_ERR(data->bclk))
> return PTR_ERR(data->bclk);
> @@ -763,23 +764,23 @@ static const struct dev_pm_ops mtk_iommu_pm_ops = {
>
> static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .has_vld_pa_rng = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + HAS_VLD_PA_RNG,
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .reset_axi = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + RESET_AXI,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> static const struct mtk_iommu_plat_data mt8183_data = {
> .m4u_plat = M4U_MT8183,
> - .reset_axi = true,
> + .flags = RESET_AXI,
> .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 1b6ea839b92c..7cc39f729263 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -17,6 +17,15 @@
> #include <linux/spinlock.h>
> #include <soc/mediatek/smi.h>
>
> +#define HAS_4GB_MODE BIT(0)
> +/* HW will use the EMI clock if there isn't the "bclk". */
> +#define HAS_BCLK BIT(1)
> +#define HAS_VLD_PA_RNG BIT(2)
> +#define RESET_AXI BIT(3)
> +
> +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> + ((((pdata)->flags) & (_x)) == (_x))
> +
> struct mtk_iommu_suspend_reg {
> u32 misc_ctrl;
> u32 dcm_dis;
> @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
>
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> - bool has_4gb_mode;
> -
> - /* HW will use the EMI clock if there isn't the "bclk". */
> - bool has_bclk;
> - bool has_vld_pa_rng;
> - bool reset_axi;
> + u32 flags;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-29 9:11 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 9:11 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for a flag present.
> No functional change.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 23 ++++++++++++-----------
> drivers/iommu/mtk_iommu.h | 16 ++++++++++------
> 2 files changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 88d3df5b91c2..8f81df6cbe51 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -563,7 +563,8 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> upper_32_bits(data->protect_base);
> writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
>
> - if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
> + if (data->enable_4GB &&
> + MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_VLD_PA_RNG)) {
> /*
> * If 4GB mode is enabled, the validate PA range is from
> * 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
> @@ -573,7 +574,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> - if (data->plat_data->reset_axi) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> /* The register is called STANDARD_AXI_MODE in this case */
> writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> }
> @@ -618,7 +619,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>
> /* Whether the current dram is over 4GB */
> data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> - if (!data->plat_data->has_4gb_mode)
> + if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
> data->enable_4GB = false;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -631,7 +632,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (data->irq < 0)
> return data->irq;
>
> - if (data->plat_data->has_bclk) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_BCLK)) {
> data->bclk = devm_clk_get(dev, "bclk");
> if (IS_ERR(data->bclk))
> return PTR_ERR(data->bclk);
> @@ -763,23 +764,23 @@ static const struct dev_pm_ops mtk_iommu_pm_ops = {
>
> static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .has_vld_pa_rng = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + HAS_VLD_PA_RNG,
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .reset_axi = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + RESET_AXI,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> static const struct mtk_iommu_plat_data mt8183_data = {
> .m4u_plat = M4U_MT8183,
> - .reset_axi = true,
> + .flags = RESET_AXI,
> .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 1b6ea839b92c..7cc39f729263 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -17,6 +17,15 @@
> #include <linux/spinlock.h>
> #include <soc/mediatek/smi.h>
>
> +#define HAS_4GB_MODE BIT(0)
> +/* HW will use the EMI clock if there isn't the "bclk". */
> +#define HAS_BCLK BIT(1)
> +#define HAS_VLD_PA_RNG BIT(2)
> +#define RESET_AXI BIT(3)
> +
> +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> + ((((pdata)->flags) & (_x)) == (_x))
> +
> struct mtk_iommu_suspend_reg {
> u32 misc_ctrl;
> u32 dcm_dis;
> @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
>
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> - bool has_4gb_mode;
> -
> - /* HW will use the EMI clock if there isn't the "bclk". */
> - bool has_bclk;
> - bool has_vld_pa_rng;
> - bool reset_axi;
> + u32 flags;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-29 9:11 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 9:11 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for a flag present.
> No functional change.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 23 ++++++++++++-----------
> drivers/iommu/mtk_iommu.h | 16 ++++++++++------
> 2 files changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 88d3df5b91c2..8f81df6cbe51 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -563,7 +563,8 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> upper_32_bits(data->protect_base);
> writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
>
> - if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
> + if (data->enable_4GB &&
> + MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_VLD_PA_RNG)) {
> /*
> * If 4GB mode is enabled, the validate PA range is from
> * 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
> @@ -573,7 +574,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> - if (data->plat_data->reset_axi) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> /* The register is called STANDARD_AXI_MODE in this case */
> writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> }
> @@ -618,7 +619,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>
> /* Whether the current dram is over 4GB */
> data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> - if (!data->plat_data->has_4gb_mode)
> + if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
> data->enable_4GB = false;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -631,7 +632,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (data->irq < 0)
> return data->irq;
>
> - if (data->plat_data->has_bclk) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_BCLK)) {
> data->bclk = devm_clk_get(dev, "bclk");
> if (IS_ERR(data->bclk))
> return PTR_ERR(data->bclk);
> @@ -763,23 +764,23 @@ static const struct dev_pm_ops mtk_iommu_pm_ops = {
>
> static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .has_vld_pa_rng = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + HAS_VLD_PA_RNG,
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .reset_axi = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + RESET_AXI,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> static const struct mtk_iommu_plat_data mt8183_data = {
> .m4u_plat = M4U_MT8183,
> - .reset_axi = true,
> + .flags = RESET_AXI,
> .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 1b6ea839b92c..7cc39f729263 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -17,6 +17,15 @@
> #include <linux/spinlock.h>
> #include <soc/mediatek/smi.h>
>
> +#define HAS_4GB_MODE BIT(0)
> +/* HW will use the EMI clock if there isn't the "bclk". */
> +#define HAS_BCLK BIT(1)
> +#define HAS_VLD_PA_RNG BIT(2)
> +#define RESET_AXI BIT(3)
> +
> +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> + ((((pdata)->flags) & (_x)) == (_x))
> +
> struct mtk_iommu_suspend_reg {
> u32 misc_ctrl;
> u32 dcm_dis;
> @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
>
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> - bool has_4gb_mode;
> -
> - /* HW will use the EMI clock if there isn't the "bclk". */
> - bool has_bclk;
> - bool has_vld_pa_rng;
> - bool reset_axi;
> + u32 flags;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-29 9:11 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 9:11 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for a flag present.
> No functional change.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 23 ++++++++++++-----------
> drivers/iommu/mtk_iommu.h | 16 ++++++++++------
> 2 files changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 88d3df5b91c2..8f81df6cbe51 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -563,7 +563,8 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> upper_32_bits(data->protect_base);
> writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
>
> - if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
> + if (data->enable_4GB &&
> + MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_VLD_PA_RNG)) {
> /*
> * If 4GB mode is enabled, the validate PA range is from
> * 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
> @@ -573,7 +574,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> - if (data->plat_data->reset_axi) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> /* The register is called STANDARD_AXI_MODE in this case */
> writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> }
> @@ -618,7 +619,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>
> /* Whether the current dram is over 4GB */
> data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> - if (!data->plat_data->has_4gb_mode)
> + if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
> data->enable_4GB = false;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -631,7 +632,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (data->irq < 0)
> return data->irq;
>
> - if (data->plat_data->has_bclk) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_BCLK)) {
> data->bclk = devm_clk_get(dev, "bclk");
> if (IS_ERR(data->bclk))
> return PTR_ERR(data->bclk);
> @@ -763,23 +764,23 @@ static const struct dev_pm_ops mtk_iommu_pm_ops = {
>
> static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .has_vld_pa_rng = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + HAS_VLD_PA_RNG,
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .reset_axi = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + RESET_AXI,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> static const struct mtk_iommu_plat_data mt8183_data = {
> .m4u_plat = M4U_MT8183,
> - .reset_axi = true,
> + .flags = RESET_AXI,
> .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 1b6ea839b92c..7cc39f729263 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -17,6 +17,15 @@
> #include <linux/spinlock.h>
> #include <soc/mediatek/smi.h>
>
> +#define HAS_4GB_MODE BIT(0)
> +/* HW will use the EMI clock if there isn't the "bclk". */
> +#define HAS_BCLK BIT(1)
> +#define HAS_VLD_PA_RNG BIT(2)
> +#define RESET_AXI BIT(3)
> +
> +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> + ((((pdata)->flags) & (_x)) == (_x))
> +
> struct mtk_iommu_suspend_reg {
> u32 misc_ctrl;
> u32 dcm_dis;
> @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
>
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> - bool has_4gb_mode;
> -
> - /* HW will use the EMI clock if there isn't the "bclk". */
> - bool has_bclk;
> - bool has_vld_pa_rng;
> - bool reset_axi;
> + u32 flags;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
2020-06-29 7:13 ` Chao Hao
(?)
(?)
@ 2020-06-29 9:28 ` Matthias Brugger
-1 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 9:28 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: Yong Wu, Evan Green, iommu, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, FY Yang
On 29/06/2020 09:13, Chao Hao wrote:
> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> in MISC_CTRL register.
> F_MMU_STANDARD_AXI_MODE_BIT:
> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> standard AXI protocol), iommu will send urgent read command firstly
> compare with normal read command to improve performance.
Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
Does this mean that you will send a 'urgent read command' which is not described
in the specifications instead of a normal read command?
> F_MMU_IN_ORDER_WR_EN:
> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> will re-order write command and send more higher priority write command
> instead of sending write command in order. The feature be controlled
> by OUT_ORDER_EN macro definition.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 8f81df6cbe51..67b46b5d83d9 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -42,6 +42,9 @@
> #define F_INVLD_EN1 BIT(1)
>
> #define REG_MMU_MISC_CTRL 0x048
> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> +
> #define REG_MMU_DCM_DIS 0x050
>
> #define REG_MMU_CTRL_REG 0x110
> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
We only need to read regval in the else branch.
> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> /* The register is called STANDARD_AXI_MODE in this case */
> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> + regval = 0;
> + } else {
> + /* For mm_iommu, it can improve performance by the setting */
> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> + regval &= ~F_MMU_IN_ORDER_WR_EN;
> }
> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
>
> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> dev_name(data->dev), (void *)data)) {
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 7cc39f729263..4b780b651ef4 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -22,6 +22,7 @@
> #define HAS_BCLK BIT(1)
> #define HAS_VLD_PA_RNG BIT(2)
> #define RESET_AXI BIT(3)
> +#define OUT_ORDER_EN BIT(4)
Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
write path.
>
> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> ((((pdata)->flags) & (_x)) == (_x))
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-06-29 9:28 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 9:28 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> in MISC_CTRL register.
> F_MMU_STANDARD_AXI_MODE_BIT:
> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> standard AXI protocol), iommu will send urgent read command firstly
> compare with normal read command to improve performance.
Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
Does this mean that you will send a 'urgent read command' which is not described
in the specifications instead of a normal read command?
> F_MMU_IN_ORDER_WR_EN:
> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> will re-order write command and send more higher priority write command
> instead of sending write command in order. The feature be controlled
> by OUT_ORDER_EN macro definition.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 8f81df6cbe51..67b46b5d83d9 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -42,6 +42,9 @@
> #define F_INVLD_EN1 BIT(1)
>
> #define REG_MMU_MISC_CTRL 0x048
> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> +
> #define REG_MMU_DCM_DIS 0x050
>
> #define REG_MMU_CTRL_REG 0x110
> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
We only need to read regval in the else branch.
> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> /* The register is called STANDARD_AXI_MODE in this case */
> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> + regval = 0;
> + } else {
> + /* For mm_iommu, it can improve performance by the setting */
> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> + regval &= ~F_MMU_IN_ORDER_WR_EN;
> }
> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
>
> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> dev_name(data->dev), (void *)data)) {
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 7cc39f729263..4b780b651ef4 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -22,6 +22,7 @@
> #define HAS_BCLK BIT(1)
> #define HAS_VLD_PA_RNG BIT(2)
> #define RESET_AXI BIT(3)
> +#define OUT_ORDER_EN BIT(4)
Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
write path.
>
> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> ((((pdata)->flags) & (_x)) == (_x))
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-06-29 9:28 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 9:28 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> in MISC_CTRL register.
> F_MMU_STANDARD_AXI_MODE_BIT:
> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> standard AXI protocol), iommu will send urgent read command firstly
> compare with normal read command to improve performance.
Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
Does this mean that you will send a 'urgent read command' which is not described
in the specifications instead of a normal read command?
> F_MMU_IN_ORDER_WR_EN:
> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> will re-order write command and send more higher priority write command
> instead of sending write command in order. The feature be controlled
> by OUT_ORDER_EN macro definition.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 8f81df6cbe51..67b46b5d83d9 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -42,6 +42,9 @@
> #define F_INVLD_EN1 BIT(1)
>
> #define REG_MMU_MISC_CTRL 0x048
> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> +
> #define REG_MMU_DCM_DIS 0x050
>
> #define REG_MMU_CTRL_REG 0x110
> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
We only need to read regval in the else branch.
> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> /* The register is called STANDARD_AXI_MODE in this case */
> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> + regval = 0;
> + } else {
> + /* For mm_iommu, it can improve performance by the setting */
> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> + regval &= ~F_MMU_IN_ORDER_WR_EN;
> }
> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
>
> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> dev_name(data->dev), (void *)data)) {
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 7cc39f729263..4b780b651ef4 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -22,6 +22,7 @@
> #define HAS_BCLK BIT(1)
> #define HAS_VLD_PA_RNG BIT(2)
> #define RESET_AXI BIT(3)
> +#define OUT_ORDER_EN BIT(4)
Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
write path.
>
> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> ((((pdata)->flags) & (_x)) == (_x))
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-06-29 9:28 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 9:28 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> in MISC_CTRL register.
> F_MMU_STANDARD_AXI_MODE_BIT:
> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> standard AXI protocol), iommu will send urgent read command firstly
> compare with normal read command to improve performance.
Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
Does this mean that you will send a 'urgent read command' which is not described
in the specifications instead of a normal read command?
> F_MMU_IN_ORDER_WR_EN:
> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> will re-order write command and send more higher priority write command
> instead of sending write command in order. The feature be controlled
> by OUT_ORDER_EN macro definition.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 8f81df6cbe51..67b46b5d83d9 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -42,6 +42,9 @@
> #define F_INVLD_EN1 BIT(1)
>
> #define REG_MMU_MISC_CTRL 0x048
> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> +
> #define REG_MMU_DCM_DIS 0x050
>
> #define REG_MMU_CTRL_REG 0x110
> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
We only need to read regval in the else branch.
> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> /* The register is called STANDARD_AXI_MODE in this case */
> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> + regval = 0;
> + } else {
> + /* For mm_iommu, it can improve performance by the setting */
> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> + regval &= ~F_MMU_IN_ORDER_WR_EN;
> }
> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
>
> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> dev_name(data->dev), (void *)data)) {
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 7cc39f729263..4b780b651ef4 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -22,6 +22,7 @@
> #define HAS_BCLK BIT(1)
> #define HAS_VLD_PA_RNG BIT(2)
> #define RESET_AXI BIT(3)
> +#define OUT_ORDER_EN BIT(4)
Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
write path.
>
> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> ((((pdata)->flags) & (_x)) == (_x))
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
2020-06-29 7:13 ` Chao Hao
(?)
(?)
@ 2020-06-29 10:16 ` Matthias Brugger
-1 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:16 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: Yong Wu, Evan Green, iommu, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, FY Yang
On 29/06/2020 09:13, Chao Hao wrote:
> Some platforms(ex: mt6779) need to improve performance by setting
> REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> whether we need to set the register. If the register uses default value,
> iommu will send command to EMI without restriction, when the number of
> commands become more and more, it will drop the EMI performance. So when
> more than ten_commands(default value) don't be handled for EMI, iommu will
> stop send command to EMI for keeping EMI's performace by enabling write
> throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 10 ++++++++++
> drivers/iommu/mtk_iommu.h | 2 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index ec1f86913739..92316c4175a9 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -46,6 +46,8 @@
> #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>
> #define REG_MMU_DCM_DIS 0x050
> +#define REG_MMU_WR_LEN 0x054
The register name is confusing. For me it seems to describe the length of a
write but it is used for controlling the write throttling. Is this the name
that's used in the datasheet?
> +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
There are two spaces between '|' and 'BIT(21)', should be one.
Regarding the name of the define, what does the 'F_' statnds for? Also I think
it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
Regards,
Matthias
>
> #define REG_MMU_CTRL_REG 0x110
> #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
> @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
> + /* write command throttling mode */
> + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
> + regval &= ~F_MMU_WR_THROT_DIS_BIT;
> + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
> + }
>
> regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> struct mtk_iommu_suspend_reg *reg = &data->reg;
> void __iomem *base = data->base;
>
> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
> reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
> reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
> reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
> @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
> dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
> return ret;
> }
> + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
> writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
> writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
> writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index be6d32ee5bda..ce4f4e8f03aa 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -24,6 +24,7 @@
> #define RESET_AXI BIT(3)
> #define OUT_ORDER_EN BIT(4)
> #define HAS_SUB_COMM BIT(5)
> +#define WR_THROT_EN BIT(6)
>
> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> ((((pdata)->flags) & (_x)) == (_x))
> @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
> u32 int_main_control;
> u32 ivrp_paddr;
> u32 vld_pa_rng;
> + u32 wr_len;
> };
>
> enum mtk_iommu_plat {
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-06-29 10:16 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:16 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Some platforms(ex: mt6779) need to improve performance by setting
> REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> whether we need to set the register. If the register uses default value,
> iommu will send command to EMI without restriction, when the number of
> commands become more and more, it will drop the EMI performance. So when
> more than ten_commands(default value) don't be handled for EMI, iommu will
> stop send command to EMI for keeping EMI's performace by enabling write
> throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 10 ++++++++++
> drivers/iommu/mtk_iommu.h | 2 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index ec1f86913739..92316c4175a9 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -46,6 +46,8 @@
> #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>
> #define REG_MMU_DCM_DIS 0x050
> +#define REG_MMU_WR_LEN 0x054
The register name is confusing. For me it seems to describe the length of a
write but it is used for controlling the write throttling. Is this the name
that's used in the datasheet?
> +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
There are two spaces between '|' and 'BIT(21)', should be one.
Regarding the name of the define, what does the 'F_' statnds for? Also I think
it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
Regards,
Matthias
>
> #define REG_MMU_CTRL_REG 0x110
> #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
> @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
> + /* write command throttling mode */
> + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
> + regval &= ~F_MMU_WR_THROT_DIS_BIT;
> + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
> + }
>
> regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> struct mtk_iommu_suspend_reg *reg = &data->reg;
> void __iomem *base = data->base;
>
> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
> reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
> reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
> reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
> @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
> dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
> return ret;
> }
> + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
> writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
> writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
> writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index be6d32ee5bda..ce4f4e8f03aa 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -24,6 +24,7 @@
> #define RESET_AXI BIT(3)
> #define OUT_ORDER_EN BIT(4)
> #define HAS_SUB_COMM BIT(5)
> +#define WR_THROT_EN BIT(6)
>
> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> ((((pdata)->flags) & (_x)) == (_x))
> @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
> u32 int_main_control;
> u32 ivrp_paddr;
> u32 vld_pa_rng;
> + u32 wr_len;
> };
>
> enum mtk_iommu_plat {
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-06-29 10:16 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:16 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Some platforms(ex: mt6779) need to improve performance by setting
> REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> whether we need to set the register. If the register uses default value,
> iommu will send command to EMI without restriction, when the number of
> commands become more and more, it will drop the EMI performance. So when
> more than ten_commands(default value) don't be handled for EMI, iommu will
> stop send command to EMI for keeping EMI's performace by enabling write
> throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 10 ++++++++++
> drivers/iommu/mtk_iommu.h | 2 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index ec1f86913739..92316c4175a9 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -46,6 +46,8 @@
> #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>
> #define REG_MMU_DCM_DIS 0x050
> +#define REG_MMU_WR_LEN 0x054
The register name is confusing. For me it seems to describe the length of a
write but it is used for controlling the write throttling. Is this the name
that's used in the datasheet?
> +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
There are two spaces between '|' and 'BIT(21)', should be one.
Regarding the name of the define, what does the 'F_' statnds for? Also I think
it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
Regards,
Matthias
>
> #define REG_MMU_CTRL_REG 0x110
> #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
> @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
> + /* write command throttling mode */
> + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
> + regval &= ~F_MMU_WR_THROT_DIS_BIT;
> + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
> + }
>
> regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> struct mtk_iommu_suspend_reg *reg = &data->reg;
> void __iomem *base = data->base;
>
> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
> reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
> reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
> reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
> @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
> dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
> return ret;
> }
> + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
> writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
> writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
> writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index be6d32ee5bda..ce4f4e8f03aa 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -24,6 +24,7 @@
> #define RESET_AXI BIT(3)
> #define OUT_ORDER_EN BIT(4)
> #define HAS_SUB_COMM BIT(5)
> +#define WR_THROT_EN BIT(6)
>
> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> ((((pdata)->flags) & (_x)) == (_x))
> @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
> u32 int_main_control;
> u32 ivrp_paddr;
> u32 vld_pa_rng;
> + u32 wr_len;
> };
>
> enum mtk_iommu_plat {
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-06-29 10:16 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:16 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Some platforms(ex: mt6779) need to improve performance by setting
> REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> whether we need to set the register. If the register uses default value,
> iommu will send command to EMI without restriction, when the number of
> commands become more and more, it will drop the EMI performance. So when
> more than ten_commands(default value) don't be handled for EMI, iommu will
> stop send command to EMI for keeping EMI's performace by enabling write
> throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 10 ++++++++++
> drivers/iommu/mtk_iommu.h | 2 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index ec1f86913739..92316c4175a9 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -46,6 +46,8 @@
> #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>
> #define REG_MMU_DCM_DIS 0x050
> +#define REG_MMU_WR_LEN 0x054
The register name is confusing. For me it seems to describe the length of a
write but it is used for controlling the write throttling. Is this the name
that's used in the datasheet?
> +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
There are two spaces between '|' and 'BIT(21)', should be one.
Regarding the name of the define, what does the 'F_' statnds for? Also I think
it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
Regards,
Matthias
>
> #define REG_MMU_CTRL_REG 0x110
> #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
> @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
> + /* write command throttling mode */
> + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
> + regval &= ~F_MMU_WR_THROT_DIS_BIT;
> + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
> + }
>
> regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> struct mtk_iommu_suspend_reg *reg = &data->reg;
> void __iomem *base = data->base;
>
> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
> reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
> reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
> reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
> @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
> dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
> return ret;
> }
> + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
> writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
> writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
> writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index be6d32ee5bda..ce4f4e8f03aa 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -24,6 +24,7 @@
> #define RESET_AXI BIT(3)
> #define OUT_ORDER_EN BIT(4)
> #define HAS_SUB_COMM BIT(5)
> +#define WR_THROT_EN BIT(6)
>
> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> ((((pdata)->flags) & (_x)) == (_x))
> @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
> u32 int_main_control;
> u32 ivrp_paddr;
> u32 vld_pa_rng;
> + u32 wr_len;
> };
>
> enum mtk_iommu_plat {
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value
2020-06-29 7:13 ` Chao Hao
(?)
(?)
@ 2020-06-29 10:17 ` Matthias Brugger
-1 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:17 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: Yong Wu, Evan Green, iommu, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, FY Yang
On 29/06/2020 09:13, Chao Hao wrote:
> Starting with mt6779, iommu needs to extend to 256 bytes from 128
> bytes which can send the max number of data for memory protection
> pa alignment. So we can use a separate patch to modify it.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 92316c4175a9..8299a3299090 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -98,7 +98,7 @@
> #define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
> #define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
>
> -#define MTK_PROTECT_PA_ALIGN 128
> +#define MTK_PROTECT_PA_ALIGN 256
>
> /*
> * Get the local arbiter ID and the portid within the larb arbiter
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value
@ 2020-06-29 10:17 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:17 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Starting with mt6779, iommu needs to extend to 256 bytes from 128
> bytes which can send the max number of data for memory protection
> pa alignment. So we can use a separate patch to modify it.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 92316c4175a9..8299a3299090 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -98,7 +98,7 @@
> #define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
> #define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
>
> -#define MTK_PROTECT_PA_ALIGN 128
> +#define MTK_PROTECT_PA_ALIGN 256
>
> /*
> * Get the local arbiter ID and the portid within the larb arbiter
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value
@ 2020-06-29 10:17 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:17 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Starting with mt6779, iommu needs to extend to 256 bytes from 128
> bytes which can send the max number of data for memory protection
> pa alignment. So we can use a separate patch to modify it.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 92316c4175a9..8299a3299090 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -98,7 +98,7 @@
> #define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
> #define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
>
> -#define MTK_PROTECT_PA_ALIGN 128
> +#define MTK_PROTECT_PA_ALIGN 256
>
> /*
> * Get the local arbiter ID and the portid within the larb arbiter
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value
@ 2020-06-29 10:17 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:17 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> Starting with mt6779, iommu needs to extend to 256 bytes from 128
> bytes which can send the max number of data for memory protection
> pa alignment. So we can use a separate patch to modify it.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 92316c4175a9..8299a3299090 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -98,7 +98,7 @@
> #define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
> #define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
>
> -#define MTK_PROTECT_PA_ALIGN 128
> +#define MTK_PROTECT_PA_ALIGN 256
>
> /*
> * Get the local arbiter ID and the portid within the larb arbiter
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
2020-06-29 7:13 ` Chao Hao
(?)
(?)
@ 2020-06-29 10:28 ` Matthias Brugger
-1 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:28 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: Yong Wu, Evan Green, iommu, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, FY Yang
On 29/06/2020 09:13, Chao Hao wrote:
> MT8173 is different from other SoCs for MMU_CTRL register.
> For mt8173, its bit9 is in_order_write_en and doesn't use its
> default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en feature and
> victim_tlb is enable defaultly(bit[12]=1), if we use
> "regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
> disabled, it will drop iommu performace.
> So we need to deal with the setting of MMU_CTRL separately
> for mt8173 and others.
>
My proposal to rewrite the commit message:
The MMU_CTRL regiser of MT8173 is different from other SoCs. The in_order_wr_en
is bit[9] which is zero by default.
Other SoCs have the vitcim_tlb_en feature mapped to bit[12]. This bit is set to
one by default. We need to preserve the bit when setting
F_MMU_TF_PROT_TO_PROGRAM_ADDR as otherwise the bit will be cleared and IOMMU
performance will drop.
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> return ret;
> }
>
> + regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
The read is only needed in the else branch.
> if (data->plat_data->m4u_plat == M4U_MT8173)
> regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
> else
> - regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> + regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>
> regval = F_L2_MULIT_HIT_EN |
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
@ 2020-06-29 10:28 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:28 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> MT8173 is different from other SoCs for MMU_CTRL register.
> For mt8173, its bit9 is in_order_write_en and doesn't use its
> default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en feature and
> victim_tlb is enable defaultly(bit[12]=1), if we use
> "regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
> disabled, it will drop iommu performace.
> So we need to deal with the setting of MMU_CTRL separately
> for mt8173 and others.
>
My proposal to rewrite the commit message:
The MMU_CTRL regiser of MT8173 is different from other SoCs. The in_order_wr_en
is bit[9] which is zero by default.
Other SoCs have the vitcim_tlb_en feature mapped to bit[12]. This bit is set to
one by default. We need to preserve the bit when setting
F_MMU_TF_PROT_TO_PROGRAM_ADDR as otherwise the bit will be cleared and IOMMU
performance will drop.
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> return ret;
> }
>
> + regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
The read is only needed in the else branch.
> if (data->plat_data->m4u_plat == M4U_MT8173)
> regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
> else
> - regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> + regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>
> regval = F_L2_MULIT_HIT_EN |
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
@ 2020-06-29 10:28 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:28 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> MT8173 is different from other SoCs for MMU_CTRL register.
> For mt8173, its bit9 is in_order_write_en and doesn't use its
> default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en feature and
> victim_tlb is enable defaultly(bit[12]=1), if we use
> "regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
> disabled, it will drop iommu performace.
> So we need to deal with the setting of MMU_CTRL separately
> for mt8173 and others.
>
My proposal to rewrite the commit message:
The MMU_CTRL regiser of MT8173 is different from other SoCs. The in_order_wr_en
is bit[9] which is zero by default.
Other SoCs have the vitcim_tlb_en feature mapped to bit[12]. This bit is set to
one by default. We need to preserve the bit when setting
F_MMU_TF_PROT_TO_PROGRAM_ADDR as otherwise the bit will be cleared and IOMMU
performance will drop.
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> return ret;
> }
>
> + regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
The read is only needed in the else branch.
> if (data->plat_data->m4u_plat == M4U_MT8173)
> regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
> else
> - regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> + regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>
> regval = F_L2_MULIT_HIT_EN |
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
@ 2020-06-29 10:28 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:28 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> MT8173 is different from other SoCs for MMU_CTRL register.
> For mt8173, its bit9 is in_order_write_en and doesn't use its
> default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en feature and
> victim_tlb is enable defaultly(bit[12]=1), if we use
> "regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
> disabled, it will drop iommu performace.
> So we need to deal with the setting of MMU_CTRL separately
> for mt8173 and others.
>
My proposal to rewrite the commit message:
The MMU_CTRL regiser of MT8173 is different from other SoCs. The in_order_wr_en
is bit[9] which is zero by default.
Other SoCs have the vitcim_tlb_en feature mapped to bit[12]. This bit is set to
one by default. We need to preserve the bit when setting
F_MMU_TF_PROT_TO_PROGRAM_ADDR as otherwise the bit will be cleared and IOMMU
performance will drop.
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> return ret;
> }
>
> + regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
The read is only needed in the else branch.
> if (data->plat_data->m4u_plat == M4U_MT8173)
> regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
> else
> - regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> + regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>
> regval = F_L2_MULIT_HIT_EN |
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support
2020-06-29 7:13 ` Chao Hao
(?)
(?)
@ 2020-06-29 10:29 ` Matthias Brugger
-1 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:29 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: Yong Wu, Evan Green, iommu, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, FY Yang
On 29/06/2020 09:13, Chao Hao wrote:
> 1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
> REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
> 2. Add mt6779_data to support mm_iommu HW init.
>
> Cc: Yong Wu <yong.wu@mediatek.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 11 +++++++++++
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index e46e2deee3fd..1575196d9cd5 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -37,6 +37,7 @@
> #define REG_MMU_INVLD_START_A 0x024
> #define REG_MMU_INVLD_END_A 0x028
>
> +#define REG_MMU_INV_SEL_GEN2 0x02c
> #define REG_MMU_INV_SEL_GEN1 0x038
> #define F_INVLD_EN0 BIT(0)
> #define F_INVLD_EN1 BIT(1)
> @@ -798,6 +799,15 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
> };
>
> +static const struct mtk_iommu_plat_data mt6779_data = {
> + .m4u_plat = M4U_MT6779,
> + .flags = HAS_SUB_COMM |
> + OUT_ORDER_EN |
> + WR_THROT_EN,
> + .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
> + .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
> +};
> +
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> .flags = HAS_4GB_MODE |
> @@ -816,6 +826,7 @@ static const struct mtk_iommu_plat_data mt8183_data = {
>
> 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,mt8173-m4u", .data = &mt8173_data},
> { .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
> {}
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index ce4f4e8f03aa..a080db2e8a93 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -43,6 +43,7 @@ struct mtk_iommu_suspend_reg {
> enum mtk_iommu_plat {
> M4U_MT2701,
> M4U_MT2712,
> + M4U_MT6779,
> M4U_MT8173,
> M4U_MT8183,
> };
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support
@ 2020-06-29 10:29 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:29 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> 1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
> REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
> 2. Add mt6779_data to support mm_iommu HW init.
>
> Cc: Yong Wu <yong.wu@mediatek.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 11 +++++++++++
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index e46e2deee3fd..1575196d9cd5 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -37,6 +37,7 @@
> #define REG_MMU_INVLD_START_A 0x024
> #define REG_MMU_INVLD_END_A 0x028
>
> +#define REG_MMU_INV_SEL_GEN2 0x02c
> #define REG_MMU_INV_SEL_GEN1 0x038
> #define F_INVLD_EN0 BIT(0)
> #define F_INVLD_EN1 BIT(1)
> @@ -798,6 +799,15 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
> };
>
> +static const struct mtk_iommu_plat_data mt6779_data = {
> + .m4u_plat = M4U_MT6779,
> + .flags = HAS_SUB_COMM |
> + OUT_ORDER_EN |
> + WR_THROT_EN,
> + .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
> + .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
> +};
> +
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> .flags = HAS_4GB_MODE |
> @@ -816,6 +826,7 @@ static const struct mtk_iommu_plat_data mt8183_data = {
>
> 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,mt8173-m4u", .data = &mt8173_data},
> { .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
> {}
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index ce4f4e8f03aa..a080db2e8a93 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -43,6 +43,7 @@ struct mtk_iommu_suspend_reg {
> enum mtk_iommu_plat {
> M4U_MT2701,
> M4U_MT2712,
> + M4U_MT6779,
> M4U_MT8173,
> M4U_MT8183,
> };
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support
@ 2020-06-29 10:29 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:29 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> 1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
> REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
> 2. Add mt6779_data to support mm_iommu HW init.
>
> Cc: Yong Wu <yong.wu@mediatek.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 11 +++++++++++
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index e46e2deee3fd..1575196d9cd5 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -37,6 +37,7 @@
> #define REG_MMU_INVLD_START_A 0x024
> #define REG_MMU_INVLD_END_A 0x028
>
> +#define REG_MMU_INV_SEL_GEN2 0x02c
> #define REG_MMU_INV_SEL_GEN1 0x038
> #define F_INVLD_EN0 BIT(0)
> #define F_INVLD_EN1 BIT(1)
> @@ -798,6 +799,15 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
> };
>
> +static const struct mtk_iommu_plat_data mt6779_data = {
> + .m4u_plat = M4U_MT6779,
> + .flags = HAS_SUB_COMM |
> + OUT_ORDER_EN |
> + WR_THROT_EN,
> + .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
> + .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
> +};
> +
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> .flags = HAS_4GB_MODE |
> @@ -816,6 +826,7 @@ static const struct mtk_iommu_plat_data mt8183_data = {
>
> 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,mt8173-m4u", .data = &mt8173_data},
> { .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
> {}
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index ce4f4e8f03aa..a080db2e8a93 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -43,6 +43,7 @@ struct mtk_iommu_suspend_reg {
> enum mtk_iommu_plat {
> M4U_MT2701,
> M4U_MT2712,
> + M4U_MT6779,
> M4U_MT8173,
> M4U_MT8183,
> };
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support
@ 2020-06-29 10:29 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-06-29 10:29 UTC (permalink / raw)
To: Chao Hao, Joerg Roedel, Rob Herring
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, linux-mediatek, Yong Wu, linux-arm-kernel
On 29/06/2020 09:13, Chao Hao wrote:
> 1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
> REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
> 2. Add mt6779_data to support mm_iommu HW init.
>
> Cc: Yong Wu <yong.wu@mediatek.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Reviewed by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 11 +++++++++++
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index e46e2deee3fd..1575196d9cd5 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -37,6 +37,7 @@
> #define REG_MMU_INVLD_START_A 0x024
> #define REG_MMU_INVLD_END_A 0x028
>
> +#define REG_MMU_INV_SEL_GEN2 0x02c
> #define REG_MMU_INV_SEL_GEN1 0x038
> #define F_INVLD_EN0 BIT(0)
> #define F_INVLD_EN1 BIT(1)
> @@ -798,6 +799,15 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
> };
>
> +static const struct mtk_iommu_plat_data mt6779_data = {
> + .m4u_plat = M4U_MT6779,
> + .flags = HAS_SUB_COMM |
> + OUT_ORDER_EN |
> + WR_THROT_EN,
> + .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
> + .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
> +};
> +
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> .flags = HAS_4GB_MODE |
> @@ -816,6 +826,7 @@ static const struct mtk_iommu_plat_data mt8183_data = {
>
> 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,mt8173-m4u", .data = &mt8173_data},
> { .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
> {}
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index ce4f4e8f03aa..a080db2e8a93 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -43,6 +43,7 @@ struct mtk_iommu_suspend_reg {
> enum mtk_iommu_plat {
> M4U_MT2701,
> M4U_MT2712,
> + M4U_MT6779,
> M4U_MT8173,
> M4U_MT8183,
> };
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
2020-06-29 9:28 ` Matthias Brugger
(?)
(?)
@ 2020-06-30 10:53 ` chao hao
-1 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 10:53 UTC (permalink / raw)
To: Matthias Brugger
Cc: Joerg Roedel, Rob Herring, Yong Wu, Evan Green, iommu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, FY Yang, Chao Hao
On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> > in MISC_CTRL register.
> > F_MMU_STANDARD_AXI_MODE_BIT:
> > If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> > standard AXI protocol), iommu will send urgent read command firstly
> > compare with normal read command to improve performance.
>
> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
> Does this mean that you will send a 'urgent read command' which is not described
> in the specifications instead of a normal read command?
ok.
iommu sends read command to next bus_node normally(we can name it to
cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
command is needed to be sent(we can name it to cmd2), iommu will send
cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
cmd2 will be handled secondly.
But for standard AXI protocol, it will ignore the priority of read
command and only be handled in order. So cmd2 is handled by next
bus_node after cmd1 is done.
>
> > F_MMU_IN_ORDER_WR_EN:
> > If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> > will re-order write command and send more higher priority write command
> > instead of sending write command in order. The feature be controlled
> > by OUT_ORDER_EN macro definition.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Suggested-by: Yong Wu <yong.wu@mediatek.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> > drivers/iommu/mtk_iommu.h | 1 +
> > 2 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 8f81df6cbe51..67b46b5d83d9 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -42,6 +42,9 @@
> > #define F_INVLD_EN1 BIT(1)
> >
> > #define REG_MMU_MISC_CTRL 0x048
> > +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> > +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>
> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
ok, you are right.
1'b1: follow standard axi protocol
>
> > +
> > #define REG_MMU_DCM_DIS 0x050
> >
> > #define REG_MMU_CTRL_REG 0x110
> > @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > }
> > writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> >
> > + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>
> We only need to read regval in the else branch.
ok, I got it. thanks
>
> > if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> > /* The register is called STANDARD_AXI_MODE in this case */
> > - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> > + regval = 0;
> > + } else {
> > + /* For mm_iommu, it can improve performance by the setting */
> > + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> > + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> > + regval &= ~F_MMU_IN_ORDER_WR_EN;
> > }
> > + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
> >
> > if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> > dev_name(data->dev), (void *)data)) {
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 7cc39f729263..4b780b651ef4 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -22,6 +22,7 @@
> > #define HAS_BCLK BIT(1)
> > #define HAS_VLD_PA_RNG BIT(2)
> > #define RESET_AXI BIT(3)
> > +#define OUT_ORDER_EN BIT(4)
>
> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
> write path.
>
ok, thanks for your advice.
> >
> > #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > ((((pdata)->flags) & (_x)) == (_x))
> >
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-06-30 10:53 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 10:53 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, Rob Herring, linux-mediatek, linux-arm-kernel
On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> > in MISC_CTRL register.
> > F_MMU_STANDARD_AXI_MODE_BIT:
> > If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> > standard AXI protocol), iommu will send urgent read command firstly
> > compare with normal read command to improve performance.
>
> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
> Does this mean that you will send a 'urgent read command' which is not described
> in the specifications instead of a normal read command?
ok.
iommu sends read command to next bus_node normally(we can name it to
cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
command is needed to be sent(we can name it to cmd2), iommu will send
cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
cmd2 will be handled secondly.
But for standard AXI protocol, it will ignore the priority of read
command and only be handled in order. So cmd2 is handled by next
bus_node after cmd1 is done.
>
> > F_MMU_IN_ORDER_WR_EN:
> > If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> > will re-order write command and send more higher priority write command
> > instead of sending write command in order. The feature be controlled
> > by OUT_ORDER_EN macro definition.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Suggested-by: Yong Wu <yong.wu@mediatek.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> > drivers/iommu/mtk_iommu.h | 1 +
> > 2 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 8f81df6cbe51..67b46b5d83d9 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -42,6 +42,9 @@
> > #define F_INVLD_EN1 BIT(1)
> >
> > #define REG_MMU_MISC_CTRL 0x048
> > +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> > +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>
> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
ok, you are right.
1'b1: follow standard axi protocol
>
> > +
> > #define REG_MMU_DCM_DIS 0x050
> >
> > #define REG_MMU_CTRL_REG 0x110
> > @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > }
> > writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> >
> > + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>
> We only need to read regval in the else branch.
ok, I got it. thanks
>
> > if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> > /* The register is called STANDARD_AXI_MODE in this case */
> > - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> > + regval = 0;
> > + } else {
> > + /* For mm_iommu, it can improve performance by the setting */
> > + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> > + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> > + regval &= ~F_MMU_IN_ORDER_WR_EN;
> > }
> > + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
> >
> > if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> > dev_name(data->dev), (void *)data)) {
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 7cc39f729263..4b780b651ef4 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -22,6 +22,7 @@
> > #define HAS_BCLK BIT(1)
> > #define HAS_VLD_PA_RNG BIT(2)
> > #define RESET_AXI BIT(3)
> > +#define OUT_ORDER_EN BIT(4)
>
> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
> write path.
>
ok, thanks for your advice.
> >
> > #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > ((((pdata)->flags) & (_x)) == (_x))
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-06-30 10:53 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 10:53 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
linux-arm-kernel, Yong Wu
On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> > in MISC_CTRL register.
> > F_MMU_STANDARD_AXI_MODE_BIT:
> > If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> > standard AXI protocol), iommu will send urgent read command firstly
> > compare with normal read command to improve performance.
>
> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
> Does this mean that you will send a 'urgent read command' which is not described
> in the specifications instead of a normal read command?
ok.
iommu sends read command to next bus_node normally(we can name it to
cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
command is needed to be sent(we can name it to cmd2), iommu will send
cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
cmd2 will be handled secondly.
But for standard AXI protocol, it will ignore the priority of read
command and only be handled in order. So cmd2 is handled by next
bus_node after cmd1 is done.
>
> > F_MMU_IN_ORDER_WR_EN:
> > If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> > will re-order write command and send more higher priority write command
> > instead of sending write command in order. The feature be controlled
> > by OUT_ORDER_EN macro definition.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Suggested-by: Yong Wu <yong.wu@mediatek.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> > drivers/iommu/mtk_iommu.h | 1 +
> > 2 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 8f81df6cbe51..67b46b5d83d9 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -42,6 +42,9 @@
> > #define F_INVLD_EN1 BIT(1)
> >
> > #define REG_MMU_MISC_CTRL 0x048
> > +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> > +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>
> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
ok, you are right.
1'b1: follow standard axi protocol
>
> > +
> > #define REG_MMU_DCM_DIS 0x050
> >
> > #define REG_MMU_CTRL_REG 0x110
> > @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > }
> > writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> >
> > + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>
> We only need to read regval in the else branch.
ok, I got it. thanks
>
> > if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> > /* The register is called STANDARD_AXI_MODE in this case */
> > - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> > + regval = 0;
> > + } else {
> > + /* For mm_iommu, it can improve performance by the setting */
> > + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> > + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> > + regval &= ~F_MMU_IN_ORDER_WR_EN;
> > }
> > + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
> >
> > if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> > dev_name(data->dev), (void *)data)) {
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 7cc39f729263..4b780b651ef4 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -22,6 +22,7 @@
> > #define HAS_BCLK BIT(1)
> > #define HAS_VLD_PA_RNG BIT(2)
> > #define RESET_AXI BIT(3)
> > +#define OUT_ORDER_EN BIT(4)
>
> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
> write path.
>
ok, thanks for your advice.
> >
> > #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > ((((pdata)->flags) & (_x)) == (_x))
> >
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-06-30 10:53 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 10:53 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
linux-arm-kernel, Yong Wu
On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> > in MISC_CTRL register.
> > F_MMU_STANDARD_AXI_MODE_BIT:
> > If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> > standard AXI protocol), iommu will send urgent read command firstly
> > compare with normal read command to improve performance.
>
> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
> Does this mean that you will send a 'urgent read command' which is not described
> in the specifications instead of a normal read command?
ok.
iommu sends read command to next bus_node normally(we can name it to
cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
command is needed to be sent(we can name it to cmd2), iommu will send
cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
cmd2 will be handled secondly.
But for standard AXI protocol, it will ignore the priority of read
command and only be handled in order. So cmd2 is handled by next
bus_node after cmd1 is done.
>
> > F_MMU_IN_ORDER_WR_EN:
> > If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> > will re-order write command and send more higher priority write command
> > instead of sending write command in order. The feature be controlled
> > by OUT_ORDER_EN macro definition.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Suggested-by: Yong Wu <yong.wu@mediatek.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> > drivers/iommu/mtk_iommu.h | 1 +
> > 2 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 8f81df6cbe51..67b46b5d83d9 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -42,6 +42,9 @@
> > #define F_INVLD_EN1 BIT(1)
> >
> > #define REG_MMU_MISC_CTRL 0x048
> > +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> > +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>
> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
ok, you are right.
1'b1: follow standard axi protocol
>
> > +
> > #define REG_MMU_DCM_DIS 0x050
> >
> > #define REG_MMU_CTRL_REG 0x110
> > @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > }
> > writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> >
> > + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>
> We only need to read regval in the else branch.
ok, I got it. thanks
>
> > if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> > /* The register is called STANDARD_AXI_MODE in this case */
> > - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> > + regval = 0;
> > + } else {
> > + /* For mm_iommu, it can improve performance by the setting */
> > + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> > + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> > + regval &= ~F_MMU_IN_ORDER_WR_EN;
> > }
> > + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
> >
> > if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> > dev_name(data->dev), (void *)data)) {
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 7cc39f729263..4b780b651ef4 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -22,6 +22,7 @@
> > #define HAS_BCLK BIT(1)
> > #define HAS_VLD_PA_RNG BIT(2)
> > #define RESET_AXI BIT(3)
> > +#define OUT_ORDER_EN BIT(4)
>
> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
> write path.
>
ok, thanks for your advice.
> >
> > #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > ((((pdata)->flags) & (_x)) == (_x))
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
2020-06-29 7:13 ` Chao Hao
(?)
(?)
@ 2020-06-30 10:55 ` Yong Wu
-1 siblings, 0 replies; 101+ messages in thread
From: Yong Wu @ 2020-06-30 10:55 UTC (permalink / raw)
To: Chao Hao
Cc: Joerg Roedel, Rob Herring, Matthias Brugger, Evan Green, iommu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, FY Yang
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> diagram).
> If the larb's number is over 8, we use a sub_common for merging
> several larbs into one larb. At this case, we will extend larb_id:
> bit[11:9] means common-id;
> bit[8:7] means subcommon-id;
> From these two variables, we could get the real larb number when
> translation fault happen.
> The diagram is as below:
> EMI
> |
> IOMMU
> |
> -----------------
> | |
> common1 common0
> | |
> -----------------
> |
> smi common
> |
> ------------------------------------
> | | | | | |
> 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> | | | | | |
> Larb0 Larb1 | Larb3 ... Larb7
> |
> smi sub common
> |
> --------------------------
> | | | |
> 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> | | | |
> Larb8 Larb9 Larb10 Larb11
>
> In this patch we extend larb_remap[] to larb_remap[8][4] for this.
> larb_remap[x][y]: x means common-id above, y means subcommon_id above.
>
> We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
> macro.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> drivers/iommu/mtk_iommu.h | 3 ++-
> include/soc/mediatek/smi.h | 2 ++
> 3 files changed, 17 insertions(+), 8 deletions(-)
[snip]
> @@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> u32 flags;
> u32 inv_sel_reg;
> - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> + unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
> };
>
> struct mtk_iommu_domain;
> diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> index 5a34b87d89e3..fa65a55468e2 100644
> --- a/include/soc/mediatek/smi.h
> +++ b/include/soc/mediatek/smi.h
> @@ -12,6 +12,8 @@
> #ifdef CONFIG_MTK_SMI
>
> #define MTK_LARB_NR_MAX 16
> +#define MTK_LARB_COM_MAX 8
> +#define MTK_LARB_SUBCOM_MAX 4
Both are only used in mtk_iommu.h, and I don't think smi has plan to use
them. thus we could move them into mtk_iommu.h
>
> #define MTK_SMI_MMU_EN(port) BIT(port)
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
@ 2020-06-30 10:55 ` Yong Wu
0 siblings, 0 replies; 101+ messages in thread
From: Yong Wu @ 2020-06-30 10:55 UTC (permalink / raw)
To: Chao Hao
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> diagram).
> If the larb's number is over 8, we use a sub_common for merging
> several larbs into one larb. At this case, we will extend larb_id:
> bit[11:9] means common-id;
> bit[8:7] means subcommon-id;
> From these two variables, we could get the real larb number when
> translation fault happen.
> The diagram is as below:
> EMI
> |
> IOMMU
> |
> -----------------
> | |
> common1 common0
> | |
> -----------------
> |
> smi common
> |
> ------------------------------------
> | | | | | |
> 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> | | | | | |
> Larb0 Larb1 | Larb3 ... Larb7
> |
> smi sub common
> |
> --------------------------
> | | | |
> 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> | | | |
> Larb8 Larb9 Larb10 Larb11
>
> In this patch we extend larb_remap[] to larb_remap[8][4] for this.
> larb_remap[x][y]: x means common-id above, y means subcommon_id above.
>
> We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
> macro.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> drivers/iommu/mtk_iommu.h | 3 ++-
> include/soc/mediatek/smi.h | 2 ++
> 3 files changed, 17 insertions(+), 8 deletions(-)
[snip]
> @@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> u32 flags;
> u32 inv_sel_reg;
> - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> + unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
> };
>
> struct mtk_iommu_domain;
> diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> index 5a34b87d89e3..fa65a55468e2 100644
> --- a/include/soc/mediatek/smi.h
> +++ b/include/soc/mediatek/smi.h
> @@ -12,6 +12,8 @@
> #ifdef CONFIG_MTK_SMI
>
> #define MTK_LARB_NR_MAX 16
> +#define MTK_LARB_COM_MAX 8
> +#define MTK_LARB_SUBCOM_MAX 4
Both are only used in mtk_iommu.h, and I don't think smi has plan to use
them. thus we could move them into mtk_iommu.h
>
> #define MTK_SMI_MMU_EN(port) BIT(port)
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
@ 2020-06-30 10:55 ` Yong Wu
0 siblings, 0 replies; 101+ messages in thread
From: Yong Wu @ 2020-06-30 10:55 UTC (permalink / raw)
To: Chao Hao
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> diagram).
> If the larb's number is over 8, we use a sub_common for merging
> several larbs into one larb. At this case, we will extend larb_id:
> bit[11:9] means common-id;
> bit[8:7] means subcommon-id;
> From these two variables, we could get the real larb number when
> translation fault happen.
> The diagram is as below:
> EMI
> |
> IOMMU
> |
> -----------------
> | |
> common1 common0
> | |
> -----------------
> |
> smi common
> |
> ------------------------------------
> | | | | | |
> 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> | | | | | |
> Larb0 Larb1 | Larb3 ... Larb7
> |
> smi sub common
> |
> --------------------------
> | | | |
> 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> | | | |
> Larb8 Larb9 Larb10 Larb11
>
> In this patch we extend larb_remap[] to larb_remap[8][4] for this.
> larb_remap[x][y]: x means common-id above, y means subcommon_id above.
>
> We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
> macro.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> drivers/iommu/mtk_iommu.h | 3 ++-
> include/soc/mediatek/smi.h | 2 ++
> 3 files changed, 17 insertions(+), 8 deletions(-)
[snip]
> @@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> u32 flags;
> u32 inv_sel_reg;
> - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> + unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
> };
>
> struct mtk_iommu_domain;
> diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> index 5a34b87d89e3..fa65a55468e2 100644
> --- a/include/soc/mediatek/smi.h
> +++ b/include/soc/mediatek/smi.h
> @@ -12,6 +12,8 @@
> #ifdef CONFIG_MTK_SMI
>
> #define MTK_LARB_NR_MAX 16
> +#define MTK_LARB_COM_MAX 8
> +#define MTK_LARB_SUBCOM_MAX 4
Both are only used in mtk_iommu.h, and I don't think smi has plan to use
them. thus we could move them into mtk_iommu.h
>
> #define MTK_SMI_MMU_EN(port) BIT(port)
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
@ 2020-06-30 10:55 ` Yong Wu
0 siblings, 0 replies; 101+ messages in thread
From: Yong Wu @ 2020-06-30 10:55 UTC (permalink / raw)
To: Chao Hao
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> diagram).
> If the larb's number is over 8, we use a sub_common for merging
> several larbs into one larb. At this case, we will extend larb_id:
> bit[11:9] means common-id;
> bit[8:7] means subcommon-id;
> From these two variables, we could get the real larb number when
> translation fault happen.
> The diagram is as below:
> EMI
> |
> IOMMU
> |
> -----------------
> | |
> common1 common0
> | |
> -----------------
> |
> smi common
> |
> ------------------------------------
> | | | | | |
> 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> | | | | | |
> Larb0 Larb1 | Larb3 ... Larb7
> |
> smi sub common
> |
> --------------------------
> | | | |
> 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> | | | |
> Larb8 Larb9 Larb10 Larb11
>
> In this patch we extend larb_remap[] to larb_remap[8][4] for this.
> larb_remap[x][y]: x means common-id above, y means subcommon_id above.
>
> We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
> macro.
>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> drivers/iommu/mtk_iommu.h | 3 ++-
> include/soc/mediatek/smi.h | 2 ++
> 3 files changed, 17 insertions(+), 8 deletions(-)
[snip]
> @@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> u32 flags;
> u32 inv_sel_reg;
> - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> + unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
> };
>
> struct mtk_iommu_domain;
> diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> index 5a34b87d89e3..fa65a55468e2 100644
> --- a/include/soc/mediatek/smi.h
> +++ b/include/soc/mediatek/smi.h
> @@ -12,6 +12,8 @@
> #ifdef CONFIG_MTK_SMI
>
> #define MTK_LARB_NR_MAX 16
> +#define MTK_LARB_COM_MAX 8
> +#define MTK_LARB_SUBCOM_MAX 4
Both are only used in mtk_iommu.h, and I don't think smi has plan to use
them. thus we could move them into mtk_iommu.h
>
> #define MTK_SMI_MMU_EN(port) BIT(port)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
2020-06-29 7:13 ` Chao Hao
(?)
(?)
@ 2020-06-30 10:56 ` Yong Wu
-1 siblings, 0 replies; 101+ messages in thread
From: Yong Wu @ 2020-06-30 10:56 UTC (permalink / raw)
To: Chao Hao
Cc: Joerg Roedel, Rob Herring, Matthias Brugger, Evan Green, iommu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, FY Yang
Hi Chao,
This is also ok for me. Only two format nitpick.
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for a flag present.
> No functional change.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
[snip]
> static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .has_vld_pa_rng = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + HAS_VLD_PA_RNG,
short enough. we can put it in one line?
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .reset_axi = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + RESET_AXI,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> static const struct mtk_iommu_plat_data mt8183_data = {
> .m4u_plat = M4U_MT8183,
> - .reset_axi = true,
> + .flags = RESET_AXI,
> .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 1b6ea839b92c..7cc39f729263 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -17,6 +17,15 @@
> #include <linux/spinlock.h>
> #include <soc/mediatek/smi.h>
>
> +#define HAS_4GB_MODE BIT(0)
> +/* HW will use the EMI clock if there isn't the "bclk". */
> +#define HAS_BCLK BIT(1)
> +#define HAS_VLD_PA_RNG BIT(2)
> +#define RESET_AXI BIT(3)
> +
> +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> + ((((pdata)->flags) & (_x)) == (_x))
If these definitions are not used in mtk_iommu_v1.c(also no this plan),
then we can put them in the mtk_iommu.c.
BTW, the patch title "modify the usage of mtk_iommu_plat_data structure"
isn't so clear, we could write what the detailed modification is.
something like:
iommu/mediatek: Use a u32 flags to describe different HW features
> +
> struct mtk_iommu_suspend_reg {
> u32 misc_ctrl;
> u32 dcm_dis;
> @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
>
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> - bool has_4gb_mode;
> -
> - /* HW will use the EMI clock if there isn't the "bclk". */
> - bool has_bclk;
> - bool has_vld_pa_rng;
> - bool reset_axi;
> + u32 flags;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-30 10:56 ` Yong Wu
0 siblings, 0 replies; 101+ messages in thread
From: Yong Wu @ 2020-06-30 10:56 UTC (permalink / raw)
To: Chao Hao
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
Hi Chao,
This is also ok for me. Only two format nitpick.
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for a flag present.
> No functional change.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
[snip]
> static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .has_vld_pa_rng = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + HAS_VLD_PA_RNG,
short enough. we can put it in one line?
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .reset_axi = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + RESET_AXI,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> static const struct mtk_iommu_plat_data mt8183_data = {
> .m4u_plat = M4U_MT8183,
> - .reset_axi = true,
> + .flags = RESET_AXI,
> .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 1b6ea839b92c..7cc39f729263 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -17,6 +17,15 @@
> #include <linux/spinlock.h>
> #include <soc/mediatek/smi.h>
>
> +#define HAS_4GB_MODE BIT(0)
> +/* HW will use the EMI clock if there isn't the "bclk". */
> +#define HAS_BCLK BIT(1)
> +#define HAS_VLD_PA_RNG BIT(2)
> +#define RESET_AXI BIT(3)
> +
> +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> + ((((pdata)->flags) & (_x)) == (_x))
If these definitions are not used in mtk_iommu_v1.c(also no this plan),
then we can put them in the mtk_iommu.c.
BTW, the patch title "modify the usage of mtk_iommu_plat_data structure"
isn't so clear, we could write what the detailed modification is.
something like:
iommu/mediatek: Use a u32 flags to describe different HW features
> +
> struct mtk_iommu_suspend_reg {
> u32 misc_ctrl;
> u32 dcm_dis;
> @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
>
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> - bool has_4gb_mode;
> -
> - /* HW will use the EMI clock if there isn't the "bclk". */
> - bool has_bclk;
> - bool has_vld_pa_rng;
> - bool reset_axi;
> + u32 flags;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-30 10:56 ` Yong Wu
0 siblings, 0 replies; 101+ messages in thread
From: Yong Wu @ 2020-06-30 10:56 UTC (permalink / raw)
To: Chao Hao
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
Hi Chao,
This is also ok for me. Only two format nitpick.
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for a flag present.
> No functional change.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
[snip]
> static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .has_vld_pa_rng = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + HAS_VLD_PA_RNG,
short enough. we can put it in one line?
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .reset_axi = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + RESET_AXI,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> static const struct mtk_iommu_plat_data mt8183_data = {
> .m4u_plat = M4U_MT8183,
> - .reset_axi = true,
> + .flags = RESET_AXI,
> .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 1b6ea839b92c..7cc39f729263 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -17,6 +17,15 @@
> #include <linux/spinlock.h>
> #include <soc/mediatek/smi.h>
>
> +#define HAS_4GB_MODE BIT(0)
> +/* HW will use the EMI clock if there isn't the "bclk". */
> +#define HAS_BCLK BIT(1)
> +#define HAS_VLD_PA_RNG BIT(2)
> +#define RESET_AXI BIT(3)
> +
> +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> + ((((pdata)->flags) & (_x)) == (_x))
If these definitions are not used in mtk_iommu_v1.c(also no this plan),
then we can put them in the mtk_iommu.c.
BTW, the patch title "modify the usage of mtk_iommu_plat_data structure"
isn't so clear, we could write what the detailed modification is.
something like:
iommu/mediatek: Use a u32 flags to describe different HW features
> +
> struct mtk_iommu_suspend_reg {
> u32 misc_ctrl;
> u32 dcm_dis;
> @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
>
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> - bool has_4gb_mode;
> -
> - /* HW will use the EMI clock if there isn't the "bclk". */
> - bool has_bclk;
> - bool has_vld_pa_rng;
> - bool reset_axi;
> + u32 flags;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-30 10:56 ` Yong Wu
0 siblings, 0 replies; 101+ messages in thread
From: Yong Wu @ 2020-06-30 10:56 UTC (permalink / raw)
To: Chao Hao
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
Hi Chao,
This is also ok for me. Only two format nitpick.
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for a flag present.
> No functional change.
>
> Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
[snip]
> static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .has_vld_pa_rng = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + HAS_VLD_PA_RNG,
short enough. we can put it in one line?
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> - .has_4gb_mode = true,
> - .has_bclk = true,
> - .reset_axi = true,
> + .flags = HAS_4GB_MODE |
> + HAS_BCLK |
> + RESET_AXI,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> static const struct mtk_iommu_plat_data mt8183_data = {
> .m4u_plat = M4U_MT8183,
> - .reset_axi = true,
> + .flags = RESET_AXI,
> .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 1b6ea839b92c..7cc39f729263 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -17,6 +17,15 @@
> #include <linux/spinlock.h>
> #include <soc/mediatek/smi.h>
>
> +#define HAS_4GB_MODE BIT(0)
> +/* HW will use the EMI clock if there isn't the "bclk". */
> +#define HAS_BCLK BIT(1)
> +#define HAS_VLD_PA_RNG BIT(2)
> +#define RESET_AXI BIT(3)
> +
> +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> + ((((pdata)->flags) & (_x)) == (_x))
If these definitions are not used in mtk_iommu_v1.c(also no this plan),
then we can put them in the mtk_iommu.c.
BTW, the patch title "modify the usage of mtk_iommu_plat_data structure"
isn't so clear, we could write what the detailed modification is.
something like:
iommu/mediatek: Use a u32 flags to describe different HW features
> +
> struct mtk_iommu_suspend_reg {
> u32 misc_ctrl;
> u32 dcm_dis;
> @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
>
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> - bool has_4gb_mode;
> -
> - /* HW will use the EMI clock if there isn't the "bclk". */
> - bool has_bclk;
> - bool has_vld_pa_rng;
> - bool reset_axi;
> + u32 flags;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
2020-06-29 10:16 ` Matthias Brugger
(?)
(?)
@ 2020-06-30 10:59 ` chao hao
-1 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 10:59 UTC (permalink / raw)
To: Matthias Brugger
Cc: Joerg Roedel, Rob Herring, Yong Wu, Evan Green, iommu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, FY Yang, Chao Hao
On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Some platforms(ex: mt6779) need to improve performance by setting
> > REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> > whether we need to set the register. If the register uses default value,
> > iommu will send command to EMI without restriction, when the number of
> > commands become more and more, it will drop the EMI performance. So when
> > more than ten_commands(default value) don't be handled for EMI, iommu will
> > stop send command to EMI for keeping EMI's performace by enabling write
> > throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 10 ++++++++++
> > drivers/iommu/mtk_iommu.h | 2 ++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index ec1f86913739..92316c4175a9 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -46,6 +46,8 @@
> > #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
> >
> > #define REG_MMU_DCM_DIS 0x050
> > +#define REG_MMU_WR_LEN 0x054
>
> The register name is confusing. For me it seems to describe the length of a
> write but it is used for controlling the write throttling. Is this the name
> that's used in the datasheet?
>
Thanks for your review carefully, we can name it to REG_MMU_WR_LEN_CTRL
> > +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
>
> There are two spaces between '|' and 'BIT(21)', should be one.
>
> Regarding the name of the define, what does the 'F_' statnds for?
F_ is used to described some bits in register and doesn't have other
meanings. The format is refer to other bits definition
> Also I think
> it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
>
Thanks for your advice.
For F_MMU_WR_THROT_DIS_BIT:
1'b0: Enable write throttling mechanism
1'b1: Disable write throttling mechanism
So I think we can name "F_MMU_WR_THROT_DIS BIT(5) | BIT(21)" directly,
it maybe more clearer.
> Regards,
> Matthias
>
> >
> > #define REG_MMU_CTRL_REG 0x110
> > #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
> > @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
> > }
> > writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> > + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
> > + /* write command throttling mode */
> > + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
> > + regval &= ~F_MMU_WR_THROT_DIS_BIT;
> > + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
> > + }
> >
> > regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> > if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> > @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> > struct mtk_iommu_suspend_reg *reg = &data->reg;
> > void __iomem *base = data->base;
> >
> > + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
> > reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
> > reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
> > reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
> > @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
> > dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
> > return ret;
> > }
> > + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
> > writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
> > writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
> > writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index be6d32ee5bda..ce4f4e8f03aa 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -24,6 +24,7 @@
> > #define RESET_AXI BIT(3)
> > #define OUT_ORDER_EN BIT(4)
> > #define HAS_SUB_COMM BIT(5)
> > +#define WR_THROT_EN BIT(6)
> >
> > #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > ((((pdata)->flags) & (_x)) == (_x))
> > @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
> > u32 int_main_control;
> > u32 ivrp_paddr;
> > u32 vld_pa_rng;
> > + u32 wr_len;
> > };
> >
> > enum mtk_iommu_plat {
> >
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-06-30 10:59 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 10:59 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, Rob Herring, linux-mediatek, linux-arm-kernel
On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Some platforms(ex: mt6779) need to improve performance by setting
> > REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> > whether we need to set the register. If the register uses default value,
> > iommu will send command to EMI without restriction, when the number of
> > commands become more and more, it will drop the EMI performance. So when
> > more than ten_commands(default value) don't be handled for EMI, iommu will
> > stop send command to EMI for keeping EMI's performace by enabling write
> > throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 10 ++++++++++
> > drivers/iommu/mtk_iommu.h | 2 ++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index ec1f86913739..92316c4175a9 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -46,6 +46,8 @@
> > #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
> >
> > #define REG_MMU_DCM_DIS 0x050
> > +#define REG_MMU_WR_LEN 0x054
>
> The register name is confusing. For me it seems to describe the length of a
> write but it is used for controlling the write throttling. Is this the name
> that's used in the datasheet?
>
Thanks for your review carefully, we can name it to REG_MMU_WR_LEN_CTRL
> > +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
>
> There are two spaces between '|' and 'BIT(21)', should be one.
>
> Regarding the name of the define, what does the 'F_' statnds for?
F_ is used to described some bits in register and doesn't have other
meanings. The format is refer to other bits definition
> Also I think
> it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
>
Thanks for your advice.
For F_MMU_WR_THROT_DIS_BIT:
1'b0: Enable write throttling mechanism
1'b1: Disable write throttling mechanism
So I think we can name "F_MMU_WR_THROT_DIS BIT(5) | BIT(21)" directly,
it maybe more clearer.
> Regards,
> Matthias
>
> >
> > #define REG_MMU_CTRL_REG 0x110
> > #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
> > @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
> > }
> > writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> > + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
> > + /* write command throttling mode */
> > + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
> > + regval &= ~F_MMU_WR_THROT_DIS_BIT;
> > + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
> > + }
> >
> > regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> > if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> > @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> > struct mtk_iommu_suspend_reg *reg = &data->reg;
> > void __iomem *base = data->base;
> >
> > + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
> > reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
> > reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
> > reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
> > @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
> > dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
> > return ret;
> > }
> > + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
> > writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
> > writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
> > writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index be6d32ee5bda..ce4f4e8f03aa 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -24,6 +24,7 @@
> > #define RESET_AXI BIT(3)
> > #define OUT_ORDER_EN BIT(4)
> > #define HAS_SUB_COMM BIT(5)
> > +#define WR_THROT_EN BIT(6)
> >
> > #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > ((((pdata)->flags) & (_x)) == (_x))
> > @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
> > u32 int_main_control;
> > u32 ivrp_paddr;
> > u32 vld_pa_rng;
> > + u32 wr_len;
> > };
> >
> > enum mtk_iommu_plat {
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-06-30 10:59 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 10:59 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
linux-arm-kernel, Yong Wu
On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Some platforms(ex: mt6779) need to improve performance by setting
> > REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> > whether we need to set the register. If the register uses default value,
> > iommu will send command to EMI without restriction, when the number of
> > commands become more and more, it will drop the EMI performance. So when
> > more than ten_commands(default value) don't be handled for EMI, iommu will
> > stop send command to EMI for keeping EMI's performace by enabling write
> > throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 10 ++++++++++
> > drivers/iommu/mtk_iommu.h | 2 ++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index ec1f86913739..92316c4175a9 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -46,6 +46,8 @@
> > #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
> >
> > #define REG_MMU_DCM_DIS 0x050
> > +#define REG_MMU_WR_LEN 0x054
>
> The register name is confusing. For me it seems to describe the length of a
> write but it is used for controlling the write throttling. Is this the name
> that's used in the datasheet?
>
Thanks for your review carefully, we can name it to REG_MMU_WR_LEN_CTRL
> > +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
>
> There are two spaces between '|' and 'BIT(21)', should be one.
>
> Regarding the name of the define, what does the 'F_' statnds for?
F_ is used to described some bits in register and doesn't have other
meanings. The format is refer to other bits definition
> Also I think
> it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
>
Thanks for your advice.
For F_MMU_WR_THROT_DIS_BIT:
1'b0: Enable write throttling mechanism
1'b1: Disable write throttling mechanism
So I think we can name "F_MMU_WR_THROT_DIS BIT(5) | BIT(21)" directly,
it maybe more clearer.
> Regards,
> Matthias
>
> >
> > #define REG_MMU_CTRL_REG 0x110
> > #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
> > @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
> > }
> > writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> > + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
> > + /* write command throttling mode */
> > + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
> > + regval &= ~F_MMU_WR_THROT_DIS_BIT;
> > + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
> > + }
> >
> > regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> > if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> > @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> > struct mtk_iommu_suspend_reg *reg = &data->reg;
> > void __iomem *base = data->base;
> >
> > + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
> > reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
> > reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
> > reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
> > @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
> > dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
> > return ret;
> > }
> > + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
> > writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
> > writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
> > writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index be6d32ee5bda..ce4f4e8f03aa 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -24,6 +24,7 @@
> > #define RESET_AXI BIT(3)
> > #define OUT_ORDER_EN BIT(4)
> > #define HAS_SUB_COMM BIT(5)
> > +#define WR_THROT_EN BIT(6)
> >
> > #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > ((((pdata)->flags) & (_x)) == (_x))
> > @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
> > u32 int_main_control;
> > u32 ivrp_paddr;
> > u32 vld_pa_rng;
> > + u32 wr_len;
> > };
> >
> > enum mtk_iommu_plat {
> >
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-06-30 10:59 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 10:59 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
linux-arm-kernel, Yong Wu
On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Some platforms(ex: mt6779) need to improve performance by setting
> > REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> > whether we need to set the register. If the register uses default value,
> > iommu will send command to EMI without restriction, when the number of
> > commands become more and more, it will drop the EMI performance. So when
> > more than ten_commands(default value) don't be handled for EMI, iommu will
> > stop send command to EMI for keeping EMI's performace by enabling write
> > throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 10 ++++++++++
> > drivers/iommu/mtk_iommu.h | 2 ++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index ec1f86913739..92316c4175a9 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -46,6 +46,8 @@
> > #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
> >
> > #define REG_MMU_DCM_DIS 0x050
> > +#define REG_MMU_WR_LEN 0x054
>
> The register name is confusing. For me it seems to describe the length of a
> write but it is used for controlling the write throttling. Is this the name
> that's used in the datasheet?
>
Thanks for your review carefully, we can name it to REG_MMU_WR_LEN_CTRL
> > +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
>
> There are two spaces between '|' and 'BIT(21)', should be one.
>
> Regarding the name of the define, what does the 'F_' statnds for?
F_ is used to described some bits in register and doesn't have other
meanings. The format is refer to other bits definition
> Also I think
> it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
>
Thanks for your advice.
For F_MMU_WR_THROT_DIS_BIT:
1'b0: Enable write throttling mechanism
1'b1: Disable write throttling mechanism
So I think we can name "F_MMU_WR_THROT_DIS BIT(5) | BIT(21)" directly,
it maybe more clearer.
> Regards,
> Matthias
>
> >
> > #define REG_MMU_CTRL_REG 0x110
> > #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
> > @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
> > }
> > writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> > + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
> > + /* write command throttling mode */
> > + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
> > + regval &= ~F_MMU_WR_THROT_DIS_BIT;
> > + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
> > + }
> >
> > regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> > if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> > @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
> > struct mtk_iommu_suspend_reg *reg = &data->reg;
> > void __iomem *base = data->base;
> >
> > + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
> > reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
> > reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
> > reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
> > @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
> > dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
> > return ret;
> > }
> > + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
> > writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
> > writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
> > writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index be6d32ee5bda..ce4f4e8f03aa 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -24,6 +24,7 @@
> > #define RESET_AXI BIT(3)
> > #define OUT_ORDER_EN BIT(4)
> > #define HAS_SUB_COMM BIT(5)
> > +#define WR_THROT_EN BIT(6)
> >
> > #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > ((((pdata)->flags) & (_x)) == (_x))
> > @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
> > u32 int_main_control;
> > u32 ivrp_paddr;
> > u32 vld_pa_rng;
> > + u32 wr_len;
> > };
> >
> > enum mtk_iommu_plat {
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
2020-06-29 10:28 ` Matthias Brugger
(?)
(?)
@ 2020-06-30 11:02 ` chao hao
-1 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:02 UTC (permalink / raw)
To: Matthias Brugger
Cc: Joerg Roedel, Rob Herring, Yong Wu, Evan Green, iommu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, FY Yang, Chao Hao
On Mon, 2020-06-29 at 12:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > MT8173 is different from other SoCs for MMU_CTRL register.
> > For mt8173, its bit9 is in_order_write_en and doesn't use its
> > default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en feature and
> > victim_tlb is enable defaultly(bit[12]=1), if we use
> > "regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
> > disabled, it will drop iommu performace.
> > So we need to deal with the setting of MMU_CTRL separately
> > for mt8173 and others.
> >
>
> My proposal to rewrite the commit message:
>
> The MMU_CTRL regiser of MT8173 is different from other SoCs. The in_order_wr_en
> is bit[9] which is zero by default.
> Other SoCs have the vitcim_tlb_en feature mapped to bit[12]. This bit is set to
> one by default. We need to preserve the bit when setting
> F_MMU_TF_PROT_TO_PROGRAM_ADDR as otherwise the bit will be cleared and IOMMU
> performance will drop.
got it, thanks for your advice very much.
>
>
> > Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> > Suggested-by: Yong Wu <yong.wu@mediatek.com>
> > Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > return ret;
> > }
> >
> > + regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
>
> The read is only needed in the else branch.
>
ok, thanks
> > if (data->plat_data->m4u_plat == M4U_MT8173)
> > regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> > F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
> > else
> > - regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> > + regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> > writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
> >
> > regval = F_L2_MULIT_HIT_EN |
> >
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
@ 2020-06-30 11:02 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:02 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, Rob Herring, linux-mediatek, linux-arm-kernel
On Mon, 2020-06-29 at 12:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > MT8173 is different from other SoCs for MMU_CTRL register.
> > For mt8173, its bit9 is in_order_write_en and doesn't use its
> > default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en feature and
> > victim_tlb is enable defaultly(bit[12]=1), if we use
> > "regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
> > disabled, it will drop iommu performace.
> > So we need to deal with the setting of MMU_CTRL separately
> > for mt8173 and others.
> >
>
> My proposal to rewrite the commit message:
>
> The MMU_CTRL regiser of MT8173 is different from other SoCs. The in_order_wr_en
> is bit[9] which is zero by default.
> Other SoCs have the vitcim_tlb_en feature mapped to bit[12]. This bit is set to
> one by default. We need to preserve the bit when setting
> F_MMU_TF_PROT_TO_PROGRAM_ADDR as otherwise the bit will be cleared and IOMMU
> performance will drop.
got it, thanks for your advice very much.
>
>
> > Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> > Suggested-by: Yong Wu <yong.wu@mediatek.com>
> > Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > return ret;
> > }
> >
> > + regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
>
> The read is only needed in the else branch.
>
ok, thanks
> > if (data->plat_data->m4u_plat == M4U_MT8173)
> > regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> > F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
> > else
> > - regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> > + regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> > writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
> >
> > regval = F_L2_MULIT_HIT_EN |
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
@ 2020-06-30 11:02 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:02 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
linux-arm-kernel, Yong Wu
On Mon, 2020-06-29 at 12:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > MT8173 is different from other SoCs for MMU_CTRL register.
> > For mt8173, its bit9 is in_order_write_en and doesn't use its
> > default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en feature and
> > victim_tlb is enable defaultly(bit[12]=1), if we use
> > "regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
> > disabled, it will drop iommu performace.
> > So we need to deal with the setting of MMU_CTRL separately
> > for mt8173 and others.
> >
>
> My proposal to rewrite the commit message:
>
> The MMU_CTRL regiser of MT8173 is different from other SoCs. The in_order_wr_en
> is bit[9] which is zero by default.
> Other SoCs have the vitcim_tlb_en feature mapped to bit[12]. This bit is set to
> one by default. We need to preserve the bit when setting
> F_MMU_TF_PROT_TO_PROGRAM_ADDR as otherwise the bit will be cleared and IOMMU
> performance will drop.
got it, thanks for your advice very much.
>
>
> > Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> > Suggested-by: Yong Wu <yong.wu@mediatek.com>
> > Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > return ret;
> > }
> >
> > + regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
>
> The read is only needed in the else branch.
>
ok, thanks
> > if (data->plat_data->m4u_plat == M4U_MT8173)
> > regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> > F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
> > else
> > - regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> > + regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> > writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
> >
> > regval = F_L2_MULIT_HIT_EN |
> >
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
@ 2020-06-30 11:02 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:02 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
linux-arm-kernel, Yong Wu
On Mon, 2020-06-29 at 12:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > MT8173 is different from other SoCs for MMU_CTRL register.
> > For mt8173, its bit9 is in_order_write_en and doesn't use its
> > default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en feature and
> > victim_tlb is enable defaultly(bit[12]=1), if we use
> > "regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will be
> > disabled, it will drop iommu performace.
> > So we need to deal with the setting of MMU_CTRL separately
> > for mt8173 and others.
> >
>
> My proposal to rewrite the commit message:
>
> The MMU_CTRL regiser of MT8173 is different from other SoCs. The in_order_wr_en
> is bit[9] which is zero by default.
> Other SoCs have the vitcim_tlb_en feature mapped to bit[12]. This bit is set to
> one by default. We need to preserve the bit when setting
> F_MMU_TF_PROT_TO_PROGRAM_ADDR as otherwise the bit will be cleared and IOMMU
> performance will drop.
got it, thanks for your advice very much.
>
>
> > Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> > Suggested-by: Yong Wu <yong.wu@mediatek.com>
> > Signed-off-by: Chao Hao <chao.hao@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 8299a3299090..e46e2deee3fd 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -543,11 +543,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> > return ret;
> > }
> >
> > + regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
>
> The read is only needed in the else branch.
>
ok, thanks
> > if (data->plat_data->m4u_plat == M4U_MT8173)
> > regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> > F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
> > else
> > - regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> > + regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> > writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
> >
> > regval = F_L2_MULIT_HIT_EN |
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
2020-06-30 10:55 ` Yong Wu
(?)
(?)
@ 2020-06-30 11:07 ` chao hao
-1 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:07 UTC (permalink / raw)
To: Yong Wu
Cc: Joerg Roedel, Rob Herring, Matthias Brugger, Evan Green, iommu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, FY Yang, Chao Hao
On Tue, 2020-06-30 at 18:55 +0800, Yong Wu wrote:
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > diagram).
> > If the larb's number is over 8, we use a sub_common for merging
> > several larbs into one larb. At this case, we will extend larb_id:
> > bit[11:9] means common-id;
> > bit[8:7] means subcommon-id;
> > From these two variables, we could get the real larb number when
> > translation fault happen.
> > The diagram is as below:
> > EMI
> > |
> > IOMMU
> > |
> > -----------------
> > | |
> > common1 common0
> > | |
> > -----------------
> > |
> > smi common
> > |
> > ------------------------------------
> > | | | | | |
> > 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> > | | | | | |
> > Larb0 Larb1 | Larb3 ... Larb7
> > |
> > smi sub common
> > |
> > --------------------------
> > | | | |
> > 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> > | | | |
> > Larb8 Larb9 Larb10 Larb11
> >
> > In this patch we extend larb_remap[] to larb_remap[8][4] for this.
> > larb_remap[x][y]: x means common-id above, y means subcommon_id above.
> >
> > We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
> > macro.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> > drivers/iommu/mtk_iommu.h | 3 ++-
> > include/soc/mediatek/smi.h | 2 ++
> > 3 files changed, 17 insertions(+), 8 deletions(-)
>
> [snip]
>
> > @@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
> > enum mtk_iommu_plat m4u_plat;
> > u32 flags;
> > u32 inv_sel_reg;
> > - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > + unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
> > };
> >
> > struct mtk_iommu_domain;
> > diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> > index 5a34b87d89e3..fa65a55468e2 100644
> > --- a/include/soc/mediatek/smi.h
> > +++ b/include/soc/mediatek/smi.h
> > @@ -12,6 +12,8 @@
> > #ifdef CONFIG_MTK_SMI
> >
> > #define MTK_LARB_NR_MAX 16
> > +#define MTK_LARB_COM_MAX 8
> > +#define MTK_LARB_SUBCOM_MAX 4
>
> Both are only used in mtk_iommu.h, and I don't think smi has plan to use
> them. thus we could move them into mtk_iommu.h
>
ok, got it. Thanks for your advice.
> >
> > #define MTK_SMI_MMU_EN(port) BIT(port)
> >
>
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
@ 2020-06-30 11:07 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:07 UTC (permalink / raw)
To: Yong Wu
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
On Tue, 2020-06-30 at 18:55 +0800, Yong Wu wrote:
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > diagram).
> > If the larb's number is over 8, we use a sub_common for merging
> > several larbs into one larb. At this case, we will extend larb_id:
> > bit[11:9] means common-id;
> > bit[8:7] means subcommon-id;
> > From these two variables, we could get the real larb number when
> > translation fault happen.
> > The diagram is as below:
> > EMI
> > |
> > IOMMU
> > |
> > -----------------
> > | |
> > common1 common0
> > | |
> > -----------------
> > |
> > smi common
> > |
> > ------------------------------------
> > | | | | | |
> > 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> > | | | | | |
> > Larb0 Larb1 | Larb3 ... Larb7
> > |
> > smi sub common
> > |
> > --------------------------
> > | | | |
> > 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> > | | | |
> > Larb8 Larb9 Larb10 Larb11
> >
> > In this patch we extend larb_remap[] to larb_remap[8][4] for this.
> > larb_remap[x][y]: x means common-id above, y means subcommon_id above.
> >
> > We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
> > macro.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> > drivers/iommu/mtk_iommu.h | 3 ++-
> > include/soc/mediatek/smi.h | 2 ++
> > 3 files changed, 17 insertions(+), 8 deletions(-)
>
> [snip]
>
> > @@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
> > enum mtk_iommu_plat m4u_plat;
> > u32 flags;
> > u32 inv_sel_reg;
> > - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > + unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
> > };
> >
> > struct mtk_iommu_domain;
> > diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> > index 5a34b87d89e3..fa65a55468e2 100644
> > --- a/include/soc/mediatek/smi.h
> > +++ b/include/soc/mediatek/smi.h
> > @@ -12,6 +12,8 @@
> > #ifdef CONFIG_MTK_SMI
> >
> > #define MTK_LARB_NR_MAX 16
> > +#define MTK_LARB_COM_MAX 8
> > +#define MTK_LARB_SUBCOM_MAX 4
>
> Both are only used in mtk_iommu.h, and I don't think smi has plan to use
> them. thus we could move them into mtk_iommu.h
>
ok, got it. Thanks for your advice.
> >
> > #define MTK_SMI_MMU_EN(port) BIT(port)
> >
>
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
@ 2020-06-30 11:07 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:07 UTC (permalink / raw)
To: Yong Wu
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
Matthias Brugger, linux-arm-kernel
On Tue, 2020-06-30 at 18:55 +0800, Yong Wu wrote:
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > diagram).
> > If the larb's number is over 8, we use a sub_common for merging
> > several larbs into one larb. At this case, we will extend larb_id:
> > bit[11:9] means common-id;
> > bit[8:7] means subcommon-id;
> > From these two variables, we could get the real larb number when
> > translation fault happen.
> > The diagram is as below:
> > EMI
> > |
> > IOMMU
> > |
> > -----------------
> > | |
> > common1 common0
> > | |
> > -----------------
> > |
> > smi common
> > |
> > ------------------------------------
> > | | | | | |
> > 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> > | | | | | |
> > Larb0 Larb1 | Larb3 ... Larb7
> > |
> > smi sub common
> > |
> > --------------------------
> > | | | |
> > 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> > | | | |
> > Larb8 Larb9 Larb10 Larb11
> >
> > In this patch we extend larb_remap[] to larb_remap[8][4] for this.
> > larb_remap[x][y]: x means common-id above, y means subcommon_id above.
> >
> > We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
> > macro.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> > drivers/iommu/mtk_iommu.h | 3 ++-
> > include/soc/mediatek/smi.h | 2 ++
> > 3 files changed, 17 insertions(+), 8 deletions(-)
>
> [snip]
>
> > @@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
> > enum mtk_iommu_plat m4u_plat;
> > u32 flags;
> > u32 inv_sel_reg;
> > - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > + unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
> > };
> >
> > struct mtk_iommu_domain;
> > diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> > index 5a34b87d89e3..fa65a55468e2 100644
> > --- a/include/soc/mediatek/smi.h
> > +++ b/include/soc/mediatek/smi.h
> > @@ -12,6 +12,8 @@
> > #ifdef CONFIG_MTK_SMI
> >
> > #define MTK_LARB_NR_MAX 16
> > +#define MTK_LARB_COM_MAX 8
> > +#define MTK_LARB_SUBCOM_MAX 4
>
> Both are only used in mtk_iommu.h, and I don't think smi has plan to use
> them. thus we could move them into mtk_iommu.h
>
ok, got it. Thanks for your advice.
> >
> > #define MTK_SMI_MMU_EN(port) BIT(port)
> >
>
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault
@ 2020-06-30 11:07 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:07 UTC (permalink / raw)
To: Yong Wu
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
Matthias Brugger, linux-arm-kernel
On Tue, 2020-06-30 at 18:55 +0800, Yong Wu wrote:
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > diagram).
> > If the larb's number is over 8, we use a sub_common for merging
> > several larbs into one larb. At this case, we will extend larb_id:
> > bit[11:9] means common-id;
> > bit[8:7] means subcommon-id;
> > From these two variables, we could get the real larb number when
> > translation fault happen.
> > The diagram is as below:
> > EMI
> > |
> > IOMMU
> > |
> > -----------------
> > | |
> > common1 common0
> > | |
> > -----------------
> > |
> > smi common
> > |
> > ------------------------------------
> > | | | | | |
> > 3'd0 3'd1 3'd2 3'd3 ... 3'd7 <-common_id(max is 8)
> > | | | | | |
> > Larb0 Larb1 | Larb3 ... Larb7
> > |
> > smi sub common
> > |
> > --------------------------
> > | | | |
> > 2'd0 2'd1 2'd2 2'd3 <-sub_common_id(max is 4)
> > | | | |
> > Larb8 Larb9 Larb10 Larb11
> >
> > In this patch we extend larb_remap[] to larb_remap[8][4] for this.
> > larb_remap[x][y]: x means common-id above, y means subcommon_id above.
> >
> > We can also distinguish if the M4U HW has sub_common by HAS_SUB_COMM
> > macro.
> >
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 20 +++++++++++++-------
> > drivers/iommu/mtk_iommu.h | 3 ++-
> > include/soc/mediatek/smi.h | 2 ++
> > 3 files changed, 17 insertions(+), 8 deletions(-)
>
> [snip]
>
> > @@ -48,7 +49,7 @@ struct mtk_iommu_plat_data {
> > enum mtk_iommu_plat m4u_plat;
> > u32 flags;
> > u32 inv_sel_reg;
> > - unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > + unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
> > };
> >
> > struct mtk_iommu_domain;
> > diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> > index 5a34b87d89e3..fa65a55468e2 100644
> > --- a/include/soc/mediatek/smi.h
> > +++ b/include/soc/mediatek/smi.h
> > @@ -12,6 +12,8 @@
> > #ifdef CONFIG_MTK_SMI
> >
> > #define MTK_LARB_NR_MAX 16
> > +#define MTK_LARB_COM_MAX 8
> > +#define MTK_LARB_SUBCOM_MAX 4
>
> Both are only used in mtk_iommu.h, and I don't think smi has plan to use
> them. thus we could move them into mtk_iommu.h
>
ok, got it. Thanks for your advice.
> >
> > #define MTK_SMI_MMU_EN(port) BIT(port)
> >
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
2020-06-30 10:56 ` Yong Wu
(?)
(?)
@ 2020-06-30 11:55 ` chao hao
-1 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:55 UTC (permalink / raw)
To: Yong Wu
Cc: Joerg Roedel, Rob Herring, Matthias Brugger, Evan Green, iommu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, FY Yang, Chao Hao
On Tue, 2020-06-30 at 18:56 +0800, Yong Wu wrote:
> Hi Chao,
>
> This is also ok for me. Only two format nitpick.
>
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > Given the fact that we are adding more and more plat_data bool values,
> > it would make sense to use a u32 flags register and add the appropriate
> > macro definitions to set and check for a flag present.
> > No functional change.
> >
> > Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
>
> [snip]
>
> > static const struct mtk_iommu_plat_data mt2712_data = {
> > .m4u_plat = M4U_MT2712,
> > - .has_4gb_mode = true,
> > - .has_bclk = true,
> > - .has_vld_pa_rng = true,
> > + .flags = HAS_4GB_MODE |
> > + HAS_BCLK |
> > + HAS_VLD_PA_RNG,
>
> short enough. we can put it in one line?
ok, I will try to put it in one line in next version, thanks
>
> > .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> > };
> >
> > static const struct mtk_iommu_plat_data mt8173_data = {
> > .m4u_plat = M4U_MT8173,
> > - .has_4gb_mode = true,
> > - .has_bclk = true,
> > - .reset_axi = true,
> > + .flags = HAS_4GB_MODE |
> > + HAS_BCLK |
> > + RESET_AXI,
> > .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> > };
> >
> > static const struct mtk_iommu_plat_data mt8183_data = {
> > .m4u_plat = M4U_MT8183,
> > - .reset_axi = true,
> > + .flags = RESET_AXI,
> > .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> > };
> >
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 1b6ea839b92c..7cc39f729263 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -17,6 +17,15 @@
> > #include <linux/spinlock.h>
> > #include <soc/mediatek/smi.h>
> >
> > +#define HAS_4GB_MODE BIT(0)
> > +/* HW will use the EMI clock if there isn't the "bclk". */
> > +#define HAS_BCLK BIT(1)
> > +#define HAS_VLD_PA_RNG BIT(2)
> > +#define RESET_AXI BIT(3)
> > +
> > +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > + ((((pdata)->flags) & (_x)) == (_x))
>
> If these definitions are not used in mtk_iommu_v1.c(also no this plan),
> then we can put them in the mtk_iommu.c.
>
ok, mtk_iommu_v1.c doesn't use these definitions.
I will move them to mtk_iommu.c in next version, thanks.
>
> BTW, the patch title "modify the usage of mtk_iommu_plat_data structure"
> isn't so clear, we could write what the detailed modification is.
> something like:
> iommu/mediatek: Use a u32 flags to describe different HW features
>
got it , thanks for you advice.
> > +
> > struct mtk_iommu_suspend_reg {
> > u32 misc_ctrl;
> > u32 dcm_dis;
> > @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
> >
> > struct mtk_iommu_plat_data {
> > enum mtk_iommu_plat m4u_plat;
> > - bool has_4gb_mode;
> > -
> > - /* HW will use the EMI clock if there isn't the "bclk". */
> > - bool has_bclk;
> > - bool has_vld_pa_rng;
> > - bool reset_axi;
> > + u32 flags;
> > unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > };
> >
>
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-30 11:55 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:55 UTC (permalink / raw)
To: Yong Wu
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
On Tue, 2020-06-30 at 18:56 +0800, Yong Wu wrote:
> Hi Chao,
>
> This is also ok for me. Only two format nitpick.
>
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > Given the fact that we are adding more and more plat_data bool values,
> > it would make sense to use a u32 flags register and add the appropriate
> > macro definitions to set and check for a flag present.
> > No functional change.
> >
> > Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
>
> [snip]
>
> > static const struct mtk_iommu_plat_data mt2712_data = {
> > .m4u_plat = M4U_MT2712,
> > - .has_4gb_mode = true,
> > - .has_bclk = true,
> > - .has_vld_pa_rng = true,
> > + .flags = HAS_4GB_MODE |
> > + HAS_BCLK |
> > + HAS_VLD_PA_RNG,
>
> short enough. we can put it in one line?
ok, I will try to put it in one line in next version, thanks
>
> > .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> > };
> >
> > static const struct mtk_iommu_plat_data mt8173_data = {
> > .m4u_plat = M4U_MT8173,
> > - .has_4gb_mode = true,
> > - .has_bclk = true,
> > - .reset_axi = true,
> > + .flags = HAS_4GB_MODE |
> > + HAS_BCLK |
> > + RESET_AXI,
> > .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> > };
> >
> > static const struct mtk_iommu_plat_data mt8183_data = {
> > .m4u_plat = M4U_MT8183,
> > - .reset_axi = true,
> > + .flags = RESET_AXI,
> > .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> > };
> >
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 1b6ea839b92c..7cc39f729263 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -17,6 +17,15 @@
> > #include <linux/spinlock.h>
> > #include <soc/mediatek/smi.h>
> >
> > +#define HAS_4GB_MODE BIT(0)
> > +/* HW will use the EMI clock if there isn't the "bclk". */
> > +#define HAS_BCLK BIT(1)
> > +#define HAS_VLD_PA_RNG BIT(2)
> > +#define RESET_AXI BIT(3)
> > +
> > +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > + ((((pdata)->flags) & (_x)) == (_x))
>
> If these definitions are not used in mtk_iommu_v1.c(also no this plan),
> then we can put them in the mtk_iommu.c.
>
ok, mtk_iommu_v1.c doesn't use these definitions.
I will move them to mtk_iommu.c in next version, thanks.
>
> BTW, the patch title "modify the usage of mtk_iommu_plat_data structure"
> isn't so clear, we could write what the detailed modification is.
> something like:
> iommu/mediatek: Use a u32 flags to describe different HW features
>
got it , thanks for you advice.
> > +
> > struct mtk_iommu_suspend_reg {
> > u32 misc_ctrl;
> > u32 dcm_dis;
> > @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
> >
> > struct mtk_iommu_plat_data {
> > enum mtk_iommu_plat m4u_plat;
> > - bool has_4gb_mode;
> > -
> > - /* HW will use the EMI clock if there isn't the "bclk". */
> > - bool has_bclk;
> > - bool has_vld_pa_rng;
> > - bool reset_axi;
> > + u32 flags;
> > unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > };
> >
>
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-30 11:55 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:55 UTC (permalink / raw)
To: Yong Wu
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
Matthias Brugger, linux-arm-kernel
On Tue, 2020-06-30 at 18:56 +0800, Yong Wu wrote:
> Hi Chao,
>
> This is also ok for me. Only two format nitpick.
>
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > Given the fact that we are adding more and more plat_data bool values,
> > it would make sense to use a u32 flags register and add the appropriate
> > macro definitions to set and check for a flag present.
> > No functional change.
> >
> > Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
>
> [snip]
>
> > static const struct mtk_iommu_plat_data mt2712_data = {
> > .m4u_plat = M4U_MT2712,
> > - .has_4gb_mode = true,
> > - .has_bclk = true,
> > - .has_vld_pa_rng = true,
> > + .flags = HAS_4GB_MODE |
> > + HAS_BCLK |
> > + HAS_VLD_PA_RNG,
>
> short enough. we can put it in one line?
ok, I will try to put it in one line in next version, thanks
>
> > .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> > };
> >
> > static const struct mtk_iommu_plat_data mt8173_data = {
> > .m4u_plat = M4U_MT8173,
> > - .has_4gb_mode = true,
> > - .has_bclk = true,
> > - .reset_axi = true,
> > + .flags = HAS_4GB_MODE |
> > + HAS_BCLK |
> > + RESET_AXI,
> > .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> > };
> >
> > static const struct mtk_iommu_plat_data mt8183_data = {
> > .m4u_plat = M4U_MT8183,
> > - .reset_axi = true,
> > + .flags = RESET_AXI,
> > .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> > };
> >
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 1b6ea839b92c..7cc39f729263 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -17,6 +17,15 @@
> > #include <linux/spinlock.h>
> > #include <soc/mediatek/smi.h>
> >
> > +#define HAS_4GB_MODE BIT(0)
> > +/* HW will use the EMI clock if there isn't the "bclk". */
> > +#define HAS_BCLK BIT(1)
> > +#define HAS_VLD_PA_RNG BIT(2)
> > +#define RESET_AXI BIT(3)
> > +
> > +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > + ((((pdata)->flags) & (_x)) == (_x))
>
> If these definitions are not used in mtk_iommu_v1.c(also no this plan),
> then we can put them in the mtk_iommu.c.
>
ok, mtk_iommu_v1.c doesn't use these definitions.
I will move them to mtk_iommu.c in next version, thanks.
>
> BTW, the patch title "modify the usage of mtk_iommu_plat_data structure"
> isn't so clear, we could write what the detailed modification is.
> something like:
> iommu/mediatek: Use a u32 flags to describe different HW features
>
got it , thanks for you advice.
> > +
> > struct mtk_iommu_suspend_reg {
> > u32 misc_ctrl;
> > u32 dcm_dis;
> > @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
> >
> > struct mtk_iommu_plat_data {
> > enum mtk_iommu_plat m4u_plat;
> > - bool has_4gb_mode;
> > -
> > - /* HW will use the EMI clock if there isn't the "bclk". */
> > - bool has_bclk;
> > - bool has_vld_pa_rng;
> > - bool reset_axi;
> > + u32 flags;
> > unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > };
> >
>
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
@ 2020-06-30 11:55 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-06-30 11:55 UTC (permalink / raw)
To: Yong Wu
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
Matthias Brugger, linux-arm-kernel
On Tue, 2020-06-30 at 18:56 +0800, Yong Wu wrote:
> Hi Chao,
>
> This is also ok for me. Only two format nitpick.
>
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > Given the fact that we are adding more and more plat_data bool values,
> > it would make sense to use a u32 flags register and add the appropriate
> > macro definitions to set and check for a flag present.
> > No functional change.
> >
> > Suggested-by: Matthias Brugger <matthias.bgg@gmail.com>
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > ---
>
> [snip]
>
> > static const struct mtk_iommu_plat_data mt2712_data = {
> > .m4u_plat = M4U_MT2712,
> > - .has_4gb_mode = true,
> > - .has_bclk = true,
> > - .has_vld_pa_rng = true,
> > + .flags = HAS_4GB_MODE |
> > + HAS_BCLK |
> > + HAS_VLD_PA_RNG,
>
> short enough. we can put it in one line?
ok, I will try to put it in one line in next version, thanks
>
> > .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> > };
> >
> > static const struct mtk_iommu_plat_data mt8173_data = {
> > .m4u_plat = M4U_MT8173,
> > - .has_4gb_mode = true,
> > - .has_bclk = true,
> > - .reset_axi = true,
> > + .flags = HAS_4GB_MODE |
> > + HAS_BCLK |
> > + RESET_AXI,
> > .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> > };
> >
> > static const struct mtk_iommu_plat_data mt8183_data = {
> > .m4u_plat = M4U_MT8183,
> > - .reset_axi = true,
> > + .flags = RESET_AXI,
> > .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> > };
> >
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index 1b6ea839b92c..7cc39f729263 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -17,6 +17,15 @@
> > #include <linux/spinlock.h>
> > #include <soc/mediatek/smi.h>
> >
> > +#define HAS_4GB_MODE BIT(0)
> > +/* HW will use the EMI clock if there isn't the "bclk". */
> > +#define HAS_BCLK BIT(1)
> > +#define HAS_VLD_PA_RNG BIT(2)
> > +#define RESET_AXI BIT(3)
> > +
> > +#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> > + ((((pdata)->flags) & (_x)) == (_x))
>
> If these definitions are not used in mtk_iommu_v1.c(also no this plan),
> then we can put them in the mtk_iommu.c.
>
ok, mtk_iommu_v1.c doesn't use these definitions.
I will move them to mtk_iommu.c in next version, thanks.
>
> BTW, the patch title "modify the usage of mtk_iommu_plat_data structure"
> isn't so clear, we could write what the detailed modification is.
> something like:
> iommu/mediatek: Use a u32 flags to describe different HW features
>
got it , thanks for you advice.
> > +
> > struct mtk_iommu_suspend_reg {
> > u32 misc_ctrl;
> > u32 dcm_dis;
> > @@ -36,12 +45,7 @@ enum mtk_iommu_plat {
> >
> > struct mtk_iommu_plat_data {
> > enum mtk_iommu_plat m4u_plat;
> > - bool has_4gb_mode;
> > -
> > - /* HW will use the EMI clock if there isn't the "bclk". */
> > - bool has_bclk;
> > - bool has_vld_pa_rng;
> > - bool reset_axi;
> > + u32 flags;
> > unsigned char larbid_remap[MTK_LARB_NR_MAX];
> > };
> >
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 02/10] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
2020-06-29 7:13 ` Chao Hao
@ 2020-07-01 2:17 ` Yong Wu
-1 siblings, 0 replies; 101+ messages in thread
From: Yong Wu @ 2020-07-01 2:17 UTC (permalink / raw)
To: Chao Hao; +Cc: FY Yang, wsd_upstream, iommu, linux-mediatek, Matthias Brugger
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
> name STANDARD_AXI_MODE, all the latest SoC extend the register more
> feature by different bits, for example: axi_mode, in_order_en, coherent_en
> and so on. So rename REG_MMU_MISC_CTRL may be more proper.
>
> This patch only rename the register name, no functional change.
>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 14 +++++++-------
> drivers/iommu/mtk_iommu.h | 2 +-
> 2 files changed, 8 insertions(+), 8 deletions(-)
...
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index ea949a324e33..1b6ea839b92c 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -18,7 +18,7 @@
> #include <soc/mediatek/smi.h>
>
> struct mtk_iommu_suspend_reg {
> - u32 standard_axi_mode;
> + u32 misc_ctrl;
Here will cause build fail for v1:
drivers/iommu/mtk_iommu_v1.c:675:20: error: 'struct
mtk_iommu_suspend_reg' has no member named 'standard_axi_mode'
writel_relaxed(reg->standard_axi_mode,
^
We could change something like:
union {
u32 standard_axi_mode; /* only for v1 */
u32 misc_ctrl; /* only for v2 */
};
> u32 dcm_dis;
> u32 ctrl_reg;
> u32 int_control0;
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 02/10] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
@ 2020-07-01 2:17 ` Yong Wu
0 siblings, 0 replies; 101+ messages in thread
From: Yong Wu @ 2020-07-01 2:17 UTC (permalink / raw)
To: Chao Hao
Cc: FY Yang, wsd_upstream, Joerg Roedel, iommu, linux-mediatek,
Matthias Brugger
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
> name STANDARD_AXI_MODE, all the latest SoC extend the register more
> feature by different bits, for example: axi_mode, in_order_en, coherent_en
> and so on. So rename REG_MMU_MISC_CTRL may be more proper.
>
> This patch only rename the register name, no functional change.
>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 14 +++++++-------
> drivers/iommu/mtk_iommu.h | 2 +-
> 2 files changed, 8 insertions(+), 8 deletions(-)
...
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index ea949a324e33..1b6ea839b92c 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -18,7 +18,7 @@
> #include <soc/mediatek/smi.h>
>
> struct mtk_iommu_suspend_reg {
> - u32 standard_axi_mode;
> + u32 misc_ctrl;
Here will cause build fail for v1:
drivers/iommu/mtk_iommu_v1.c:675:20: error: 'struct
mtk_iommu_suspend_reg' has no member named 'standard_axi_mode'
writel_relaxed(reg->standard_axi_mode,
^
We could change something like:
union {
u32 standard_axi_mode; /* only for v1 */
u32 misc_ctrl; /* only for v2 */
};
> u32 dcm_dis;
> u32 ctrl_reg;
> u32 int_control0;
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
2020-06-30 10:53 ` chao hao
(?)
(?)
@ 2020-07-01 14:58 ` Matthias Brugger
-1 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-07-01 14:58 UTC (permalink / raw)
To: chao hao
Cc: Joerg Roedel, Rob Herring, Yong Wu, Evan Green, iommu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, FY Yang
On 30/06/2020 12:53, chao hao wrote:
> On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>>
>> On 29/06/2020 09:13, Chao Hao wrote:
>>> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
>>> in MISC_CTRL register.
>>> F_MMU_STANDARD_AXI_MODE_BIT:
>>> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
>>> standard AXI protocol), iommu will send urgent read command firstly
>>> compare with normal read command to improve performance.
>>
>> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
>> Does this mean that you will send a 'urgent read command' which is not described
>> in the specifications instead of a normal read command?
>
> ok.
> iommu sends read command to next bus_node normally(we can name it to
> cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
> command is needed to be sent(we can name it to cmd2), iommu will send
> cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
> cmd2 will be handled secondly.
> But for standard AXI protocol, it will ignore the priority of read
> command and only be handled in order. So cmd2 is handled by next
> bus_node after cmd1 is done.
>
Thanks. So I propose change this part of the commit message to something like:
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
AXI protocol), the iommu will priorize sending of urgent read command over a
normal read command. This improves the performance.
>>
>>> F_MMU_IN_ORDER_WR_EN:
>>> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
>>> will re-order write command and send more higher priority write command
>>> instead of sending write command in order. The feature be controlled
>>> by OUT_ORDER_EN macro definition.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
iommu will re-order write commands and send the write command with higher
priority. Otherwise the sending of write commands will be done in order. The
feature is controlled by OUT_ORDER_WR_EN platform data flag.
>>>
>>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
>>> Suggested-by: Yong Wu <yong.wu@mediatek.com>
>>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
>>> ---
>>> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
>>> drivers/iommu/mtk_iommu.h | 1 +
>>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index 8f81df6cbe51..67b46b5d83d9 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -42,6 +42,9 @@
>>> #define F_INVLD_EN1 BIT(1)
>>>
>>> #define REG_MMU_MISC_CTRL 0x048
>>> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
>>> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>>
>> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> ok, you are right.
> 1'b1: follow standard axi protocol
>
What about
F_MMU_IN_ORDER_WR_EN_MASK
F_MMU_STANDARD_AXI_MODE_EN_MASK
Background is that we have to set/unset two bits to enable or disable the
feature, so it's a mask we have to apply to the register.
Regards,
Matthias
>>
>>> +
>>> #define REG_MMU_DCM_DIS 0x050
>>>
>>> #define REG_MMU_CTRL_REG 0x110
>>> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>>> }
>>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>>>
>>> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>>
>> We only need to read regval in the else branch.
>
> ok, I got it. thanks
>
>>
>>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
>>> /* The register is called STANDARD_AXI_MODE in this case */
>>> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
>>> + regval = 0;
>>> + } else {
>>> + /* For mm_iommu, it can improve performance by the setting */
>>> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
>>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
>>> + regval &= ~F_MMU_IN_ORDER_WR_EN;
>>> }
>>> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
>>>
>>> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
>>> dev_name(data->dev), (void *)data)) {
>>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
>>> index 7cc39f729263..4b780b651ef4 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -22,6 +22,7 @@
>>> #define HAS_BCLK BIT(1)
>>> #define HAS_VLD_PA_RNG BIT(2)
>>> #define RESET_AXI BIT(3)
>>> +#define OUT_ORDER_EN BIT(4)
>>
>> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
>> write path.
>>
> ok, thanks for your advice.
>
>>>
>>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
>>> ((((pdata)->flags) & (_x)) == (_x))
>>>
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-07-01 14:58 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-07-01 14:58 UTC (permalink / raw)
To: chao hao
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, Rob Herring, linux-mediatek, linux-arm-kernel
On 30/06/2020 12:53, chao hao wrote:
> On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>>
>> On 29/06/2020 09:13, Chao Hao wrote:
>>> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
>>> in MISC_CTRL register.
>>> F_MMU_STANDARD_AXI_MODE_BIT:
>>> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
>>> standard AXI protocol), iommu will send urgent read command firstly
>>> compare with normal read command to improve performance.
>>
>> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
>> Does this mean that you will send a 'urgent read command' which is not described
>> in the specifications instead of a normal read command?
>
> ok.
> iommu sends read command to next bus_node normally(we can name it to
> cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
> command is needed to be sent(we can name it to cmd2), iommu will send
> cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
> cmd2 will be handled secondly.
> But for standard AXI protocol, it will ignore the priority of read
> command and only be handled in order. So cmd2 is handled by next
> bus_node after cmd1 is done.
>
Thanks. So I propose change this part of the commit message to something like:
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
AXI protocol), the iommu will priorize sending of urgent read command over a
normal read command. This improves the performance.
>>
>>> F_MMU_IN_ORDER_WR_EN:
>>> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
>>> will re-order write command and send more higher priority write command
>>> instead of sending write command in order. The feature be controlled
>>> by OUT_ORDER_EN macro definition.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
iommu will re-order write commands and send the write command with higher
priority. Otherwise the sending of write commands will be done in order. The
feature is controlled by OUT_ORDER_WR_EN platform data flag.
>>>
>>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
>>> Suggested-by: Yong Wu <yong.wu@mediatek.com>
>>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
>>> ---
>>> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
>>> drivers/iommu/mtk_iommu.h | 1 +
>>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index 8f81df6cbe51..67b46b5d83d9 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -42,6 +42,9 @@
>>> #define F_INVLD_EN1 BIT(1)
>>>
>>> #define REG_MMU_MISC_CTRL 0x048
>>> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
>>> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>>
>> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> ok, you are right.
> 1'b1: follow standard axi protocol
>
What about
F_MMU_IN_ORDER_WR_EN_MASK
F_MMU_STANDARD_AXI_MODE_EN_MASK
Background is that we have to set/unset two bits to enable or disable the
feature, so it's a mask we have to apply to the register.
Regards,
Matthias
>>
>>> +
>>> #define REG_MMU_DCM_DIS 0x050
>>>
>>> #define REG_MMU_CTRL_REG 0x110
>>> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>>> }
>>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>>>
>>> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>>
>> We only need to read regval in the else branch.
>
> ok, I got it. thanks
>
>>
>>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
>>> /* The register is called STANDARD_AXI_MODE in this case */
>>> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
>>> + regval = 0;
>>> + } else {
>>> + /* For mm_iommu, it can improve performance by the setting */
>>> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
>>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
>>> + regval &= ~F_MMU_IN_ORDER_WR_EN;
>>> }
>>> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
>>>
>>> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
>>> dev_name(data->dev), (void *)data)) {
>>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
>>> index 7cc39f729263..4b780b651ef4 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -22,6 +22,7 @@
>>> #define HAS_BCLK BIT(1)
>>> #define HAS_VLD_PA_RNG BIT(2)
>>> #define RESET_AXI BIT(3)
>>> +#define OUT_ORDER_EN BIT(4)
>>
>> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
>> write path.
>>
> ok, thanks for your advice.
>
>>>
>>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
>>> ((((pdata)->flags) & (_x)) == (_x))
>>>
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-07-01 14:58 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-07-01 14:58 UTC (permalink / raw)
To: chao hao
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, iommu, Rob Herring, linux-mediatek, linux-arm-kernel,
Yong Wu
On 30/06/2020 12:53, chao hao wrote:
> On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>>
>> On 29/06/2020 09:13, Chao Hao wrote:
>>> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
>>> in MISC_CTRL register.
>>> F_MMU_STANDARD_AXI_MODE_BIT:
>>> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
>>> standard AXI protocol), iommu will send urgent read command firstly
>>> compare with normal read command to improve performance.
>>
>> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
>> Does this mean that you will send a 'urgent read command' which is not described
>> in the specifications instead of a normal read command?
>
> ok.
> iommu sends read command to next bus_node normally(we can name it to
> cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
> command is needed to be sent(we can name it to cmd2), iommu will send
> cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
> cmd2 will be handled secondly.
> But for standard AXI protocol, it will ignore the priority of read
> command and only be handled in order. So cmd2 is handled by next
> bus_node after cmd1 is done.
>
Thanks. So I propose change this part of the commit message to something like:
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
AXI protocol), the iommu will priorize sending of urgent read command over a
normal read command. This improves the performance.
>>
>>> F_MMU_IN_ORDER_WR_EN:
>>> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
>>> will re-order write command and send more higher priority write command
>>> instead of sending write command in order. The feature be controlled
>>> by OUT_ORDER_EN macro definition.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
iommu will re-order write commands and send the write command with higher
priority. Otherwise the sending of write commands will be done in order. The
feature is controlled by OUT_ORDER_WR_EN platform data flag.
>>>
>>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
>>> Suggested-by: Yong Wu <yong.wu@mediatek.com>
>>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
>>> ---
>>> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
>>> drivers/iommu/mtk_iommu.h | 1 +
>>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index 8f81df6cbe51..67b46b5d83d9 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -42,6 +42,9 @@
>>> #define F_INVLD_EN1 BIT(1)
>>>
>>> #define REG_MMU_MISC_CTRL 0x048
>>> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
>>> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>>
>> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> ok, you are right.
> 1'b1: follow standard axi protocol
>
What about
F_MMU_IN_ORDER_WR_EN_MASK
F_MMU_STANDARD_AXI_MODE_EN_MASK
Background is that we have to set/unset two bits to enable or disable the
feature, so it's a mask we have to apply to the register.
Regards,
Matthias
>>
>>> +
>>> #define REG_MMU_DCM_DIS 0x050
>>>
>>> #define REG_MMU_CTRL_REG 0x110
>>> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>>> }
>>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>>>
>>> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>>
>> We only need to read regval in the else branch.
>
> ok, I got it. thanks
>
>>
>>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
>>> /* The register is called STANDARD_AXI_MODE in this case */
>>> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
>>> + regval = 0;
>>> + } else {
>>> + /* For mm_iommu, it can improve performance by the setting */
>>> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
>>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
>>> + regval &= ~F_MMU_IN_ORDER_WR_EN;
>>> }
>>> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
>>>
>>> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
>>> dev_name(data->dev), (void *)data)) {
>>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
>>> index 7cc39f729263..4b780b651ef4 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -22,6 +22,7 @@
>>> #define HAS_BCLK BIT(1)
>>> #define HAS_VLD_PA_RNG BIT(2)
>>> #define RESET_AXI BIT(3)
>>> +#define OUT_ORDER_EN BIT(4)
>>
>> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
>> write path.
>>
> ok, thanks for your advice.
>
>>>
>>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
>>> ((((pdata)->flags) & (_x)) == (_x))
>>>
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-07-01 14:58 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-07-01 14:58 UTC (permalink / raw)
To: chao hao
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, iommu, Rob Herring, linux-mediatek, linux-arm-kernel,
Yong Wu
On 30/06/2020 12:53, chao hao wrote:
> On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>>
>> On 29/06/2020 09:13, Chao Hao wrote:
>>> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
>>> in MISC_CTRL register.
>>> F_MMU_STANDARD_AXI_MODE_BIT:
>>> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
>>> standard AXI protocol), iommu will send urgent read command firstly
>>> compare with normal read command to improve performance.
>>
>> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
>> Does this mean that you will send a 'urgent read command' which is not described
>> in the specifications instead of a normal read command?
>
> ok.
> iommu sends read command to next bus_node normally(we can name it to
> cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
> command is needed to be sent(we can name it to cmd2), iommu will send
> cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
> cmd2 will be handled secondly.
> But for standard AXI protocol, it will ignore the priority of read
> command and only be handled in order. So cmd2 is handled by next
> bus_node after cmd1 is done.
>
Thanks. So I propose change this part of the commit message to something like:
F_MMU_STANDARD_AXI_MODE_BIT:
If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
AXI protocol), the iommu will priorize sending of urgent read command over a
normal read command. This improves the performance.
>>
>>> F_MMU_IN_ORDER_WR_EN:
>>> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
>>> will re-order write command and send more higher priority write command
>>> instead of sending write command in order. The feature be controlled
>>> by OUT_ORDER_EN macro definition.
F_MMU_IN_ORDER_WR_EN:
If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
iommu will re-order write commands and send the write command with higher
priority. Otherwise the sending of write commands will be done in order. The
feature is controlled by OUT_ORDER_WR_EN platform data flag.
>>>
>>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
>>> Suggested-by: Yong Wu <yong.wu@mediatek.com>
>>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
>>> ---
>>> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
>>> drivers/iommu/mtk_iommu.h | 1 +
>>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index 8f81df6cbe51..67b46b5d83d9 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -42,6 +42,9 @@
>>> #define F_INVLD_EN1 BIT(1)
>>>
>>> #define REG_MMU_MISC_CTRL 0x048
>>> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
>>> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>>
>> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> ok, you are right.
> 1'b1: follow standard axi protocol
>
What about
F_MMU_IN_ORDER_WR_EN_MASK
F_MMU_STANDARD_AXI_MODE_EN_MASK
Background is that we have to set/unset two bits to enable or disable the
feature, so it's a mask we have to apply to the register.
Regards,
Matthias
>>
>>> +
>>> #define REG_MMU_DCM_DIS 0x050
>>>
>>> #define REG_MMU_CTRL_REG 0x110
>>> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>>> }
>>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>>>
>>> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>>
>> We only need to read regval in the else branch.
>
> ok, I got it. thanks
>
>>
>>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
>>> /* The register is called STANDARD_AXI_MODE in this case */
>>> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
>>> + regval = 0;
>>> + } else {
>>> + /* For mm_iommu, it can improve performance by the setting */
>>> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
>>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
>>> + regval &= ~F_MMU_IN_ORDER_WR_EN;
>>> }
>>> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
>>>
>>> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
>>> dev_name(data->dev), (void *)data)) {
>>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
>>> index 7cc39f729263..4b780b651ef4 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -22,6 +22,7 @@
>>> #define HAS_BCLK BIT(1)
>>> #define HAS_VLD_PA_RNG BIT(2)
>>> #define RESET_AXI BIT(3)
>>> +#define OUT_ORDER_EN BIT(4)
>>
>> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
>> write path.
>>
> ok, thanks for your advice.
>
>>>
>>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
>>> ((((pdata)->flags) & (_x)) == (_x))
>>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
2020-06-30 10:59 ` chao hao
(?)
(?)
@ 2020-07-01 15:00 ` Matthias Brugger
-1 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-07-01 15:00 UTC (permalink / raw)
To: chao hao
Cc: Joerg Roedel, Rob Herring, Yong Wu, Evan Green, iommu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, FY Yang
On 30/06/2020 12:59, chao hao wrote:
> On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>>
>> On 29/06/2020 09:13, Chao Hao wrote:
>>> Some platforms(ex: mt6779) need to improve performance by setting
>>> REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
>>> whether we need to set the register. If the register uses default value,
>>> iommu will send command to EMI without restriction, when the number of
>>> commands become more and more, it will drop the EMI performance. So when
>>> more than ten_commands(default value) don't be handled for EMI, iommu will
>>> stop send command to EMI for keeping EMI's performace by enabling write
>>> throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
>>>
>>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
>>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
>>> ---
>>> drivers/iommu/mtk_iommu.c | 10 ++++++++++
>>> drivers/iommu/mtk_iommu.h | 2 ++
>>> 2 files changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index ec1f86913739..92316c4175a9 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -46,6 +46,8 @@
>>> #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>>>
>>> #define REG_MMU_DCM_DIS 0x050
>>> +#define REG_MMU_WR_LEN 0x054
>>
>> The register name is confusing. For me it seems to describe the length of a
>> write but it is used for controlling the write throttling. Is this the name
>> that's used in the datasheet?
>>
>
> Thanks for your review carefully, we can name it to REG_MMU_WR_LEN_CTRL
Yes, that's mbetter, thanks.
>
>
>>> +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
>>
>> There are two spaces between '|' and 'BIT(21)', should be one.
>>
>> Regarding the name of the define, what does the 'F_' statnds for?
>
> F_ is used to described some bits in register and doesn't have other
> meanings. The format is refer to other bits definition
>
>> Also I think
>> it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
>>
>
> Thanks for your advice.
> For F_MMU_WR_THROT_DIS_BIT:
> 1'b0: Enable write throttling mechanism
> 1'b1: Disable write throttling mechanism
> So I think we can name "F_MMU_WR_THROT_DIS BIT(5) | BIT(21)" directly,
> it maybe more clearer.
>
Is this what the datasheet names it? If not then I'd prefer F_MMU_WR_THROT_DIS_MASK.
Regards,
Matthias
>> Regards,
>> Matthias
>>
>>>
>>> #define REG_MMU_CTRL_REG 0x110
>>> #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
>>> @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>>> writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
>>> }
>>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
>>> + /* write command throttling mode */
>>> + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
>>> + regval &= ~F_MMU_WR_THROT_DIS_BIT;
>>> + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
>>> + }
>>>
>>> regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
>>> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
>>> struct mtk_iommu_suspend_reg *reg = &data->reg;
>>> void __iomem *base = data->base;
>>>
>>> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
>>> reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
>>> reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
>>> reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
>>> @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
>>> dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
>>> return ret;
>>> }
>>> + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
>>> writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
>>> writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
>>> writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
>>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
>>> index be6d32ee5bda..ce4f4e8f03aa 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -24,6 +24,7 @@
>>> #define RESET_AXI BIT(3)
>>> #define OUT_ORDER_EN BIT(4)
>>> #define HAS_SUB_COMM BIT(5)
>>> +#define WR_THROT_EN BIT(6)
>>>
>>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
>>> ((((pdata)->flags) & (_x)) == (_x))
>>> @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
>>> u32 int_main_control;
>>> u32 ivrp_paddr;
>>> u32 vld_pa_rng;
>>> + u32 wr_len;
>>> };
>>>
>>> enum mtk_iommu_plat {
>>>
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-07-01 15:00 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-07-01 15:00 UTC (permalink / raw)
To: chao hao
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
iommu, Rob Herring, linux-mediatek, linux-arm-kernel
On 30/06/2020 12:59, chao hao wrote:
> On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>>
>> On 29/06/2020 09:13, Chao Hao wrote:
>>> Some platforms(ex: mt6779) need to improve performance by setting
>>> REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
>>> whether we need to set the register. If the register uses default value,
>>> iommu will send command to EMI without restriction, when the number of
>>> commands become more and more, it will drop the EMI performance. So when
>>> more than ten_commands(default value) don't be handled for EMI, iommu will
>>> stop send command to EMI for keeping EMI's performace by enabling write
>>> throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
>>>
>>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
>>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
>>> ---
>>> drivers/iommu/mtk_iommu.c | 10 ++++++++++
>>> drivers/iommu/mtk_iommu.h | 2 ++
>>> 2 files changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index ec1f86913739..92316c4175a9 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -46,6 +46,8 @@
>>> #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>>>
>>> #define REG_MMU_DCM_DIS 0x050
>>> +#define REG_MMU_WR_LEN 0x054
>>
>> The register name is confusing. For me it seems to describe the length of a
>> write but it is used for controlling the write throttling. Is this the name
>> that's used in the datasheet?
>>
>
> Thanks for your review carefully, we can name it to REG_MMU_WR_LEN_CTRL
Yes, that's mbetter, thanks.
>
>
>>> +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
>>
>> There are two spaces between '|' and 'BIT(21)', should be one.
>>
>> Regarding the name of the define, what does the 'F_' statnds for?
>
> F_ is used to described some bits in register and doesn't have other
> meanings. The format is refer to other bits definition
>
>> Also I think
>> it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
>>
>
> Thanks for your advice.
> For F_MMU_WR_THROT_DIS_BIT:
> 1'b0: Enable write throttling mechanism
> 1'b1: Disable write throttling mechanism
> So I think we can name "F_MMU_WR_THROT_DIS BIT(5) | BIT(21)" directly,
> it maybe more clearer.
>
Is this what the datasheet names it? If not then I'd prefer F_MMU_WR_THROT_DIS_MASK.
Regards,
Matthias
>> Regards,
>> Matthias
>>
>>>
>>> #define REG_MMU_CTRL_REG 0x110
>>> #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
>>> @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>>> writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
>>> }
>>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
>>> + /* write command throttling mode */
>>> + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
>>> + regval &= ~F_MMU_WR_THROT_DIS_BIT;
>>> + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
>>> + }
>>>
>>> regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
>>> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
>>> struct mtk_iommu_suspend_reg *reg = &data->reg;
>>> void __iomem *base = data->base;
>>>
>>> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
>>> reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
>>> reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
>>> reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
>>> @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
>>> dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
>>> return ret;
>>> }
>>> + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
>>> writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
>>> writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
>>> writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
>>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
>>> index be6d32ee5bda..ce4f4e8f03aa 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -24,6 +24,7 @@
>>> #define RESET_AXI BIT(3)
>>> #define OUT_ORDER_EN BIT(4)
>>> #define HAS_SUB_COMM BIT(5)
>>> +#define WR_THROT_EN BIT(6)
>>>
>>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
>>> ((((pdata)->flags) & (_x)) == (_x))
>>> @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
>>> u32 int_main_control;
>>> u32 ivrp_paddr;
>>> u32 vld_pa_rng;
>>> + u32 wr_len;
>>> };
>>>
>>> enum mtk_iommu_plat {
>>>
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-07-01 15:00 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-07-01 15:00 UTC (permalink / raw)
To: chao hao
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, iommu, Rob Herring, linux-mediatek, linux-arm-kernel,
Yong Wu
On 30/06/2020 12:59, chao hao wrote:
> On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>>
>> On 29/06/2020 09:13, Chao Hao wrote:
>>> Some platforms(ex: mt6779) need to improve performance by setting
>>> REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
>>> whether we need to set the register. If the register uses default value,
>>> iommu will send command to EMI without restriction, when the number of
>>> commands become more and more, it will drop the EMI performance. So when
>>> more than ten_commands(default value) don't be handled for EMI, iommu will
>>> stop send command to EMI for keeping EMI's performace by enabling write
>>> throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
>>>
>>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
>>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
>>> ---
>>> drivers/iommu/mtk_iommu.c | 10 ++++++++++
>>> drivers/iommu/mtk_iommu.h | 2 ++
>>> 2 files changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index ec1f86913739..92316c4175a9 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -46,6 +46,8 @@
>>> #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>>>
>>> #define REG_MMU_DCM_DIS 0x050
>>> +#define REG_MMU_WR_LEN 0x054
>>
>> The register name is confusing. For me it seems to describe the length of a
>> write but it is used for controlling the write throttling. Is this the name
>> that's used in the datasheet?
>>
>
> Thanks for your review carefully, we can name it to REG_MMU_WR_LEN_CTRL
Yes, that's mbetter, thanks.
>
>
>>> +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
>>
>> There are two spaces between '|' and 'BIT(21)', should be one.
>>
>> Regarding the name of the define, what does the 'F_' statnds for?
>
> F_ is used to described some bits in register and doesn't have other
> meanings. The format is refer to other bits definition
>
>> Also I think
>> it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
>>
>
> Thanks for your advice.
> For F_MMU_WR_THROT_DIS_BIT:
> 1'b0: Enable write throttling mechanism
> 1'b1: Disable write throttling mechanism
> So I think we can name "F_MMU_WR_THROT_DIS BIT(5) | BIT(21)" directly,
> it maybe more clearer.
>
Is this what the datasheet names it? If not then I'd prefer F_MMU_WR_THROT_DIS_MASK.
Regards,
Matthias
>> Regards,
>> Matthias
>>
>>>
>>> #define REG_MMU_CTRL_REG 0x110
>>> #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
>>> @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>>> writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
>>> }
>>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
>>> + /* write command throttling mode */
>>> + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
>>> + regval &= ~F_MMU_WR_THROT_DIS_BIT;
>>> + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
>>> + }
>>>
>>> regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
>>> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
>>> struct mtk_iommu_suspend_reg *reg = &data->reg;
>>> void __iomem *base = data->base;
>>>
>>> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
>>> reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
>>> reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
>>> reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
>>> @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
>>> dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
>>> return ret;
>>> }
>>> + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
>>> writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
>>> writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
>>> writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
>>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
>>> index be6d32ee5bda..ce4f4e8f03aa 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -24,6 +24,7 @@
>>> #define RESET_AXI BIT(3)
>>> #define OUT_ORDER_EN BIT(4)
>>> #define HAS_SUB_COMM BIT(5)
>>> +#define WR_THROT_EN BIT(6)
>>>
>>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
>>> ((((pdata)->flags) & (_x)) == (_x))
>>> @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
>>> u32 int_main_control;
>>> u32 ivrp_paddr;
>>> u32 vld_pa_rng;
>>> + u32 wr_len;
>>> };
>>>
>>> enum mtk_iommu_plat {
>>>
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
@ 2020-07-01 15:00 ` Matthias Brugger
0 siblings, 0 replies; 101+ messages in thread
From: Matthias Brugger @ 2020-07-01 15:00 UTC (permalink / raw)
To: chao hao
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, iommu, Rob Herring, linux-mediatek, linux-arm-kernel,
Yong Wu
On 30/06/2020 12:59, chao hao wrote:
> On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>>
>> On 29/06/2020 09:13, Chao Hao wrote:
>>> Some platforms(ex: mt6779) need to improve performance by setting
>>> REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
>>> whether we need to set the register. If the register uses default value,
>>> iommu will send command to EMI without restriction, when the number of
>>> commands become more and more, it will drop the EMI performance. So when
>>> more than ten_commands(default value) don't be handled for EMI, iommu will
>>> stop send command to EMI for keeping EMI's performace by enabling write
>>> throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
>>>
>>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
>>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
>>> ---
>>> drivers/iommu/mtk_iommu.c | 10 ++++++++++
>>> drivers/iommu/mtk_iommu.h | 2 ++
>>> 2 files changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index ec1f86913739..92316c4175a9 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -46,6 +46,8 @@
>>> #define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
>>>
>>> #define REG_MMU_DCM_DIS 0x050
>>> +#define REG_MMU_WR_LEN 0x054
>>
>> The register name is confusing. For me it seems to describe the length of a
>> write but it is used for controlling the write throttling. Is this the name
>> that's used in the datasheet?
>>
>
> Thanks for your review carefully, we can name it to REG_MMU_WR_LEN_CTRL
Yes, that's mbetter, thanks.
>
>
>>> +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
>>
>> There are two spaces between '|' and 'BIT(21)', should be one.
>>
>> Regarding the name of the define, what does the 'F_' statnds for?
>
> F_ is used to described some bits in register and doesn't have other
> meanings. The format is refer to other bits definition
>
>> Also I think
>> it should be called '_MASK' instead of '_BIT' as it defines a mask of bits.
>>
>
> Thanks for your advice.
> For F_MMU_WR_THROT_DIS_BIT:
> 1'b0: Enable write throttling mechanism
> 1'b1: Disable write throttling mechanism
> So I think we can name "F_MMU_WR_THROT_DIS BIT(5) | BIT(21)" directly,
> it maybe more clearer.
>
Is this what the datasheet names it? If not then I'd prefer F_MMU_WR_THROT_DIS_MASK.
Regards,
Matthias
>> Regards,
>> Matthias
>>
>>>
>>> #define REG_MMU_CTRL_REG 0x110
>>> #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
>>> @@ -582,6 +584,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>>> writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
>>> }
>>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, WR_THROT_EN)) {
>>> + /* write command throttling mode */
>>> + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
>>> + regval &= ~F_MMU_WR_THROT_DIS_BIT;
>>> + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
>>> + }
>>>
>>> regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
>>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
>>> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
>>> struct mtk_iommu_suspend_reg *reg = &data->reg;
>>> void __iomem *base = data->base;
>>>
>>> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
>>> reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
>>> reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
>>> reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
>>> @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
>>> dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
>>> return ret;
>>> }
>>> + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
>>> writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
>>> writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
>>> writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
>>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
>>> index be6d32ee5bda..ce4f4e8f03aa 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -24,6 +24,7 @@
>>> #define RESET_AXI BIT(3)
>>> #define OUT_ORDER_EN BIT(4)
>>> #define HAS_SUB_COMM BIT(5)
>>> +#define WR_THROT_EN BIT(6)
>>>
>>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
>>> ((((pdata)->flags) & (_x)) == (_x))
>>> @@ -36,6 +37,7 @@ struct mtk_iommu_suspend_reg {
>>> u32 int_main_control;
>>> u32 ivrp_paddr;
>>> u32 vld_pa_rng;
>>> + u32 wr_len;
>>> };
>>>
>>> enum mtk_iommu_plat {
>>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 02/10] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
2020-07-01 2:17 ` Yong Wu
@ 2020-07-03 2:36 ` chao hao
-1 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-07-03 2:36 UTC (permalink / raw)
To: Yong Wu
Cc: FY Yang, wsd_upstream, Chao Hao, iommu, linux-mediatek, Matthias Brugger
On Wed, 2020-07-01 at 10:17 +0800, Yong Wu wrote:
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
> > name STANDARD_AXI_MODE, all the latest SoC extend the register more
> > feature by different bits, for example: axi_mode, in_order_en, coherent_en
> > and so on. So rename REG_MMU_MISC_CTRL may be more proper.
> >
> > This patch only rename the register name, no functional change.
> >
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> > Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 14 +++++++-------
> > drivers/iommu/mtk_iommu.h | 2 +-
> > 2 files changed, 8 insertions(+), 8 deletions(-)
>
> ...
>
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index ea949a324e33..1b6ea839b92c 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -18,7 +18,7 @@
> > #include <soc/mediatek/smi.h>
> >
> > struct mtk_iommu_suspend_reg {
> > - u32 standard_axi_mode;
> > + u32 misc_ctrl;
>
> Here will cause build fail for v1:
>
> drivers/iommu/mtk_iommu_v1.c:675:20: error: 'struct
> mtk_iommu_suspend_reg' has no member named 'standard_axi_mode'
> writel_relaxed(reg->standard_axi_mode,
> ^
>
> We could change something like:
>
> union {
> u32 standard_axi_mode; /* only for v1 */
> u32 misc_ctrl; /* only for v2 */
> };
>
> > u32 dcm_dis;
> > u32 ctrl_reg;
> > u32 int_control0;
ok, I will fix it in next version, thanks
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 02/10] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
@ 2020-07-03 2:36 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-07-03 2:36 UTC (permalink / raw)
To: Yong Wu
Cc: FY Yang, wsd_upstream, Chao Hao, Joerg Roedel, iommu,
linux-mediatek, Matthias Brugger
On Wed, 2020-07-01 at 10:17 +0800, Yong Wu wrote:
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
> > name STANDARD_AXI_MODE, all the latest SoC extend the register more
> > feature by different bits, for example: axi_mode, in_order_en, coherent_en
> > and so on. So rename REG_MMU_MISC_CTRL may be more proper.
> >
> > This patch only rename the register name, no functional change.
> >
> > Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> > Reviewed-by: Yong Wu <yong.wu@mediatek.com>
> > Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 14 +++++++-------
> > drivers/iommu/mtk_iommu.h | 2 +-
> > 2 files changed, 8 insertions(+), 8 deletions(-)
>
> ...
>
> > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> > index ea949a324e33..1b6ea839b92c 100644
> > --- a/drivers/iommu/mtk_iommu.h
> > +++ b/drivers/iommu/mtk_iommu.h
> > @@ -18,7 +18,7 @@
> > #include <soc/mediatek/smi.h>
> >
> > struct mtk_iommu_suspend_reg {
> > - u32 standard_axi_mode;
> > + u32 misc_ctrl;
>
> Here will cause build fail for v1:
>
> drivers/iommu/mtk_iommu_v1.c:675:20: error: 'struct
> mtk_iommu_suspend_reg' has no member named 'standard_axi_mode'
> writel_relaxed(reg->standard_axi_mode,
> ^
>
> We could change something like:
>
> union {
> u32 standard_axi_mode; /* only for v1 */
> u32 misc_ctrl; /* only for v2 */
> };
>
> > u32 dcm_dis;
> > u32 ctrl_reg;
> > u32 int_control0;
ok, I will fix it in next version, thanks
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
2020-07-01 14:58 ` Matthias Brugger
(?)
(?)
@ 2020-07-03 2:38 ` chao hao
-1 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-07-03 2:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: Joerg Roedel, Rob Herring, Yong Wu, Evan Green, iommu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, FY Yang, Chao Hao
On Wed, 2020-07-01 at 16:58 +0200, Matthias Brugger wrote:
>
> On 30/06/2020 12:53, chao hao wrote:
> > On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
> >>
> >> On 29/06/2020 09:13, Chao Hao wrote:
> >>> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> >>> in MISC_CTRL register.
> >>> F_MMU_STANDARD_AXI_MODE_BIT:
> >>> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> >>> standard AXI protocol), iommu will send urgent read command firstly
> >>> compare with normal read command to improve performance.
> >>
> >> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
> >> Does this mean that you will send a 'urgent read command' which is not described
> >> in the specifications instead of a normal read command?
> >
> > ok.
> > iommu sends read command to next bus_node normally(we can name it to
> > cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
> > command is needed to be sent(we can name it to cmd2), iommu will send
> > cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
> > cmd2 will be handled secondly.
> > But for standard AXI protocol, it will ignore the priority of read
> > command and only be handled in order. So cmd2 is handled by next
> > bus_node after cmd1 is done.
> >
>
> Thanks. So I propose change this part of the commit message to something like:
> F_MMU_STANDARD_AXI_MODE_BIT:
> If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
> AXI protocol), the iommu will priorize sending of urgent read command over a
> normal read command. This improves the performance.
>
ok, thanks
> >>
> >>> F_MMU_IN_ORDER_WR_EN:
> >>> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> >>> will re-order write command and send more higher priority write command
> >>> instead of sending write command in order. The feature be controlled
> >>> by OUT_ORDER_EN macro definition.
>
> F_MMU_IN_ORDER_WR_EN:
> If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
> iommu will re-order write commands and send the write command with higher
> priority. Otherwise the sending of write commands will be done in order. The
> feature is controlled by OUT_ORDER_WR_EN platform data flag.
>
>
> >>>
> >>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> >>> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> >>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> >>> ---
> >>> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> >>> drivers/iommu/mtk_iommu.h | 1 +
> >>> 2 files changed, 12 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> >>> index 8f81df6cbe51..67b46b5d83d9 100644
> >>> --- a/drivers/iommu/mtk_iommu.c
> >>> +++ b/drivers/iommu/mtk_iommu.c
> >>> @@ -42,6 +42,9 @@
> >>> #define F_INVLD_EN1 BIT(1)
> >>>
> >>> #define REG_MMU_MISC_CTRL 0x048
> >>> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> >>> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
> >>
> >> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> > ok, you are right.
> > 1'b1: follow standard axi protocol
> >
>
> What about
> F_MMU_IN_ORDER_WR_EN_MASK
> F_MMU_STANDARD_AXI_MODE_EN_MASK
>
> Background is that we have to set/unset two bits to enable or disable the
> feature, so it's a mask we have to apply to the register.
>
ok, thanks for your advice
> Regards,
> Matthias
>
> >>
> >>> +
> >>> #define REG_MMU_DCM_DIS 0x050
> >>>
> >>> #define REG_MMU_CTRL_REG 0x110
> >>> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> >>> }
> >>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> >>>
> >>> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> >>
> >> We only need to read regval in the else branch.
> >
> > ok, I got it. thanks
> >
> >>
> >>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> >>> /* The register is called STANDARD_AXI_MODE in this case */
> >>> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> >>> + regval = 0;
> >>> + } else {
> >>> + /* For mm_iommu, it can improve performance by the setting */
> >>> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> >>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> >>> + regval &= ~F_MMU_IN_ORDER_WR_EN;
> >>> }
> >>> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
> >>>
> >>> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> >>> dev_name(data->dev), (void *)data)) {
> >>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> >>> index 7cc39f729263..4b780b651ef4 100644
> >>> --- a/drivers/iommu/mtk_iommu.h
> >>> +++ b/drivers/iommu/mtk_iommu.h
> >>> @@ -22,6 +22,7 @@
> >>> #define HAS_BCLK BIT(1)
> >>> #define HAS_VLD_PA_RNG BIT(2)
> >>> #define RESET_AXI BIT(3)
> >>> +#define OUT_ORDER_EN BIT(4)
> >>
> >> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
> >> write path.
> >>
> > ok, thanks for your advice.
> >
> >>>
> >>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> >>> ((((pdata)->flags) & (_x)) == (_x))
> >>>
> >
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-07-03 2:38 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-07-03 2:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, linux-kernel, Evan Green,
Chao Hao, iommu, Rob Herring, linux-mediatek, linux-arm-kernel
On Wed, 2020-07-01 at 16:58 +0200, Matthias Brugger wrote:
>
> On 30/06/2020 12:53, chao hao wrote:
> > On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
> >>
> >> On 29/06/2020 09:13, Chao Hao wrote:
> >>> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> >>> in MISC_CTRL register.
> >>> F_MMU_STANDARD_AXI_MODE_BIT:
> >>> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> >>> standard AXI protocol), iommu will send urgent read command firstly
> >>> compare with normal read command to improve performance.
> >>
> >> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
> >> Does this mean that you will send a 'urgent read command' which is not described
> >> in the specifications instead of a normal read command?
> >
> > ok.
> > iommu sends read command to next bus_node normally(we can name it to
> > cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
> > command is needed to be sent(we can name it to cmd2), iommu will send
> > cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
> > cmd2 will be handled secondly.
> > But for standard AXI protocol, it will ignore the priority of read
> > command and only be handled in order. So cmd2 is handled by next
> > bus_node after cmd1 is done.
> >
>
> Thanks. So I propose change this part of the commit message to something like:
> F_MMU_STANDARD_AXI_MODE_BIT:
> If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
> AXI protocol), the iommu will priorize sending of urgent read command over a
> normal read command. This improves the performance.
>
ok, thanks
> >>
> >>> F_MMU_IN_ORDER_WR_EN:
> >>> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> >>> will re-order write command and send more higher priority write command
> >>> instead of sending write command in order. The feature be controlled
> >>> by OUT_ORDER_EN macro definition.
>
> F_MMU_IN_ORDER_WR_EN:
> If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
> iommu will re-order write commands and send the write command with higher
> priority. Otherwise the sending of write commands will be done in order. The
> feature is controlled by OUT_ORDER_WR_EN platform data flag.
>
>
> >>>
> >>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> >>> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> >>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> >>> ---
> >>> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> >>> drivers/iommu/mtk_iommu.h | 1 +
> >>> 2 files changed, 12 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> >>> index 8f81df6cbe51..67b46b5d83d9 100644
> >>> --- a/drivers/iommu/mtk_iommu.c
> >>> +++ b/drivers/iommu/mtk_iommu.c
> >>> @@ -42,6 +42,9 @@
> >>> #define F_INVLD_EN1 BIT(1)
> >>>
> >>> #define REG_MMU_MISC_CTRL 0x048
> >>> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> >>> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
> >>
> >> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> > ok, you are right.
> > 1'b1: follow standard axi protocol
> >
>
> What about
> F_MMU_IN_ORDER_WR_EN_MASK
> F_MMU_STANDARD_AXI_MODE_EN_MASK
>
> Background is that we have to set/unset two bits to enable or disable the
> feature, so it's a mask we have to apply to the register.
>
ok, thanks for your advice
> Regards,
> Matthias
>
> >>
> >>> +
> >>> #define REG_MMU_DCM_DIS 0x050
> >>>
> >>> #define REG_MMU_CTRL_REG 0x110
> >>> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> >>> }
> >>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> >>>
> >>> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> >>
> >> We only need to read regval in the else branch.
> >
> > ok, I got it. thanks
> >
> >>
> >>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> >>> /* The register is called STANDARD_AXI_MODE in this case */
> >>> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> >>> + regval = 0;
> >>> + } else {
> >>> + /* For mm_iommu, it can improve performance by the setting */
> >>> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> >>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> >>> + regval &= ~F_MMU_IN_ORDER_WR_EN;
> >>> }
> >>> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
> >>>
> >>> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> >>> dev_name(data->dev), (void *)data)) {
> >>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> >>> index 7cc39f729263..4b780b651ef4 100644
> >>> --- a/drivers/iommu/mtk_iommu.h
> >>> +++ b/drivers/iommu/mtk_iommu.h
> >>> @@ -22,6 +22,7 @@
> >>> #define HAS_BCLK BIT(1)
> >>> #define HAS_VLD_PA_RNG BIT(2)
> >>> #define RESET_AXI BIT(3)
> >>> +#define OUT_ORDER_EN BIT(4)
> >>
> >> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
> >> write path.
> >>
> > ok, thanks for your advice.
> >
> >>>
> >>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> >>> ((((pdata)->flags) & (_x)) == (_x))
> >>>
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-07-03 2:38 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-07-03 2:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
linux-arm-kernel, Yong Wu
On Wed, 2020-07-01 at 16:58 +0200, Matthias Brugger wrote:
>
> On 30/06/2020 12:53, chao hao wrote:
> > On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
> >>
> >> On 29/06/2020 09:13, Chao Hao wrote:
> >>> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> >>> in MISC_CTRL register.
> >>> F_MMU_STANDARD_AXI_MODE_BIT:
> >>> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> >>> standard AXI protocol), iommu will send urgent read command firstly
> >>> compare with normal read command to improve performance.
> >>
> >> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
> >> Does this mean that you will send a 'urgent read command' which is not described
> >> in the specifications instead of a normal read command?
> >
> > ok.
> > iommu sends read command to next bus_node normally(we can name it to
> > cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
> > command is needed to be sent(we can name it to cmd2), iommu will send
> > cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
> > cmd2 will be handled secondly.
> > But for standard AXI protocol, it will ignore the priority of read
> > command and only be handled in order. So cmd2 is handled by next
> > bus_node after cmd1 is done.
> >
>
> Thanks. So I propose change this part of the commit message to something like:
> F_MMU_STANDARD_AXI_MODE_BIT:
> If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
> AXI protocol), the iommu will priorize sending of urgent read command over a
> normal read command. This improves the performance.
>
ok, thanks
> >>
> >>> F_MMU_IN_ORDER_WR_EN:
> >>> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> >>> will re-order write command and send more higher priority write command
> >>> instead of sending write command in order. The feature be controlled
> >>> by OUT_ORDER_EN macro definition.
>
> F_MMU_IN_ORDER_WR_EN:
> If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
> iommu will re-order write commands and send the write command with higher
> priority. Otherwise the sending of write commands will be done in order. The
> feature is controlled by OUT_ORDER_WR_EN platform data flag.
>
>
> >>>
> >>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> >>> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> >>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> >>> ---
> >>> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> >>> drivers/iommu/mtk_iommu.h | 1 +
> >>> 2 files changed, 12 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> >>> index 8f81df6cbe51..67b46b5d83d9 100644
> >>> --- a/drivers/iommu/mtk_iommu.c
> >>> +++ b/drivers/iommu/mtk_iommu.c
> >>> @@ -42,6 +42,9 @@
> >>> #define F_INVLD_EN1 BIT(1)
> >>>
> >>> #define REG_MMU_MISC_CTRL 0x048
> >>> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> >>> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
> >>
> >> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> > ok, you are right.
> > 1'b1: follow standard axi protocol
> >
>
> What about
> F_MMU_IN_ORDER_WR_EN_MASK
> F_MMU_STANDARD_AXI_MODE_EN_MASK
>
> Background is that we have to set/unset two bits to enable or disable the
> feature, so it's a mask we have to apply to the register.
>
ok, thanks for your advice
> Regards,
> Matthias
>
> >>
> >>> +
> >>> #define REG_MMU_DCM_DIS 0x050
> >>>
> >>> #define REG_MMU_CTRL_REG 0x110
> >>> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> >>> }
> >>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> >>>
> >>> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> >>
> >> We only need to read regval in the else branch.
> >
> > ok, I got it. thanks
> >
> >>
> >>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> >>> /* The register is called STANDARD_AXI_MODE in this case */
> >>> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> >>> + regval = 0;
> >>> + } else {
> >>> + /* For mm_iommu, it can improve performance by the setting */
> >>> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> >>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> >>> + regval &= ~F_MMU_IN_ORDER_WR_EN;
> >>> }
> >>> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
> >>>
> >>> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> >>> dev_name(data->dev), (void *)data)) {
> >>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> >>> index 7cc39f729263..4b780b651ef4 100644
> >>> --- a/drivers/iommu/mtk_iommu.h
> >>> +++ b/drivers/iommu/mtk_iommu.h
> >>> @@ -22,6 +22,7 @@
> >>> #define HAS_BCLK BIT(1)
> >>> #define HAS_VLD_PA_RNG BIT(2)
> >>> #define RESET_AXI BIT(3)
> >>> +#define OUT_ORDER_EN BIT(4)
> >>
> >> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
> >> write path.
> >>
> > ok, thanks for your advice.
> >
> >>>
> >>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> >>> ((((pdata)->flags) & (_x)) == (_x))
> >>>
> >
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
@ 2020-07-03 2:38 ` chao hao
0 siblings, 0 replies; 101+ messages in thread
From: chao hao @ 2020-07-03 2:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
Evan Green, Chao Hao, iommu, Rob Herring, linux-mediatek,
linux-arm-kernel, Yong Wu
On Wed, 2020-07-01 at 16:58 +0200, Matthias Brugger wrote:
>
> On 30/06/2020 12:53, chao hao wrote:
> > On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
> >>
> >> On 29/06/2020 09:13, Chao Hao wrote:
> >>> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> >>> in MISC_CTRL register.
> >>> F_MMU_STANDARD_AXI_MODE_BIT:
> >>> If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not follow
> >>> standard AXI protocol), iommu will send urgent read command firstly
> >>> compare with normal read command to improve performance.
> >>
> >> Can you please help me to understand the phrase. Sorry I'm not a AXI specialist.
> >> Does this mean that you will send a 'urgent read command' which is not described
> >> in the specifications instead of a normal read command?
> >
> > ok.
> > iommu sends read command to next bus_node normally(we can name it to
> > cmd1), when cmd1 isn't handled by next bus_node, iommu has a urgent read
> > command is needed to be sent(we can name it to cmd2), iommu will send
> > cmd2 and replace cmd1. So cmd2 is handled by next bus_node firstly and
> > cmd2 will be handled secondly.
> > But for standard AXI protocol, it will ignore the priority of read
> > command and only be handled in order. So cmd2 is handled by next
> > bus_node after cmd1 is done.
> >
>
> Thanks. So I propose change this part of the commit message to something like:
> F_MMU_STANDARD_AXI_MODE_BIT:
> If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow standard
> AXI protocol), the iommu will priorize sending of urgent read command over a
> normal read command. This improves the performance.
>
ok, thanks
> >>
> >>> F_MMU_IN_ORDER_WR_EN:
> >>> If we set F_MMU_IN_ORDER_WR_EN(bit[1][17] = 0, out-of-order write), iommu
> >>> will re-order write command and send more higher priority write command
> >>> instead of sending write command in order. The feature be controlled
> >>> by OUT_ORDER_EN macro definition.
>
> F_MMU_IN_ORDER_WR_EN:
> If we set F_MMU_IN_ORDER_WR_EN_MASK (bit[1][17] = 0, out-of-order write), the
> iommu will re-order write commands and send the write command with higher
> priority. Otherwise the sending of write commands will be done in order. The
> feature is controlled by OUT_ORDER_WR_EN platform data flag.
>
>
> >>>
> >>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> >>> Suggested-by: Yong Wu <yong.wu@mediatek.com>
> >>> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> >>> ---
> >>> drivers/iommu/mtk_iommu.c | 12 +++++++++++-
> >>> drivers/iommu/mtk_iommu.h | 1 +
> >>> 2 files changed, 12 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> >>> index 8f81df6cbe51..67b46b5d83d9 100644
> >>> --- a/drivers/iommu/mtk_iommu.c
> >>> +++ b/drivers/iommu/mtk_iommu.c
> >>> @@ -42,6 +42,9 @@
> >>> #define F_INVLD_EN1 BIT(1)
> >>>
> >>> #define REG_MMU_MISC_CTRL 0x048
> >>> +#define F_MMU_IN_ORDER_WR_EN (BIT(1) | BIT(17))
> >>> +#define F_MMU_STANDARD_AXI_MODE_BIT (BIT(3) | BIT(19))
> >>
> >> Wouldn't it make more sense to name it F_MMU_STANDARD_AXI_MODE_EN?
> > ok, you are right.
> > 1'b1: follow standard axi protocol
> >
>
> What about
> F_MMU_IN_ORDER_WR_EN_MASK
> F_MMU_STANDARD_AXI_MODE_EN_MASK
>
> Background is that we have to set/unset two bits to enable or disable the
> feature, so it's a mask we have to apply to the register.
>
ok, thanks for your advice
> Regards,
> Matthias
>
> >>
> >>> +
> >>> #define REG_MMU_DCM_DIS 0x050
> >>>
> >>> #define REG_MMU_CTRL_REG 0x110
> >>> @@ -574,10 +577,17 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> >>> }
> >>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
> >>>
> >>> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> >>
> >> We only need to read regval in the else branch.
> >
> > ok, I got it. thanks
> >
> >>
> >>> if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
> >>> /* The register is called STANDARD_AXI_MODE in this case */
> >>> - writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> >>> + regval = 0;
> >>> + } else {
> >>> + /* For mm_iommu, it can improve performance by the setting */
> >>> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> >>> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_EN))
> >>> + regval &= ~F_MMU_IN_ORDER_WR_EN;
> >>> }
> >>> + writel_relaxed(regval, data->base + REG_MMU_MISC_CTRL);
> >>>
> >>> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> >>> dev_name(data->dev), (void *)data)) {
> >>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> >>> index 7cc39f729263..4b780b651ef4 100644
> >>> --- a/drivers/iommu/mtk_iommu.h
> >>> +++ b/drivers/iommu/mtk_iommu.h
> >>> @@ -22,6 +22,7 @@
> >>> #define HAS_BCLK BIT(1)
> >>> #define HAS_VLD_PA_RNG BIT(2)
> >>> #define RESET_AXI BIT(3)
> >>> +#define OUT_ORDER_EN BIT(4)
> >>
> >> Maybe something like OUT_ORDER_WR_EN, to make clear that it's about the the
> >> write path.
> >>
> > ok, thanks for your advice.
> >
> >>>
> >>> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> >>> ((((pdata)->flags) & (_x)) == (_x))
> >>>
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 101+ messages in thread
end of thread, other threads:[~2020-07-03 2:48 UTC | newest]
Thread overview: 101+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-29 7:13 [PATCH v5 00/10] MT6779 IOMMU SUPPORT Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` [PATCH v5 01/10] dt-bindings: mediatek: Add bindings for MT6779 Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` [PATCH v5 02/10] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-07-01 2:17 ` Yong Wu
2020-07-01 2:17 ` Yong Wu
2020-07-03 2:36 ` chao hao
2020-07-03 2:36 ` chao hao
2020-06-29 7:13 ` [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 9:11 ` Matthias Brugger
2020-06-29 9:11 ` Matthias Brugger
2020-06-29 9:11 ` Matthias Brugger
2020-06-29 9:11 ` Matthias Brugger
2020-06-30 10:56 ` Yong Wu
2020-06-30 10:56 ` Yong Wu
2020-06-30 10:56 ` Yong Wu
2020-06-30 10:56 ` Yong Wu
2020-06-30 11:55 ` chao hao
2020-06-30 11:55 ` chao hao
2020-06-30 11:55 ` chao hao
2020-06-30 11:55 ` chao hao
2020-06-29 7:13 ` [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 9:28 ` Matthias Brugger
2020-06-29 9:28 ` Matthias Brugger
2020-06-29 9:28 ` Matthias Brugger
2020-06-29 9:28 ` Matthias Brugger
2020-06-30 10:53 ` chao hao
2020-06-30 10:53 ` chao hao
2020-06-30 10:53 ` chao hao
2020-06-30 10:53 ` chao hao
2020-07-01 14:58 ` Matthias Brugger
2020-07-01 14:58 ` Matthias Brugger
2020-07-01 14:58 ` Matthias Brugger
2020-07-01 14:58 ` Matthias Brugger
2020-07-03 2:38 ` chao hao
2020-07-03 2:38 ` chao hao
2020-07-03 2:38 ` chao hao
2020-07-03 2:38 ` chao hao
2020-06-29 7:13 ` [PATCH v5 05/10] iommu/mediatek: Move inv_sel_reg into the plat_data Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-30 10:55 ` Yong Wu
2020-06-30 10:55 ` Yong Wu
2020-06-30 10:55 ` Yong Wu
2020-06-30 10:55 ` Yong Wu
2020-06-30 11:07 ` chao hao
2020-06-30 11:07 ` chao hao
2020-06-30 11:07 ` chao hao
2020-06-30 11:07 ` chao hao
2020-06-29 7:13 ` [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 10:16 ` Matthias Brugger
2020-06-29 10:16 ` Matthias Brugger
2020-06-29 10:16 ` Matthias Brugger
2020-06-29 10:16 ` Matthias Brugger
2020-06-30 10:59 ` chao hao
2020-06-30 10:59 ` chao hao
2020-06-30 10:59 ` chao hao
2020-06-30 10:59 ` chao hao
2020-07-01 15:00 ` Matthias Brugger
2020-07-01 15:00 ` Matthias Brugger
2020-07-01 15:00 ` Matthias Brugger
2020-07-01 15:00 ` Matthias Brugger
2020-06-29 7:13 ` [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 10:17 ` Matthias Brugger
2020-06-29 10:17 ` Matthias Brugger
2020-06-29 10:17 ` Matthias Brugger
2020-06-29 10:17 ` Matthias Brugger
2020-06-29 7:13 ` [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 10:28 ` Matthias Brugger
2020-06-29 10:28 ` Matthias Brugger
2020-06-29 10:28 ` Matthias Brugger
2020-06-29 10:28 ` Matthias Brugger
2020-06-30 11:02 ` chao hao
2020-06-30 11:02 ` chao hao
2020-06-30 11:02 ` chao hao
2020-06-30 11:02 ` chao hao
2020-06-29 7:13 ` [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 7:13 ` Chao Hao
2020-06-29 10:29 ` Matthias Brugger
2020-06-29 10:29 ` Matthias Brugger
2020-06-29 10:29 ` Matthias Brugger
2020-06-29 10:29 ` Matthias Brugger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.