Re: [PATCH v1 02/16] dt-bindings: memory: mediatek: Update condition for mt8195 smi node
On 06/07/2022 16:38, Krzysztof Kozlowski wrote: On 06/07/2022 15:48, Matthias Brugger wrote: On 04/07/2022 14:36, Krzysztof Kozlowski wrote: On 04/07/2022 12:00, Tinghan Shen wrote: The max clock items for the dts node with compatible 'mediatek,mt8195-smi-sub-common' should be 3. However, the dtbs_check of such node will get following message, arch/arm64/boot/dts/mediatek/mt8195-evb.dtb: smi@1401: clock-names: ['apb', 'smi', 'gals0'] is too long From schema: Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml Remove the last 'else' checking to fix this error. Missing fixes tag. From my understanding, fixes tags are for patches that fix bugs (hw is not working etc) and not a warning message from dtbs_check. So my point of view would be to not add a fixes tag here. Not conforming to bindings is also a bug. Missing properties or wrong properties, even if hardware is working, is still a bug. If such bug is not visible now in Linux, might be visible later in the future or visible in different OS (DTS are used by other systems and pieces of software like bootloaders). Limiting this only to Linux and to current version (hardware still works) is OK for Linux drivers, but not for DTS. If a wrong DTS breaks software, then it's worth a fixes tag, especially for the DTS part, we could argue about the bindings part, but in that case it would be probably OK. Therefore Fixes tag in general is applicable. Of course maybe to this one not really, maybe this is too trivial, or whatever, so I do not insist. But I insist on the principle - reasonable dtbs_check warnings are like compiler warnings - bugs which have to be fixed. I'm not arguing that these things shouldn't be fixed, but that they are worth being back-ported to the stable branches. Regards, Matthias ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 02/16] dt-bindings: memory: mediatek: Update condition for mt8195 smi node
On 04/07/2022 14:36, Krzysztof Kozlowski wrote: On 04/07/2022 12:00, Tinghan Shen wrote: The max clock items for the dts node with compatible 'mediatek,mt8195-smi-sub-common' should be 3. However, the dtbs_check of such node will get following message, arch/arm64/boot/dts/mediatek/mt8195-evb.dtb: smi@1401: clock-names: ['apb', 'smi', 'gals0'] is too long From schema: Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml Remove the last 'else' checking to fix this error. Missing fixes tag. From my understanding, fixes tags are for patches that fix bugs (hw is not working etc) and not a warning message from dtbs_check. So my point of view would be to not add a fixes tag here. Regards, Matthias Signed-off-by: Tinghan Shen --- .../memory-controllers/mediatek,smi-common.yaml| 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index a98b359bf909..e5f553e2e12a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -143,7 +143,15 @@ allOf: - const: gals0 - const: gals1 -else: # for gen2 HW that don't have gals + - if: # for gen2 HW that don't have gals + properties: +compatible: + enum: +- mediatek,mt2712-smi-common +- mediatek,mt8167-smi-common +- mediatek,mt8173-smi-common + Without looking at the code, it's impossible to understand what you are doing here. The commit msg says one, but you are doing something else. Write commit msg explaining what you want to achieve and what you are doing. Best regards, Krzysztof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 08/16] arm64: dts: mt8195: Add power domains controller
On 04/07/2022 14:38, Krzysztof Kozlowski wrote:
On 04/07/2022 12:00, Tinghan Shen wrote:
Add power domains controller node for mt8195.
Signed-off-by: Weiyi Lu
Signed-off-by: Tinghan Shen
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 327 +++
1 file changed, 327 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index 8d59a7da3271..d52e140d9271 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt8195";
@@ -338,6 +339,332 @@
#interrupt-cells = <2>;
};
+ scpsys: syscon@10006000 {
+ compatible = "syscon", "simple-mfd";
These compatibles cannot be alone.
You mean we would need something like "mediatek,scpsys" as dummy compatible
that's not bound to any driver?
+ reg = <0 0x10006000 0 0x1000>;
+ #power-domain-cells = <1>;
If it is simple MFD, then probably it is not a power domain provider.
Decide.
The SCPSYS IP block of MediaTek SoCs group several functionality, one is the
power domain controller. Others are not yet implemented, but defining the scpsys
as a MFD will give us the possibility to do so in the future.
Regards,
Matthias
Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 0/5] mtk_iommu: Specify phandles to infracfg and pericfg
Hi Joerg, On 22/06/2022 15:44, Joerg Roedel wrote: On Thu, Jun 16, 2022 at 01:08:25PM +0200, AngeloGioacchino Del Regno wrote: AngeloGioacchino Del Regno (5): dt-bindings: iommu: mediatek: Add mediatek,infracfg phandle iommu/mediatek: Lookup phandle to retrieve syscon to infracfg arm64: dts: mediatek: mt8173: Add mediatek,infracfg phandle for IOMMU arm64: dts: mediatek: mt2712e: Add mediatek,infracfg phandle for IOMMU iommu/mediatek: Cleanup pericfg lookup flow .../bindings/iommu/mediatek,iommu.yaml| 17 +++ arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 2 + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 1 + drivers/iommu/mtk_iommu.c | 50 +++ 4 files changed, 49 insertions(+), 21 deletions(-) Applied, thanks. I wanted to check if you took also 3 and 4, as these should go through my tree. Unfortunately you haven't pushed your tree (yet). In case you took the whole series, can you please drop the dts patches. I'll apply them now on my v5.19-next/dts64 branch. Regards. Matthias ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 0/5] mtk_iommu: Specify phandles to infracfg and pericfg
Hi Joerg, On 22/06/2022 15:44, Joerg Roedel wrote: On Thu, Jun 16, 2022 at 01:08:25PM +0200, AngeloGioacchino Del Regno wrote: AngeloGioacchino Del Regno (5): dt-bindings: iommu: mediatek: Add mediatek,infracfg phandle iommu/mediatek: Lookup phandle to retrieve syscon to infracfg arm64: dts: mediatek: mt8173: Add mediatek,infracfg phandle for IOMMU arm64: dts: mediatek: mt2712e: Add mediatek,infracfg phandle for IOMMU iommu/mediatek: Cleanup pericfg lookup flow .../bindings/iommu/mediatek,iommu.yaml| 17 +++ arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 2 + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 1 + drivers/iommu/mtk_iommu.c | 50 +++ 4 files changed, 49 insertions(+), 21 deletions(-) Applied, thanks. I wanted to check if you took also 3 and 4, as these should go through my tree. Unfortunately you haven't pushed your tree (yet). In case you took the whole series, can you please drop the dts patches. I'll apply them now on my v5.19-next/dts64 branch. Regards. Matthias ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 6/6] iommu: mtk_iommu: Lookup phandle to retrieve syscon to pericfg
On 15/06/2022 14:28, AngeloGioacchino Del Regno wrote:
Il 15/06/22 14:09, Matthias Brugger ha scritto:
On 09/06/2022 12:08, AngeloGioacchino Del Regno wrote:
On some SoCs (of which only MT8195 is supported at the time of writing),
the "R" and "W" (I/O) enable bits for the IOMMUs are in the pericfg_ao
register space and not in the IOMMU space: as it happened already with
infracfg, it is expected that this list will grow.
Instead of specifying pericfg compatibles on a per-SoC basis, following
what was done with infracfg, let's lookup the syscon by phandle instead.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 90685946fcbe..0ea0848581e9 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -138,6 +138,8 @@
/* PM and clock always on. e.g. infra iommu */
#define PM_CLK_AO BIT(15)
#define IFA_IOMMU_PCIE_SUPPORT BIT(16)
+/* IOMMU I/O (r/w) is enabled using PERICFG_IOMMU_1 register */
+#define HAS_PERI_IOMMU1_REG BIT(17)
From what I can see MTK_IOMMU_TYPE_INFRA is only set in MT8195 which uses
pericfg. So we don't need a new flag here. For me the flag name
MTK_IOMMU_TYPE_INFRA was confusing as it has nothing to do with the use of
infracfg. I'll hijack this patch to provide some feedback on the actual code,
please see below.
#define MTK_IOMMU_HAS_FLAG_MASK(pdata, _x, mask) \
pdata)->flags) & (mask)) == (_x))
@@ -187,7 +189,6 @@ struct mtk_iommu_plat_data {
u32 flags;
u32 inv_sel_reg;
- char *pericfg_comp_str;
struct list_head *hw_list;
unsigned int iova_region_nr;
const struct mtk_iommu_iova_region *iova_region;
@@ -1218,14 +1219,16 @@ static int mtk_iommu_probe(struct platform_device *pdev)
goto out_runtime_disable;
}
} else if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_INFRA) &&
- data->plat_data->pericfg_comp_str) {
Check for pericfg_comp_str is not needed, we only have one platform that uses
MTK_IOMMU_TYPE_INFRA.
Fair enough. I agree.
- infracfg =
syscon_regmap_lookup_by_compatible(data->plat_data->pericfg_comp_str);
We can do something like this to make the code clearer:
data->pericfg =
syscon_regmap_lookup_by_compatible(data->plat_data->pericfg_comp_str);
if (IS_ERR(data->pericfg)) {
Using infracfg variable here is confusing as it has nothing to do with
infracfg used with HAS_4GB_MODE flag.
Yes Matthias, using the infracfg variable is confusing - that's why I changed
that
already
Regards,
Matthias
- if (IS_ERR(infracfg)) {
- ret = PTR_ERR(infracfg);
- goto out_runtime_disable;
+ MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_PERI_IOMMU1_REG)) {
+ data->pericfg = syscon_regmap_lookup_by_phandle(dev->of_node,
"mediatek,pericfg");
Here, where I'm assigning directly to data->pericfg :-P
Uuuups, sorry, did look too much on the existing code and not enough on your
patch.
By the way, since it was only about one platform, my intention was to remove the
pericfg_comp_str from struct iommu_plat_data (as you can see), but then, with
the
current code, I had to assign .
+ if (IS_ERR(data->pericfg)) {
+ p = "mediatek,mt8195-pericfg_ao";
...the string to 'p', because otherwise it would go over 100 columns.
In any case, I just checked and, apparently, MT8195 is really the one and only
SoC
that needs this pericfg register to be managed by Linux... even the latest and
greatest smartphone chip (Dimensity 9000, MT6983) doesn't need this (at least,
from what I can read on a downstream kernel).
On an afterthought, perhaps the best idea is to just leave this as it is and, as
you proposed, avoid using that confusing infracfg variable, without adding the
pericfg handle at all.
Either this or get also rid of the pericfg_comp_str in the _plat_data. I'm
unemotional about this :)
Regards,
Matthias
After all, it's just one single SoC.
I'll send a new version soon!
Cheers,
Angelo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 5/5] iommu/mediatek: Remove a unused "mapping" which is only for v1
On 16/06/2022 07:42, Yong Wu wrote:
Just remove a unused variable that only is for mtk_iommu_v1.
Fixes: 9485a04a5bb9 ("iommu/mediatek: Separate mtk_iommu_data for v1 and v2")
It does not fix a bug, so no fixes tag here needed.
With that:
Reviewed-by: Matthias Brugger
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 5e86fd48928a..e65e705d9fc1 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -221,10 +221,7 @@ struct mtk_iommu_data {
struct device *smicomm_dev;
struct mtk_iommu_bank_data *bank;
-
- struct dma_iommu_mapping*mapping; /* For mtk_iommu_v1.c */
struct regmap *pericfg;
-
struct mutexmutex; /* Protect m4u_group/m4u_dom
above */
/*
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 2/5] iommu/mediatek: Add error path for loop of mm_dts_parse
On 16/06/2022 07:42, Yong Wu wrote:
The mtk_iommu_mm_dts_parse will parse the smi larbs nodes. if the i+1
larb is parsed fail(return -EINVAL), we should of_node_put for the 0..i
larbs. In the fail path, one of_node_put matches with of_parse_phandle in
it.
Fixes: d2e9a1102cfc ("iommu/mediatek: Contain MM IOMMU flow with the MM TYPE")
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 3b2489e8a6dd..ab24078938bf 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -1071,12 +1071,12 @@ static int mtk_iommu_mm_dts_parse(struct device *dev,
struct component_match **m
Don't we need to call the goto also on error case of:
larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
Regards,
Matthias
plarbdev = of_find_device_by_node(larbnode);
if (!plarbdev) {
- of_node_put(larbnode);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_larbnode_put;
}
if (!plarbdev->dev.driver) {
- of_node_put(larbnode);
- return -EPROBE_DEFER;
+ ret = -EPROBE_DEFER;
+ goto err_larbnode_put;
}
data->larb_imu[id].dev = >dev;
@@ -1107,9 +1107,20 @@ static int mtk_iommu_mm_dts_parse(struct device *dev, struct component_match **m
DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
if (!link) {
dev_err(dev, "Unable to link %s.\n",
dev_name(data->smicomm_dev));
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_larbnode_put;
}
return 0;
+
+err_larbnode_put:
+ while (i--) {
+ larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
+ if (larbnode && of_device_is_available(larbnode)) {
+ of_node_put(larbnode);
+ of_node_put(larbnode);
+ }
+ }
+ return ret;
}
static int mtk_iommu_probe(struct platform_device *pdev)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/5] iommu/mediatek: Use dev_err_probe to mute probe_defer err log
On 16/06/2022 07:41, Yong Wu wrote:
Mute the probe defer log:
[2.654806] mtk-iommu 14018000.iommu: mm dts parse fail(-517).
[2.656168] mtk-iommu 1c01f000.iommu: mm dts parse fail(-517).
Fixes: d2e9a1102cfc ("iommu/mediatek: Contain MM IOMMU flow with the MM TYPE")
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Guenter Roeck
Reviewed-by: Matthias Brugger
---
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 bb9dd92c9898..3b2489e8a6dd 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -1204,7 +1204,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_MM)) {
ret = mtk_iommu_mm_dts_parse(dev, , data);
if (ret) {
- dev_err(dev, "mm dts parse fail(%d).", ret);
+ dev_err_probe(dev, ret, "mm dts parse fail.");
goto out_runtime_disable;
}
} else if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_INFRA) &&
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 5/5] iommu/mediatek: Cleanup pericfg lookup flow
On 16/06/2022 13:08, AngeloGioacchino Del Regno wrote:
Since only the INFRA type IOMMU needs to modify register(s) in the
pericfg iospace, it's safe to drop the pericfg_comp_str NULL check;
also, directly assign the regmap handle to data->pericfg instead of
to the infracfg variable to improve code readability.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 90685946fcbe..b2ae84046249 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -1217,15 +1217,13 @@ static int mtk_iommu_probe(struct platform_device *pdev)
dev_err(dev, "mm dts parse fail(%d).", ret);
goto out_runtime_disable;
}
- } else if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_INFRA) &&
- data->plat_data->pericfg_comp_str) {
- infracfg =
syscon_regmap_lookup_by_compatible(data->plat_data->pericfg_comp_str);
- if (IS_ERR(infracfg)) {
- ret = PTR_ERR(infracfg);
+ } else if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_INFRA)) {
+ p = data->plat_data->pericfg_comp_str;
+ data->pericfg = syscon_regmap_lookup_by_compatible(p);
+ if (IS_ERR(data->pericfg)) {
+ ret = PTR_ERR(data->pericfg);
goto out_runtime_disable;
}
-
- data->pericfg = infracfg;
}
platform_set_drvdata(pdev, data);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 1/5] dt-bindings: iommu: mediatek: Add mediatek,infracfg phandle
On 16/06/2022 13:08, AngeloGioacchino Del Regno wrote: Add property "mediatek,infracfg" to let the mtk_iommu driver retrieve a phandle to the infracfg syscon instead of performing a per-soc compatible lookup in the entire devicetree and set it as a required property for MT2712 and MT8173. Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger --- .../bindings/iommu/mediatek,iommu.yaml | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 2ae3bbad7f1a..fee0241b5098 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -101,6 +101,10 @@ properties: items: - const: bclk + mediatek,infracfg: +$ref: /schemas/types.yaml#/definitions/phandle +description: The phandle to the mediatek infracfg syscon + mediatek,larbs: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 @@ -167,6 +171,18 @@ allOf: required: - power-domains + - if: + properties: +compatible: + contains: +enum: + - mediatek,mt2712-m4u + - mediatek,mt8173-m4u + +then: + required: +- mediatek,infracfg + - if: # The IOMMUs don't have larbs. not: properties: @@ -191,6 +207,7 @@ examples: interrupts = ; clocks = < CLK_INFRA_M4U>; clock-names = "bclk"; +mediatek,infracfg = <>; mediatek,larbs = <>, <>, <>, <>, <>, <>; #iommu-cells = <1>; ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 6/6] iommu: mtk_iommu: Lookup phandle to retrieve syscon to pericfg
On 09/06/2022 12:08, AngeloGioacchino Del Regno wrote:
On some SoCs (of which only MT8195 is supported at the time of writing),
the "R" and "W" (I/O) enable bits for the IOMMUs are in the pericfg_ao
register space and not in the IOMMU space: as it happened already with
infracfg, it is expected that this list will grow.
Instead of specifying pericfg compatibles on a per-SoC basis, following
what was done with infracfg, let's lookup the syscon by phandle instead.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 90685946fcbe..0ea0848581e9 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -138,6 +138,8 @@
/* PM and clock always on. e.g. infra iommu */
#define PM_CLK_AO BIT(15)
#define IFA_IOMMU_PCIE_SUPPORTBIT(16)
+/* IOMMU I/O (r/w) is enabled using PERICFG_IOMMU_1 register */
+#define HAS_PERI_IOMMU1_REGBIT(17)
From what I can see MTK_IOMMU_TYPE_INFRA is only set in MT8195 which uses
pericfg. So we don't need a new flag here. For me the flag name
MTK_IOMMU_TYPE_INFRA was confusing as it has nothing to do with the use of
infracfg. I'll hijack this patch to provide some feedback on the actual code,
please see below.
#define MTK_IOMMU_HAS_FLAG_MASK(pdata, _x, mask) \
pdata)->flags) & (mask)) == (_x))
@@ -187,7 +189,6 @@ struct mtk_iommu_plat_data {
u32 flags;
u32 inv_sel_reg;
- char *pericfg_comp_str;
struct list_head*hw_list;
unsigned intiova_region_nr;
const struct mtk_iommu_iova_region *iova_region;
@@ -1218,14 +1219,16 @@ static int mtk_iommu_probe(struct platform_device *pdev)
goto out_runtime_disable;
}
} else if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_INFRA) &&
- data->plat_data->pericfg_comp_str) {
Check for pericfg_comp_str is not needed, we only have one platform that uses
MTK_IOMMU_TYPE_INFRA.
- infracfg =
syscon_regmap_lookup_by_compatible(data->plat_data->pericfg_comp_str);
We can do something like this to make the code clearer:
data->pericfg =
syscon_regmap_lookup_by_compatible(data->plat_data->pericfg_comp_str);
if (IS_ERR(data->pericfg)) {
Using infracfg variable here is confusing as it has nothing to do with infracfg
used with HAS_4GB_MODE flag.
Regards,
Matthias
- if (IS_ERR(infracfg)) {
- ret = PTR_ERR(infracfg);
- goto out_runtime_disable;
+ MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_PERI_IOMMU1_REG)) {
+ data->pericfg = syscon_regmap_lookup_by_phandle(dev->of_node,
"mediatek,pericfg");
+ if (IS_ERR(data->pericfg)) {
+ p = "mediatek,mt8195-pericfg_ao";
+ data->pericfg = syscon_regmap_lookup_by_compatible(p);
+ if (IS_ERR(data->pericfg)) {
+ ret = PTR_ERR(data->pericfg);
+ goto out_runtime_disable;
+ }
}
-
- data->pericfg = infracfg;
}
platform_set_drvdata(pdev, data);
@@ -1484,8 +1487,8 @@ static const struct mtk_iommu_plat_data mt8192_data = {
static const struct mtk_iommu_plat_data mt8195_data_infra = {
.m4u_plat = M4U_MT8195,
.flags= WR_THROT_EN | DCM_DISABLE | STD_AXI_MODE |
PM_CLK_AO |
- MTK_IOMMU_TYPE_INFRA | IFA_IOMMU_PCIE_SUPPORT,
- .pericfg_comp_str = "mediatek,mt8195-pericfg_ao",
+ HAS_PERI_IOMMU1_REG | MTK_IOMMU_TYPE_INFRA |
+ IFA_IOMMU_PCIE_SUPPORT,
.inv_sel_reg = REG_MMU_INV_SEL_GEN2,
.banks_num= 5,
.banks_enable = {true, false, false, false, true},
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 5/6] dt-bindings: iommu: mediatek: Add mediatek, pericfg phandle
On 09/06/2022 12:08, AngeloGioacchino Del Regno wrote: Add property "mediatek,pericfg" to let the mtk_iommu driver retrieve a phandle to the infracfg syscon instead of performing a per-soc compatible lookup in the entire devicetree and set it as a required property for MT8195's infra IOMMU. Signed-off-by: AngeloGioacchino Del Regno Reviewd-by: Matthias Brugger --- .../devicetree/bindings/iommu/mediatek,iommu.yaml | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 4142a568b293..d5e3272a54e8 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -116,6 +116,10 @@ properties: Refer to bindings/memory-controllers/mediatek,smi-larb.yaml. It must sort according to the local arbiter index, like larb0, larb1, larb2... + mediatek,pericfg: +$ref: /schemas/types.yaml#/definitions/phandle +description: The phandle to the mediatek pericfg syscon + '#iommu-cells': const: 1 description: | @@ -183,6 +187,16 @@ allOf: required: - mediatek,infracfg + - if: + properties: +compatible: + contains: +const: mediatek,mt8195-iommu-infra + +then: + required: +- mediatek,pericfg + - if: # The IOMMUs don't have larbs. not: properties: ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 2/6] iommu: mtk_iommu: Lookup phandle to retrieve syscon to infracfg
On 09/06/2022 12:07, AngeloGioacchino Del Regno wrote:
This driver will get support for more SoCs and the list of infracfg
compatibles is expected to grow: in order to prevent getting this
situation out of control and see a long list of compatible strings,
add support to retrieve a handle to infracfg's regmap through a
new "mediatek,infracfg" phandle.
In order to keep retrocompatibility with older devicetrees, the old
way is kept in place.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index bb9dd92c9898..90685946fcbe 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -1140,22 +1140,32 @@ static int mtk_iommu_probe(struct platform_device *pdev)
data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE)) {
- switch (data->plat_data->m4u_plat) {
- case M4U_MT2712:
- p = "mediatek,mt2712-infracfg";
- break;
- case M4U_MT8173:
- p = "mediatek,mt8173-infracfg";
- break;
- default:
- p = NULL;
+ infracfg = syscon_regmap_lookup_by_phandle(dev->of_node,
"mediatek,infracfg");
+ if (IS_ERR(infracfg)) {
+ /*
+* Legacy devicetrees will not specify a phandle to
+* mediatek,infracfg: in that case, we use the older
+* way to retrieve a syscon to infra.
+*
+* This is for retrocompatibility purposes only, hence
+* no more compatibles shall be added to this.
+*/
+ switch (data->plat_data->m4u_plat) {
+ case M4U_MT2712:
+ p = "mediatek,mt2712-infracfg";
+ break;
+ case M4U_MT8173:
+ p = "mediatek,mt8173-infracfg";
+ break;
+ default:
+ p = NULL;
+ }
+
+ infracfg = syscon_regmap_lookup_by_compatible(p);
+ if (IS_ERR(infracfg))
+ return PTR_ERR(infracfg);
}
- infracfg = syscon_regmap_lookup_by_compatible(p);
-
- if (IS_ERR(infracfg))
- return PTR_ERR(infracfg);
-
ret = regmap_read(infracfg, REG_INFRA_MISC, );
if (ret)
return ret;
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/7] dt-bindings: iommu: mediatek: Add phandles for mediatek infra/pericfg
On 18/05/2022 12:04, AngeloGioacchino Del Regno wrote: Add properties "mediatek,infracfg" and "mediatek,pericfg" to let the mtk_iommu driver retrieve phandles to the infracfg and pericfg syscon(s) instead of performing a per-soc compatible lookup. Signed-off-by: AngeloGioacchino Del Regno --- .../devicetree/bindings/iommu/mediatek,iommu.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 2ae3bbad7f1a..c4af41947593 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -101,6 +101,10 @@ properties: items: - const: bclk + mediatek,infracfg: +$ref: /schemas/types.yaml#/definitions/phandle +description: The phandle to the mediatek infracfg syscon + mediatek,larbs: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 @@ -112,6 +116,10 @@ properties: Refer to bindings/memory-controllers/mediatek,smi-larb.yaml. It must sort according to the local arbiter index, like larb0, larb1, larb2... + mediatek,pericfg: +$ref: /schemas/types.yaml#/definitions/phandle +description: The phandle to the mediatek pericfg syscon + I didn't explain myself. What I was suguesting was to squash the patch that add requiered mediatek,infracfg with the patch that adds mediatk,infracfg to the binding description. And then squash the both patches adding pericfg as well. Regards, Matthias '#iommu-cells': const: 1 description: | ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 4/8] iommu: mtk_iommu: Lookup phandle to retrieve syscon to pericfg
On 17/05/2022 15:21, AngeloGioacchino Del Regno wrote:
On some SoCs (of which only MT8195 is supported at the time of writing),
the "R" and "W" (I/O) enable bits for the IOMMUs are in the pericfg_ao
register space and not in the IOMMU space: as it happened already with
infracfg, it is expected that this list will grow.
Instead of specifying pericfg compatibles on a per-SoC basis, following
what was done with infracfg, let's lookup the syscon by phandle instead.
Also following the previous infracfg change, add a warning for outdated
devicetrees, in hope that the user will take action.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index cfaaa98d2b50..c7e2d836199e 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -138,6 +138,8 @@
/* PM and clock always on. e.g. infra iommu */
#define PM_CLK_AO BIT(15)
#define IFA_IOMMU_PCIE_SUPPORTBIT(16)
+/* IOMMU I/O (r/w) is enabled using PERICFG_IOMMU_1 register */
+#define HAS_PERI_IOMMU1_REGBIT(17)
#define MTK_IOMMU_HAS_FLAG_MASK(pdata, _x, mask) \
pdata)->flags) & (mask)) == (_x))
@@ -187,7 +189,6 @@ struct mtk_iommu_plat_data {
u32 flags;
u32 inv_sel_reg;
- char *pericfg_comp_str;
struct list_head*hw_list;
unsigned intiova_region_nr;
const struct mtk_iommu_iova_region *iova_region;
@@ -1214,14 +1215,19 @@ static int mtk_iommu_probe(struct platform_device *pdev)
goto out_runtime_disable;
}
} else if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_INFRA) &&
- data->plat_data->pericfg_comp_str) {
- infracfg =
syscon_regmap_lookup_by_compatible(data->plat_data->pericfg_comp_str);
- if (IS_ERR(infracfg)) {
- ret = PTR_ERR(infracfg);
- goto out_runtime_disable;
- }
+ MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_PERI_IOMMU1_REG)) {
+ data->pericfg = syscon_regmap_lookup_by_phandle(dev->of_node,
"mediatek,pericfg");
+ if (IS_ERR(data->pericfg)) {
+ dev_warn(dev, "Cannot find phandle to mediatek,pericfg:"
+ " Please update your devicetree.\n");
- data->pericfg = infracfg;
+ p = "mediatek,mt8195-pericfg_ao";
+ data->pericfg = syscon_regmap_lookup_by_compatible(p);
+ if (IS_ERR(data->pericfg)) {
+ ret = PTR_ERR(data->pericfg);
+ goto out_runtime_disable;
+ }
+ }
}
platform_set_drvdata(pdev, data);
@@ -1480,8 +1486,8 @@ static const struct mtk_iommu_plat_data mt8192_data = {
static const struct mtk_iommu_plat_data mt8195_data_infra = {
.m4u_plat = M4U_MT8195,
.flags= WR_THROT_EN | DCM_DISABLE | STD_AXI_MODE |
PM_CLK_AO |
- MTK_IOMMU_TYPE_INFRA | IFA_IOMMU_PCIE_SUPPORT,
- .pericfg_comp_str = "mediatek,mt8195-pericfg_ao",
+ HAS_PERI_IOMMU1_REG | MTK_IOMMU_TYPE_INFRA |
+ IFA_IOMMU_PCIE_SUPPORT,
.inv_sel_reg = REG_MMU_INV_SEL_GEN2,
.banks_num= 5,
.banks_enable = {true, false, false, false, true},
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/8] dt-bindings: iommu: mediatek: Add mediatek,infracfg phandle
On 17/05/2022 15:21, AngeloGioacchino Del Regno wrote: Add property "mediatek,infracfg" to let the mtk_iommu driver retrieve a phandle to the infracfg syscon instead of performing a per-soc compatible lookup. Signed-off-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 2ae3bbad7f1a..78c72c22740b 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -101,6 +101,10 @@ properties: items: - const: bclk + mediatek,infracfg: +$ref: "/schemas/types.yaml#/definitions/phandle" +description: The phandle to the mediatek infracfg syscon + mediatek,larbs: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 I think we can squash patch 7 in here. Same holds for pericfg Regards, Matthias ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] iommu: mtk_iommu: Add support for MT6795 Helio X10 M4Us
On 17/05/2022 11:26, AngeloGioacchino Del Regno wrote:
Il 17/05/22 11:08, Yong Wu ha scritto:
On Fri, 2022-05-13 at 17:14 +0200, AngeloGioacchino Del Regno wrote:
Add support for the M4Us found in the MT6795 Helio X10 SoC.
Signed-off-by: AngeloGioacchino Del Regno <
angelogioacchino.delre...@collabora.com>
---
drivers/iommu/mtk_iommu.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 71b2ace74cd6..3d802dd3f377 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -157,6 +157,7 @@
enum mtk_iommu_plat {
M4U_MT2712,
M4U_MT6779,
+ M4U_MT6795,
M4U_MT8167,
M4U_MT8173,
M4U_MT8183,
@@ -953,7 +954,8 @@ static int mtk_iommu_hw_init(const struct
mtk_iommu_data *data, unsigned int ban
* Global control settings are in bank0. May re-init these
global registers
* since no sure if there is bank0 consumers.
*/
- if (data->plat_data->m4u_plat == M4U_MT8173) {
+ if (data->plat_data->m4u_plat == M4U_MT6795 ||
+ data->plat_data->m4u_plat == M4U_MT8173) {
regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
} else {
@@ -1138,6 +1140,9 @@ static int mtk_iommu_probe(struct
platform_device *pdev)
case M4U_MT2712:
p = "mediatek,mt2712-infracfg";
break;
+ case M4U_MT6795:
+ p = "mediatek,mt6795-infracfg";
+ break;
case M4U_MT8173:
p = "mediatek,mt8173-infracfg";
break;
@@ -1404,6 +1409,18 @@ static const struct mtk_iommu_plat_data
mt6779_data = {
.larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
};
+static const struct mtk_iommu_plat_data mt6795_data = {
+ .m4u_plat = M4U_MT6795,
+ .flags = HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
+ HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM,
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
+ .banks_num = 1,
+ .banks_enable = {true},
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
+ .larbid_remap = {{0}, {1}, {2}, {3}, {4}}, /* Linear mapping.
*/
+};
This is nearly same with mt8173_data. mt8173 has one more larb than
mt6795, its larbid_remap is also ok for mt6795.
I think that we should be explicit about the larbid_remap property,
since mt6795 has one less larb, we should explicitly say that like
I did there... that's only for human readability I admit ... but,
still, I wouldn't want to see people thinking that MT6795 has 6 LARBs
because they've read that larbid_remap having 6 entries.
thus it looks we could use mt8173 as the backward compatible.
compatible = "mediatek,mt6795-m4u",
"mediatek,mt8173-m4u";
After this, the only thing is about "mediatek,mt6795-infracfg". we have
to try again with mediatek,mt6795-infracfg after mediatek,mt8173-
infracfg fail. I think we should allow the backward case in 4GB mode
judgment if we have.
What's your opinion? or some other suggestion?
Thanks.
I know, I may have a plan for that, but I wanted to have a good reason to
propose such a thing, as if it's just about two SoCs needing that, there
would be no good reason to get things done differently.
...so, in order to provide a good cleanup, we have two possible roads to
follow here: either we add a generic "mediatek,infracfg" compatible to the
infra node (but I don't like that), or we can do it like it was previously
done in mtk-pm-domains.c (I prefer that approach):
iommu: iommu@somewhere {
... something ...
mediatek,infracfg = <>;
};
infracfg = syscon_regmap_lookup_by_compatible(node, "mediatek,infracfg");
if (IS_ERR(infracfg)) {
/* try with the older way */
switch (...) {
case p = "mediatek,mt2712-infracfg";
... blah blah ...
}
/* legacy also failed, ouch! */
if (IS_ERR(infracfg))
return PTR_ERR(infracfg);
}
ret = regmap_read ... etc etc etc
I prefer that approach as well.
Regards,
Matthias
Cheers,
Angelo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 00/36] MT8195 and MT8186 IOMMU SUPPORT
On 03/05/2022 09:13, Yong Wu wrote: This patchset adds MT8195 and MT8186 iommu support. MT8195 have 3 IOMMU HWs. 2 IOMMU HW is for multimedia, and 1 IOMMU HW is for infra-master, like PCIe/USB. About the 2 MM IOMMU HW, something like this: IOMMU(VDO) IOMMU(VPP) | | SMI_COMMON(VDO) SMI_COMMON(VPP) --- | | ... | | ... larb0 larb2 ...larb1 larb3... these two MM IOMMU HW share a pgtable. About the INFRA IOMMU, it don't have larbs, the master connects the iommu directly. It use a independent pgtable. Also, mt8195 IOMMU bank supports. Normally the IOMMU register size only is 0x1000. In this IOMMU HW, the register size is 5 * 0x1000. each 0x1000 is a bank. the banks' register look like this: |bank0 | bank1 | bank2 | bank3 | bank4| |global | |control| null |regs | - |bank |bank |bank |bank |bank | |regs |regs |regs |regs |regs | | | | | | | - All the banks share some global control registers, and each bank have its special bank registers, like pgtable base register, tlb operation registers, the fault status registers. In mt8195, we enable this bank feature for infra iommu, We put PCIe in bank0 and USB in bank4. they have independent pgtable. MT8186 is based on MT8195, it just has two patches. Change note: v7: 1) Update the changes from Matthias. like add a new function for readability. 2) Add mt8186 into this patchset, It may be helpful for maintainer to apply. For the whole series: Reviewed-by: Matthias Brugger v6: https://lore.kernel.org/linux-iommu/20220407075726.17771-1-yong...@mediatek.com/ Rebase on v5.18-rc1. v5: https://lore.kernel.org/linux-iommu/20220217113453.13658-1-yong...@mediatek.com 1) Base on next-20220216 2) Remove a patch for kmalloc for protect buffer. keep the kzalloc for it. 3) minor fix from AngeloGioacchino, like rename the error label name (data_unlock to err_unlock). Note, keep the TODO for component compare_of[26/34]. v4: https://lore.kernel.org/linux-iommu/20220125085634.17972-1-yong...@mediatek.com/ 1) Base on v5.16-rc1 2) Base on tlb logic 2 patchset, some patches in v3 has already gone through that patchset. 3) Due to the unreadable union for v1/v2(comment in 26/33 of v3), I separate mtk_iommu_data for v1 and v2 totally, then remove mtk_iommu.h. please see patch[26/35][27/35]. 4) add two mutex for the internal data. patch[6/35][7/35]. 5) add a new flag PM_CLK_AO. v3: https://lore.kernel.org/linux-mediatek/20210923115840.17813-1-yong...@mediatek.com/ 1) base on v5.15-rc1 2) Adjust devlink with smi-common, not use the property(sub-sommon). 3) Adjust tlb_flush_all flow, a) Fix tlb_flush_all only is supported in bank0. b) add tlb-flush-all in the resume callback. c) remove the pm status checking in tlb-flush-all. The reason are showed in the commit message. 4) Allow IOMMU_DOMAIN_UNMANAGED since PCIe VFIO use that. 5) Fix a clk warning and a null abort when unbind the iommu driver. v2: https://lore.kernel.org/linux-mediatek/20210813065324.29220-1-yong...@mediatek.com/ 1) Base on v5.14-rc1. 2) Fix build fail for arm32. 3) Fix dt-binding issue from Rob. 4) Fix the bank issue when tlb flush. v1 always use bank->base. 5) adjust devlink with smi-common since the node may be smi-sub-common. 6) other changes: like reword some commit message(removing many "This patch..."); seperate serveral patches. v1: https://lore.kernel.org/linux-mediatek/20210630023504.18177-1-yong...@mediatek.com/ Base on v5.13-rc1 Yong Wu (36): dt-bindings: mediatek: mt8195: Add binding for MM IOMMU dt-bindings: mediatek: mt8195: Add binding for infra IOMMU dt-bindings: mediatek: mt8186: Add binding for MM iommu iommu/mediatek: Fix 2 HW sharing pgtable issue iommu/mediatek: Add list_del in mtk_iommu_remove iommu/mediatek: Remove clk_disable in mtk_iommu_remove iommu/mediatek: Add mutex for m4u_group and m4u_dom in data iommu/mediatek: Add mutex for data in the mtk_iommu_domain iommu/mediatek: Adapt sharing and non-sharing pgtable case iommu/mediatek: Add 12G~16G support for multi domains iommu/mediatek: Add a flag DCM_DISABLE iommu/mediatek: Add a flag STD_AXI_MODE iommu/mediatek: Remove the granule in the tlb flush iommu/mediatek: Always enable output PA over 32bits in isr iommu/mediatek: Add SUB_COMMON_3BITS flag iommu/mediatek: Add IOMMU_TYPE flag iommu/mediatek: Contain MM IOMMU flow with the MM TYPE iommu/mediatek: Adjust dev
Re: [PATCH v6 11/34] iommu/mediatek: Add a flag NON_STD_AXI
On 07/04/2022 09:57, Yong Wu wrote:
Add a new flag NON_STD_AXI, All the previous SoC support this flag.
Prepare for adding infra and apu iommu which don't support this.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 92f172a772d1..e7008a20ec74 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -122,6 +122,7 @@
#define IOVA_34_ENBIT(8)
#define SHARE_PGTABLE BIT(9) /* 2 HW share pgtable */
#define DCM_DISABLE BIT(10)
+#define NOT_STD_AXI_MODE BIT(11)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
pdata)->flags) & (_x)) == (_x))
@@ -785,7 +786,8 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
regval = 0;
} else {
regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
- regval &= ~F_MMU_STANDARD_AXI_MODE_MASK;
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, NOT_STD_AXI_MODE))
+ regval &= ~F_MMU_STANDARD_AXI_MODE_MASK;
That means that for mt8195 infra we write back the very same value we read from
REG_MMU_MISC_CTRL. Is this necessary?
Maybe we can come up with a different flag called STD_AXI_MODE and use something
like
} else if (!MTK_IOMMU_HAS_FLAG(data->plat_data, \
STD_AXI_MODE)) {
Reason is that it makes more sense to add a flag for one specific iommu instead
of adding a flag to the common case (iommu is not following standard AXI protocol).
What do you think?
Regards,
Matthias
if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_WR_EN))
regval &= ~F_MMU_IN_ORDER_WR_EN_MASK;
}
@@ -1058,7 +1060,8 @@ static const struct dev_pm_ops mtk_iommu_pm_ops = {
static const struct mtk_iommu_plat_data mt2712_data = {
.m4u_plat = M4U_MT2712,
- .flags= HAS_4GB_MODE | HAS_BCLK | HAS_VLD_PA_RNG |
SHARE_PGTABLE,
+ .flags= HAS_4GB_MODE | HAS_BCLK | HAS_VLD_PA_RNG |
SHARE_PGTABLE |
+ NOT_STD_AXI_MODE,
.hw_list = ,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.iova_region = single_domain,
@@ -1068,7 +1071,8 @@ static const struct mtk_iommu_plat_data mt2712_data = {
static const struct mtk_iommu_plat_data mt6779_data = {
.m4u_plat = M4U_MT6779,
- .flags = HAS_SUB_COMM | OUT_ORDER_WR_EN | WR_THROT_EN,
+ .flags = HAS_SUB_COMM | OUT_ORDER_WR_EN | WR_THROT_EN |
+NOT_STD_AXI_MODE,
.inv_sel_reg = REG_MMU_INV_SEL_GEN2,
.iova_region = single_domain,
.iova_region_nr = ARRAY_SIZE(single_domain),
@@ -1077,7 +1081,7 @@ static const struct mtk_iommu_plat_data mt6779_data = {
static const struct mtk_iommu_plat_data mt8167_data = {
.m4u_plat = M4U_MT8167,
- .flags= RESET_AXI | HAS_LEGACY_IVRP_PADDR,
+ .flags= RESET_AXI | HAS_LEGACY_IVRP_PADDR | NOT_STD_AXI_MODE,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.iova_region = single_domain,
.iova_region_nr = ARRAY_SIZE(single_domain),
@@ -1087,7 +1091,7 @@ static const struct mtk_iommu_plat_data mt8167_data = {
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
.flags= HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
- HAS_LEGACY_IVRP_PADDR,
+ HAS_LEGACY_IVRP_PADDR | NOT_STD_AXI_MODE,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.iova_region = single_domain,
.iova_region_nr = ARRAY_SIZE(single_domain),
@@ -1106,7 +1110,7 @@ static const struct mtk_iommu_plat_data mt8183_data = {
static const struct mtk_iommu_plat_data mt8192_data = {
.m4u_plat = M4U_MT8192,
.flags = HAS_BCLK | HAS_SUB_COMM | OUT_ORDER_WR_EN |
- WR_THROT_EN | IOVA_34_EN,
+ WR_THROT_EN | IOVA_34_EN | NOT_STD_AXI_MODE,
.inv_sel_reg= REG_MMU_INV_SEL_GEN2,
.iova_region= mt8192_multi_dom,
.iova_region_nr = ARRAY_SIZE(mt8192_multi_dom),
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 15/34] iommu/mediatek: Add IOMMU_TYPE flag
On 07/04/2022 09:57, Yong Wu wrote:
Add IOMMU_TYPE definition. In the mt8195, we have another IOMMU_TYPE:
infra iommu, also there will be another APU_IOMMU, thus, use 2bits for the
IOMMU_TYPE.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 84d661e0b371..642949aad47e 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -126,9 +126,17 @@
#define SHARE_PGTABLE BIT(10) /* 2 HW share pgtable */
#define DCM_DISABLE BIT(11)
#define NOT_STD_AXI_MODE BIT(12)
+/* 2 bits: iommu type */
+#define MTK_IOMMU_TYPE_MM (0x0 << 13)
+#define MTK_IOMMU_TYPE_INFRA (0x1 << 13)
+#define MTK_IOMMU_TYPE_MASK(0x3 << 13)
-#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
- pdata)->flags) & (_x)) == (_x))
+#define MTK_IOMMU_HAS_FLAG(pdata, _x) (!!(((pdata)->flags) & (_x)))
That could be:
MTK_IOMMU_HAS_FLAG(pdata, _x) \
MTK_IOMMU_HAS_FLAG_MASK(pdata, _x, _x)
+
+#define MTK_IOMMU_HAS_FLAG_MASK(pdata, _x, mask) \
+ pdata)->flags) & (mask)) == (_x))
+#define MTK_IOMMU_IS_TYPE(pdata, _x) MTK_IOMMU_HAS_FLAG_MASK(pdata, _x,\
+ MTK_IOMMU_TYPE_MASK)
struct mtk_iommu_domain {
struct io_pgtable_cfg cfg;
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 31/34] iommu/mediatek: Get the proper bankid for multi banks
On 07/04/2022 09:57, Yong Wu wrote:
We preassign some ports in a special bank via the new defined
banks_portmsk. Put it in the plat_data means it is not expected to be
adjusted dynamically.
If the iommu id in the iommu consumer's dtsi node is inside this
banks_portmsk, then we switch it to this special iommu bank, and
initialise the IOMMU bank HW.
Each a bank has the independent pgtable(4GB iova range). Each a bank
is a independent iommu domain/group. Currently we don't separate different
iova ranges inside a bank.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 39 ---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 0828cff97625..d42b3d35a36e 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -191,6 +191,7 @@ struct mtk_iommu_plat_data {
u8 banks_num;
boolbanks_enable[MTK_IOMMU_BANK_MAX];
+ unsigned intbanks_portmsk[MTK_IOMMU_BANK_MAX];
unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
};
@@ -467,6 +468,30 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static unsigned int mtk_iommu_get_bank_id(struct device *dev,
+ const struct mtk_iommu_plat_data
*plat_data)
+{
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ unsigned int i, portmsk = 0, bankid = 0;
+
+ if (plat_data->banks_num == 1)
+ return bankid;
+
+ for (i = 0; i < fwspec->num_ids; i++)
+ portmsk |= BIT(MTK_M4U_TO_PORT(fwspec->ids[i]));
+
+ for (i = 0; i < plat_data->banks_num && i < MTK_IOMMU_BANK_MAX; i++) {
+ if (!plat_data->banks_enable[i])
+ continue;
+
+ if (portmsk & plat_data->banks_portmsk[i]) {
+ bankid = i;
+ break;
+ }
+ }
+ return bankid; /* default is 0 */
+}
+
static int mtk_iommu_get_iova_region_id(struct device *dev,
const struct mtk_iommu_plat_data
*plat_data)
{
@@ -619,13 +644,14 @@ static int mtk_iommu_attach_device(struct iommu_domain
*domain,
struct list_head *hw_list = data->hw_list;
struct device *m4udev = data->dev;
struct mtk_iommu_bank_data *bank;
- unsigned int bankid = 0;
+ unsigned int bankid;
int ret, region_id;
region_id = mtk_iommu_get_iova_region_id(dev, data->plat_data);
if (region_id < 0)
return region_id;
+ bankid = mtk_iommu_get_bank_id(dev, data->plat_data);
mutex_lock(>mutex);
if (!dom->bank) {
/* Data is in the frstdata in sharing pgtable case. */
@@ -802,6 +828,7 @@ static struct iommu_group *mtk_iommu_device_group(struct
device *dev)
struct mtk_iommu_data *c_data = dev_iommu_priv_get(dev), *data;
struct list_head *hw_list = c_data->hw_list;
struct iommu_group *group;
+ unsigned int bankid, groupid;
int regionid;
data = mtk_iommu_get_frst_data(hw_list);
@@ -812,12 +839,18 @@ static struct iommu_group *mtk_iommu_device_group(struct
device *dev)
if (regionid < 0)
return ERR_PTR(regionid);
+ bankid = mtk_iommu_get_bank_id(dev, data->plat_data);
I think code readability would be improved if we add a new function like
mtk_iommu_get_id which call mtk_iommu_get_bankid and if necessary
mtk_iommu_get_regionid.
mutex_lock(>mutex);
- group = data->m4u_group[regionid];
+ /*
+* If the bank function is enabled, each a bank is a iommu group/domain.
+* otherwise, each a iova region is a iommu group/domain.
While at it:
"If the bank function is enabled, each bank is a iommu group/domain. Otherwise,
each iova region is a iommu group/domain."
Regards,
Matthias
+*/
+ groupid = bankid ? bankid : regionid;
+ group = data->m4u_group[groupid];
if (!group) {
group = iommu_group_alloc();
if (!IS_ERR(group))
- data->m4u_group[regionid] = group;
+ data->m4u_group[groupid] = group;
} else {
iommu_group_ref_get(group);
}
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 2/2] iommu/mediatek: Add mt8186 iommu support
On 23/02/2022 08:24, Yong Wu wrote:
Add mt8186 iommu supports.
Signed-off-by: Anan Sun
Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d9ca9ffe404c..174a2f3bd68a 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -160,6 +160,7 @@ enum mtk_iommu_plat {
M4U_MT8167,
M4U_MT8173,
M4U_MT8183,
+ M4U_MT8186,
M4U_MT8192,
M4U_MT8195,
};
@@ -1438,6 +1439,21 @@ static const struct mtk_iommu_plat_data mt8183_data = {
.larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
};
+static const struct mtk_iommu_plat_data mt8186_data_mm = {
+ .m4u_plat = M4U_MT8186,
+ .flags = HAS_BCLK | HAS_SUB_COMM_2BITS | OUT_ORDER_WR_EN |
+ WR_THROT_EN | IOVA_34_EN | NOT_STD_AXI_MODE |
+ MTK_IOMMU_TYPE_MM,
+ .larbid_remap = {{0}, {1, MTK_INVALID_LARBID, 8}, {4}, {7}, {2}, {9,
11, 19, 20},
+ {MTK_INVALID_LARBID, 14, 16},
+ {MTK_INVALID_LARBID, 13, MTK_INVALID_LARBID, 17}},
+ .inv_sel_reg= REG_MMU_INV_SEL_GEN2,
+ .banks_num = 1,
+ .banks_enable = {true},
+ .iova_region= mt8192_multi_dom,
+ .iova_region_nr = ARRAY_SIZE(mt8192_multi_dom),
+};
+
static const struct mtk_iommu_plat_data mt8192_data = {
.m4u_plat = M4U_MT8192,
.flags = HAS_BCLK | HAS_SUB_COMM_2BITS | OUT_ORDER_WR_EN |
@@ -1507,6 +1523,7 @@ static const struct of_device_id mtk_iommu_of_ids[] = {
{ .compatible = "mediatek,mt8167-m4u", .data = _data},
{ .compatible = "mediatek,mt8173-m4u", .data = _data},
{ .compatible = "mediatek,mt8183-m4u", .data = _data},
+ { .compatible = "mediatek,mt8186-iommu-mm",.data =
_data_mm}, /* mm: m4u */
{ .compatible = "mediatek,mt8192-m4u", .data = _data},
{ .compatible = "mediatek,mt8195-iommu-infra", .data =
_data_infra},
{ .compatible = "mediatek,mt8195-iommu-vdo", .data =
_data_vdo},
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/2] dt-bindings: mediatek: mt8186: Add binding for MM iommu
On 23/02/2022 08:24, Yong Wu wrote: Add mt8186 iommu binding. "-mm" means the iommu is for Multimedia. Signed-off-by: Yong Wu Acked-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Reviewed-by: Matthias Brugger --- .../bindings/iommu/mediatek,iommu.yaml| 4 + .../dt-bindings/memory/mt8186-memory-port.h | 217 ++ 2 files changed, 221 insertions(+) create mode 100644 include/dt-bindings/memory/mt8186-memory-port.h diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index c528a299afa9..d78df484bb76 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -76,6 +76,7 @@ properties: - mediatek,mt8167-m4u # generation two - mediatek,mt8173-m4u # generation two - mediatek,mt8183-m4u # generation two + - mediatek,mt8186-iommu-mm # generation two - mediatek,mt8192-m4u # generation two - mediatek,mt8195-iommu-vdo# generation two - mediatek,mt8195-iommu-vpp# generation two @@ -120,6 +121,7 @@ properties: dt-binding/memory/mt8167-larb-port.h for mt8167, dt-binding/memory/mt8173-larb-port.h for mt8173, dt-binding/memory/mt8183-larb-port.h for mt8183, + dt-binding/memory/mt8186-memory-port.h for mt8186, dt-binding/memory/mt8192-larb-port.h for mt8192. dt-binding/memory/mt8195-memory-port.h for mt8195. @@ -141,6 +143,7 @@ allOf: - mediatek,mt2701-m4u - mediatek,mt2712-m4u - mediatek,mt8173-m4u + - mediatek,mt8186-iommu-mm - mediatek,mt8192-m4u - mediatek,mt8195-iommu-vdo - mediatek,mt8195-iommu-vpp @@ -153,6 +156,7 @@ allOf: properties: compatible: enum: +- mediatek,mt8186-iommu-mm - mediatek,mt8192-m4u - mediatek,mt8195-iommu-vdo - mediatek,mt8195-iommu-vpp diff --git a/include/dt-bindings/memory/mt8186-memory-port.h b/include/dt-bindings/memory/mt8186-memory-port.h new file mode 100644 index ..bda265725870 --- /dev/null +++ b/include/dt-bindings/memory/mt8186-memory-port.h @@ -0,0 +1,217 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2022 MediaTek Inc. + * + * Author: Anan Sun + * Author: Yong Wu + */ +#ifndef _DT_BINDINGS_MEMORY_MT8186_LARB_PORT_H_ +#define _DT_BINDINGS_MEMORY_MT8186_LARB_PORT_H_ + +#include + +/* + * MM IOMMU supports 16GB dma address. We separate it to four ranges: + * 0 ~ 4G; 4G ~ 8G; 8G ~ 12G; 12G ~ 16G, we could adjust these masters + * locate in anyone bank. BUT: + * a) Make sure all the ports inside a larb are in one range. + * b) The iova of any master can NOT cross the 4G/8G/12G boundary. + * + * This is the suggested mapping in this SoC: + * + * modulesdma-address-region larbs-ports + * disp 0 ~ 4G larb0/1/2 + * vcodec 4G ~ 8G larb4/7 + * cam/mdp 8G ~ 12G the other larbs. + * N/A 12G ~ 16G + * CCU0 0x24000_ ~ 0x243ff_ larb13: port 9/10 + * CCU1 0x24400_ ~ 0x247ff_ larb14: port 4/5 + */ + +/* MM IOMMU ports */ +/* LARB 0 -- MMSYS */ +#define IOMMU_PORT_L0_DISP_POSTMASK0 MTK_M4U_ID(0, 0) +#define IOMMU_PORT_L0_REVERSED MTK_M4U_ID(0, 1) +#define IOMMU_PORT_L0_OVL_RDMA0MTK_M4U_ID(0, 2) +#define IOMMU_PORT_L0_DISP_FAKE0 MTK_M4U_ID(0, 3) + +/* LARB 1 -- MMSYS */ +#define IOMMU_PORT_L1_DISP_RDMA1 MTK_M4U_ID(1, 0) +#define IOMMU_PORT_L1_OVL_2L_RDMA0 MTK_M4U_ID(1, 1) +#define IOMMU_PORT_L1_DISP_RDMA0 MTK_M4U_ID(1, 2) +#define IOMMU_PORT_L1_DISP_WDMA0 MTK_M4U_ID(1, 3) +#define IOMMU_PORT_L1_DISP_FAKE1 MTK_M4U_ID(1, 4) + +/* LARB 2 -- MMSYS */ +#define IOMMU_PORT_L2_MDP_RDMA0MTK_M4U_ID(2, 0) +#define IOMMU_PORT_L2_MDP_RDMA1MTK_M4U_ID(2, 1) +#define IOMMU_PORT_L2_MDP_WROT0MTK_M4U_ID(2, 2) +#define IOMMU_PORT_L2_MDP_WROT1MTK_M4U_ID(2, 3) +#define IOMMU_PORT_L2_DISP_FAKE0 MTK_M4U_ID(2, 4) + +/* LARB 4 -- VDEC */ +#define IOMMU_PORT_L4_HW_VDEC_MC_EXT MTK_M4U_ID(4, 0) +#define IOMMU_PORT_L4_HW_VDEC_UFO_EXT MTK_M4U_ID(4, 1) +#define IOMMU_PORT_L4_HW_VDEC_PP_EXT MTK_M4U_ID(4, 2) +#define IOMMU_PORT_L4_HW_VDEC_PRED_RD_EXT MTK_M4U_ID(4, 3) +#define IOMMU_PORT_L4_HW_VDEC_PRED_WR_EXT MTK_M4U_ID(4, 4) +#define IOMMU_PORT_L4_HW_VDEC_PPWRAP_EXT MTK_M4U_ID(4, 5) +#define IOMMU_PORT_L4_HW_VDEC_TILE_EXT MTK_M4U_ID(4, 6) +#define IOMMU_PORT_L4_HW_VDEC_VLD_EXT MTK_M4U_ID(4, 7) +#define IOMMU_PORT_L4_HW_VDEC_VLD2_EXT MTK_M4U_ID(4, 8) +#define IOMMU_PORT_L4_HW_VDEC_AVC_MV_EXT MTK_M4U_ID(4, 9
Re: [PATCH v10 02/13] iommu/mediatek-v1: Free the existed fwspec if the master dev already has
On 28/01/2022 13:45, Mauro Carvalho Chehab wrote:
Em Fri, 28 Jan 2022 13:40:55 +0100
Mauro Carvalho Chehab escreveu:
Hi Matthias/Yong,
Are you ok if this patch gets merged via the media tree together with the
remaining series, or do you prefer to apply it via SoC tree instead?
Same questions for other patches touching files outside drivers/media
on this pull request:
https://patchwork.kernel.org/project/linux-mediatek/patch/7af52d61-47c7-581d-62ed-76a7f8315...@xs4all.nl/
Looks good to me.
Please let me know once you accepted the pull request and I'll queue the DTS
related changes from this series.
Regards,
Matthias
Like those:
0004-0013-iommu-mediatek-v1-Free-the-existed-fwspec-if-the-mas.patch
0005-0013-iommu-mediatek-Return-ENODEV-if-the-device-is-NULL.patch
0006-0013-iommu-mediatek-Add-probe_defer-for-smi-larb.patch
0007-0013-iommu-mediatek-Add-device_link-between-the-consumer-.patch
Regards,
Mauro
Regards,
Mauro
Em Mon, 17 Jan 2022 15:04:59 +0800
Yong Wu escreveu:
When the iommu master device enters of_iommu_xlate, the ops may be
NULL(iommu dev is defered), then it will initialize the fwspec here:
[] (dev_iommu_fwspec_set) from []
(iommu_fwspec_init+0xbc/0xd4)
[] (iommu_fwspec_init) from []
(of_iommu_xlate+0x7c/0x12c)
[] (of_iommu_xlate) from []
(of_iommu_configure+0x144/0x1e8)
BUT the mtk_iommu_v1.c only supports arm32, the probing flow still is a bit
weird. We always expect create the fwspec internally. otherwise it will
enter here and return fail.
static int mtk_iommu_create_mapping(struct device *dev,
struct of_phandle_args *args)
{
...
if (!fwspec) {
} else if (dev_iommu_fwspec_get(dev)->ops != _iommu_ops) {
>>Enter here. return fail.
return -EINVAL;
}
...
}
Thus, Free the existed fwspec if the master device already has fwspec.
This issue is reported at:
https://lore.kernel.org/linux-mediatek/trinity-7d9ebdc9-4849-4d93-bfb5-429dcb4ee449-1626253158870@3c-app-gmx-bs01/
Reported-by: Frank Wunderlich
Tested-by: Frank Wunderlich # BPI-R2/MT7623
Signed-off-by: Yong Wu
Acked-by: Joerg Roedel
Acked-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu_v1.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index be22fcf988ce..1467ba1e4417 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -425,6 +425,15 @@ static struct iommu_device *mtk_iommu_probe_device(struct
device *dev)
struct mtk_iommu_data *data;
int err, idx = 0;
+ /*
+* In the deferred case, free the existed fwspec.
+* Always initialize the fwspec internally.
+*/
+ if (fwspec) {
+ iommu_fwspec_free(dev);
+ fwspec = dev_iommu_fwspec_get(dev);
+ }
+
while (!of_parse_phandle_with_args(dev->of_node, "iommus",
"#iommu-cells",
idx, _spec)) {
Thanks,
Mauro
Thanks,
Mauro
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v10 00/13] Clean up "mediatek,larb"
On 17/01/2022 11:27, AngeloGioacchino Del Regno wrote: Il 17/01/22 08:04, Yong Wu ha scritto: MediaTek IOMMU block diagram always like below: M4U | smi-common | - | | ... | | larb1 larb2 | | vdec venc All the consumer connect with smi-larb, then connect with smi-common. When the consumer works, it should enable the smi-larb's power which also need enable the smi-common's power firstly. Thus, Firstly, use the device link connect the consumer and the smi-larbs. then add device link between the smi-larb and smi-common. After adding the device_link, then "mediatek,larb" property can be removed. the iommu consumer don't need call the mtk_smi_larb_get/put to enable the power and clock of smi-larb and smi-common. Base on the media branch [1] and a jpeg dtbinding patchset[2] that already got the necessary R-b. [1] git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.18d [2] https://lore.kernel.org/linux-mediatek/20211206130425.184420-1-hsi...@chromium.org/ Change notes: v10: a) Rebase on the media tree. Respin the "media: mtk-vcodec:" patches. b) Add Joerg's Ack for iommu patches. v9: https://lore.kernel.org/linux-mediatek/2022105509.12010-1-yong...@mediatek.com/ 1) Add return -ENODEV when the dev is null. 2) Add more strict about the case that a iommu consume device use the ports in different larbs. Don't allow this case. 3) Remove two codec interface: mtk_vcodec_release_enc/dec_pm since it only has one line now. v8: https://lore.kernel.org/linux-mediatek/20210929013719.25120-1-yong...@mediatek.com/ 1) Rebase on v5.15-rc1. 2) Don't rebase the below mdp patchset that may still need more discuss. https://lore.kernel.org/linux-mediatek/20210709022324.1607884-1-ei...@chromium.org/ 3) Add Frank's Tested-by. Remove Dafna's Tested-by as he requested. v7: https://lore.kernel.org/linux-mediatek/20210730025238.22456-1-yong...@mediatek.com/ 1) Fix a arm32 boot fail issue. reported from Frank. 2) Add a return fail in the mtk drm. suggested by Dafna. v6: https://lore.kernel.org/linux-mediatek/20210714025626.5528-1-yong...@mediatek.com/ 1) rebase on v5.14-rc1. 2) Fix the issue commented in v5 from Dafna and Hsin-Yi. 3) Remove the patches about using pm_runtime_resume_and_get since they have already been merged by other patches. v5: https://lore.kernel.org/linux-mediatek/20210410091128.31823-1-yong...@mediatek.com/ 1) Base v5.12-rc2. 2) Remove changing the mtk-iommu to module_platform_driver patch, It have already been a independent patch. v4: https://lore.kernel.org/linux-mediatek/1590826218-23653-1-git-send-email-yong...@mediatek.com/ base on v5.7-rc1. 1) Move drm PM patch before smi patchs. 2) Change builtin_platform_driver to module_platform_driver since we may need build as module. 3) Rebase many patchset as above. v3: https://lore.kernel.org/linux-iommu/1567503456-24725-1-git-send-email-yong...@mediatek.com/ 1) rebase on v5.3-rc1 and the latest mt8183 patchset. 2) Use device_is_bound to check whether the driver is ready from Matthias. 3) Add DL_FLAG_STATELESS flag when calling device_link_add and explain the reason in the commit message[3/14]. 4) Add a display patch[12/14] into this series. otherwise it may affect display HW fastlogo even though it don't happen in mt8183. v2: https://lore.kernel.org/linux-iommu/1560171313-28299-1-git-send-email-yong...@mediatek.com/ 1) rebase on v5.2-rc1. 2) Move adding device_link between the consumer and smi-larb into iommu_add_device from Robin. 3) add DL_FLAG_AUTOREMOVE_CONSUMER even though the smi is built-in from Evan. 4) Remove the shutdown callback in iommu. v1: https://lore.kernel.org/linux-iommu/1546318276-18993-1-git-send-email-yong...@mediatek.com/ Yong Wu (12): dt-binding: mediatek: Get rid of mediatek,larb for multimedia HW iommu/mediatek-v1: Free the existed fwspec if the master dev already has iommu/mediatek: Return ENODEV if the device is NULL iommu/mediatek: Add probe_defer for smi-larb iommu/mediatek: Add device_link between the consumer and the larb devices media: mtk-jpeg: Get rid of mtk_smi_larb_get/put media: mtk-mdp: Get rid of mtk_smi_larb_get/put drm/mediatek: Get rid of mtk_smi_larb_get/put media: mtk-vcodec: Get rid of mtk_smi_larb_get/put memory: mtk-smi: Get rid of mtk_smi_larb_get/put arm: dts: mediatek: Get rid of mediatek,larb for MM nodes arm64: dts: mediatek: Get rid of mediatek,larb for MM nodes Yongqiang Niu (1): drm/mediatek: Add pm runtime support for ovl and rdma .../display/mediatek/mediatek,disp.txt | 9 .../media/mediatek,vcodec-decoder.yaml | 7 --- .../media/mediatek,vcodec-encoder.yaml | 8
Re: [PATCH v9 12/15] media: mtk-vcodec: enc: Remove mtk_vcodec_release_enc_pm
Hi Hans, On 13/01/2022 11:15, Hans Verkuil wrote: On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote: Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto: Il 12/11/21 11:55, Yong Wu ha scritto: After this patchset, mtk_vcodec_release_enc_pm has only one line. then remove that function, use pm_runtime_disable instead. meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks, rename it from the _pm to _clk. No functional change. CC: Tiffany Lin CC: Irui Wang Signed-off-by: Yong Wu Reviewed-by: AngeloGioacchino Del Regno Hello Yong, the mtk-vcodec patches were merged in Yunfei's vcodec patch series and Hans has scheduled that for v5.18. Can you please send a v10 and drop patches 10/15, 11/15, 12/15 (all of the media: mtk-vcodec: *) from this series? For the records, I think that after sending v10 this series is ready to be merged, as it was well reviewed and also tested on many MTK platforms. Good to know. When I have the v10 I'll try to prioritize reviewing it and running my usual tests. Yong, please make sure you run 'checkpatch.pl --strict' over the v10 patches and fix any issues (using common sense). Can you please take me in the look when you take the patches. I'll take the DTS related as soon as you queue up the others. Thanks! Matthias Regards, Hans Thank you, - Angelo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 13/16] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
On 10/06/2021 14:02, Yong Wu wrote:
> On Thu, 2021-06-10 at 09:53 +0200, Matthias Brugger wrote:
>> Hi Yong,
>>
>> On 12/05/2021 14:29, Yong Wu wrote:
>>> On Wed, 2021-05-12 at 17:20 +0800, Hsin-Yi Wang wrote:
>>>> On Sat, Apr 10, 2021 at 5:14 PM Yong Wu wrote:
>>>>>
>>>>> MediaTek IOMMU has already added the device_link between the consumer
>>>>> and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
>>>>> the smi-larb's pm_runtime_get_sync also be called automatically.
>>>>>
>>>>> CC: Tiffany Lin
>>>>> CC: Irui Wang
>>>>> Signed-off-by: Yong Wu
>>>>> Reviewed-by: Evan Green
>>>>> Acked-by: Tiffany Lin
>>>>> ---
>>>>> .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 37 ++-
>>>>> .../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
>>>>> .../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
>>>>> .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 46 ++-
>>>>> 4 files changed, 10 insertions(+), 77 deletions(-)
>>>
>>> [...]
>>>
>>>>> @@ -108,13 +80,6 @@ void mtk_vcodec_enc_clock_on(struct mtk_vcodec_pm *pm)
>>>>> }
>>>>> }
>>>>>
>>>>> - ret = mtk_smi_larb_get(pm->larbvenc);
>>>>> - if (ret) {
>>>>> - mtk_v4l2_err("mtk_smi_larb_get larb3 fail %d", ret);
>>>>> - goto clkerr;
>>>>> - }
>>>>> - return;
>>>>
>>>> You can't delete the return; here, otherwise vcodec_clk will be turned
>>>> off immediately after they are turned on.
>>>
>>> Thanks very much for your review.
>>>
>>> Sorry for this. You are quite right.
>>>
>>> I checked this, it was introduced in v4 when I rebase the code. I will
>>> fix it in next time.
>>>
>>
>> Please also make sure that you add all maintainers. I realized that at least
>> for
>> the media/platform drivers we miss the maintainer and the corresponding
>> mailing
>> list.
>> This is especially important in this series, as it spans several subsystems.
>
> Thanks for hint. I only added the file maintainer here. I will add
> linux-media in next version.
>
> By the way, this patchset cross several trees, then which tree should it
> go through. Do you have some suggestion?
>
That's a good question. I think the media tree would be a good candidate, as it
has the biggest bunch of patches. But that would mean that Joerg is fine that.
The DTS part could still go through my tree.
Regards,
Matthias
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 13/16] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
Hi Yong,
On 12/05/2021 14:29, Yong Wu wrote:
> On Wed, 2021-05-12 at 17:20 +0800, Hsin-Yi Wang wrote:
>> On Sat, Apr 10, 2021 at 5:14 PM Yong Wu wrote:
>>>
>>> MediaTek IOMMU has already added the device_link between the consumer
>>> and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
>>> the smi-larb's pm_runtime_get_sync also be called automatically.
>>>
>>> CC: Tiffany Lin
>>> CC: Irui Wang
>>> Signed-off-by: Yong Wu
>>> Reviewed-by: Evan Green
>>> Acked-by: Tiffany Lin
>>> ---
>>> .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 37 ++-
>>> .../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
>>> .../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
>>> .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 46 ++-
>>> 4 files changed, 10 insertions(+), 77 deletions(-)
>
> [...]
>
>>> @@ -108,13 +80,6 @@ void mtk_vcodec_enc_clock_on(struct mtk_vcodec_pm *pm)
>>> }
>>> }
>>>
>>> - ret = mtk_smi_larb_get(pm->larbvenc);
>>> - if (ret) {
>>> - mtk_v4l2_err("mtk_smi_larb_get larb3 fail %d", ret);
>>> - goto clkerr;
>>> - }
>>> - return;
>>
>> You can't delete the return; here, otherwise vcodec_clk will be turned
>> off immediately after they are turned on.
>
> Thanks very much for your review.
>
> Sorry for this. You are quite right.
>
> I checked this, it was introduced in v4 when I rebase the code. I will
> fix it in next time.
>
Please also make sure that you add all maintainers. I realized that at least for
the media/platform drivers we miss the maintainer and the corresponding mailing
list.
This is especially important in this series, as it spans several subsystems.
Thanks a lot,
Matthias
>>
>>> -
>>> clkerr:
>>> for (i -= 1; i >= 0; i--)
>>> clk_disable_unprepare(enc_clk->clk_info[i].vcodec_clk);
>>> @@ -125,7 +90,6 @@ void mtk_vcodec_enc_clock_off(struct mtk_vcodec_pm *pm)
>>> struct mtk_vcodec_clk *enc_clk = >venc_clk;
>>> int i = 0;
>>>
>>> - mtk_smi_larb_put(pm->larbvenc);
>>> for (i = enc_clk->clk_num - 1; i >= 0; i--)
>>> clk_disable_unprepare(enc_clk->clk_info[i].vcodec_clk);
>>> }
>>> --
>>> 2.18.0
>>>
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 14/16] memory: mtk-smi: Get rid of mtk_smi_larb_get/put
On 10/04/2021 11:11, Yong Wu wrote:
> After adding device_link between the iommu consumer and smi-larb,
> the pm_runtime_get(_sync) of smi-larb and smi-common will be called
> automatically. we can get rid of mtk_smi_larb_get/put.
>
> CC: Matthias Brugger
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
Acked-by: Matthias Brugger
> ---
> drivers/memory/mtk-smi.c | 14 --
> include/soc/mediatek/smi.h | 20
> 2 files changed, 34 deletions(-)
>
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index c5fb51f73b34..7c61c924e220 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -134,20 +134,6 @@ static void mtk_smi_clk_disable(const struct mtk_smi
> *smi)
> clk_disable_unprepare(smi->clk_apb);
> }
>
> -int mtk_smi_larb_get(struct device *larbdev)
> -{
> - int ret = pm_runtime_resume_and_get(larbdev);
> -
> - return (ret < 0) ? ret : 0;
> -}
> -EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
> -
> -void mtk_smi_larb_put(struct device *larbdev)
> -{
> - pm_runtime_put_sync(larbdev);
> -}
> -EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
> -
> static int
> mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
> {
> diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> index 15e3397cec58..11f7d6b59642 100644
> --- a/include/soc/mediatek/smi.h
> +++ b/include/soc/mediatek/smi.h
> @@ -19,26 +19,6 @@ struct mtk_smi_larb_iommu {
> unsigned char bank[32];
> };
>
> -/*
> - * mtk_smi_larb_get: Enable the power domain and clocks for this local
> arbiter.
> - * It also initialize some basic setting(like iommu).
> - * mtk_smi_larb_put: Disable the power domain and clocks for this local
> arbiter.
> - * Both should be called in non-atomic context.
> - *
> - * Returns 0 if successful, negative on failure.
> - */
> -int mtk_smi_larb_get(struct device *larbdev);
> -void mtk_smi_larb_put(struct device *larbdev);
> -
> -#else
> -
> -static inline int mtk_smi_larb_get(struct device *larbdev)
> -{
> - return 0;
> -}
> -
> -static inline void mtk_smi_larb_put(struct device *larbdev) { }
> -
> #endif
>
> #endif
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 09/16] drm/mediatek: Use pm_runtime_resume_and_get for PM get_sync
On 10/04/2021 11:11, Yong Wu wrote:
> pm_runtime_get_sync will increment pm usage counter even it failed.
> This patch use pm_runtime_resume_and_get instead of pm_runtime_get
> to keep usage counter balanced.
>
> Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 8b0de90156c6..69d23ce56d2c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -259,7 +259,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> *mtk_crtc)
> drm_connector_list_iter_end(_iter);
> }
>
> - ret = pm_runtime_get_sync(crtc->dev->dev);
> + ret = pm_runtime_resume_and_get(crtc->dev->dev);
> if (ret < 0) {
> DRM_ERROR("Failed to enable power domain: %d\n", ret);
> return ret;
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 05/16] media: mtk-jpeg: Use pm_runtime_resume_and_get for PM get_sync
On 10/04/2021 11:11, Yong Wu wrote: > pm_runtime_get_sync will increment pm usage counter even it failed. > This patch use pm_runtime_resume_and_get instead of pm_runtime_get > to keep usage counter balanced. > > CC: Xia Jiang > Signed-off-by: Yong Wu Reviewed-by: Matthias Brugger > --- > drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c > b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c > index 88a23bce569d..a89c7b206eef 100644 > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c > @@ -920,7 +920,7 @@ static void mtk_jpeg_enc_device_run(void *priv) > src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx); > dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx); > > - ret = pm_runtime_get_sync(jpeg->dev); > + ret = pm_runtime_resume_and_get(jpeg->dev); > if (ret < 0) > goto enc_end; > > @@ -973,7 +973,7 @@ static void mtk_jpeg_dec_device_run(void *priv) > return; > } > > - ret = pm_runtime_get_sync(jpeg->dev); > + ret = pm_runtime_resume_and_get(jpeg->dev); > if (ret < 0) > goto dec_end; > > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 2/3] iommu/mediatek: add flag for legacy ivrp paddr
On 07/09/2020 12:16, Fabien Parent wrote:
Add a new flag in order to select which IVRP_PADDR format is used
by an SoC.
Signed-off-by: Fabien Parent
Reviewed-by: Yong Wu
Reviewed-by: Matthias Brugger
---
v4: no change
v3: set LEGACY_IVRP_PADDR as a flag instead of platform data
v2: new patch
---
drivers/iommu/mtk_iommu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 785b228d39a6..b1f85a7e9346 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -116,6 +116,7 @@
#define OUT_ORDER_WR_EN BIT(4)
#define HAS_SUB_COMM BIT(5)
#define WR_THROT_EN BIT(6)
+#define HAS_LEGACY_IVRP_PADDR BIT(7)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
pdata)->flags) & (_x)) == (_x))
@@ -582,7 +583,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
- if (data->plat_data->m4u_plat == M4U_MT8173)
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_LEGACY_IVRP_PADDR))
regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
else
regval = lower_32_bits(data->protect_base) |
@@ -818,7 +819,8 @@ static const struct mtk_iommu_plat_data mt6779_data = {
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
- .flags= HAS_4GB_MODE | HAS_BCLK | RESET_AXI,
+ .flags= HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
+ HAS_LEGACY_IVRP_PADDR,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
.larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
};
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;
On 09/09/2020 22:06, Joe Perches wrote:
diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c
b/drivers/net/wireless/mediatek/mt7601u/dma.c
index 09f931d4598c..778be26d329f 100644
--- a/drivers/net/wireless/mediatek/mt7601u/dma.c
+++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
@@ -193,11 +193,11 @@ static void mt7601u_complete_rx(struct urb *urb)
case -ESHUTDOWN:
case -ENOENT:
return;
+ case 0:
+ break;
default:
dev_err_ratelimited(dev->dev, "rx urb failed: %d\n",
urb->status);
- fallthrough;
- case 0:
break;
}
@@ -238,11 +238,11 @@ static void mt7601u_complete_tx(struct urb *urb)
case -ESHUTDOWN:
case -ENOENT:
return;
+ case 0:
+ break;
default:
dev_err_ratelimited(dev->dev, "tx urb failed: %d\n",
urb->status);
- fallthrough;
- case 0:
break;
}
Reviewed-by: Matthias Brugger
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: Aw: [PATCH 00/18] Convert arch/arm to use iommu-dma
On 27/08/2020 14:31, Frank Wunderlich wrote: Tested full series on bananapi r2 (mt7623/mt2701, 5.9-rc1 + hdmi-patches), works so far fbcon+x without issues Tested-by: Frank Wunderlich Thanks for testing. Robin this is especially relevant for: [PATCH 09/18] iommu/mediatek-v1: Add IOMMU_DOMAIN_DMA support Regards, Matthias ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RESEND PATCH v4] iommu/mediatek: check 4GB mode by reading infracfg
On 26/08/2020 10:56, Miles Chen wrote:
In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the un-exported symbol max_pfn.
This is a step towards building mtk_iommu as a kernel module.
[1] https://lore.kernel.org/lkml/20200603161132.2441-1-miles.c...@mediatek.com/
[2] https://lore.kernel.org/lkml/20200604080120.2628-1-miles.c...@mediatek.com/
[3] https://lore.kernel.org/lkml/20200715205120.GA778876@bogus/
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: Yong Wu
Cc: Yingjoe Chen
Cc: Christoph Hellwig
Cc: Rob Herring
Cc: Matthias Brugger
Signed-off-by: Miles Chen
Reviewed-by: Matthias Brugger
---
Change since v3
- use lore.kernel.org links
- move "change since..." after "---"
Change since v2:
- determine compatible string by m4u_plat
- rebase to next-20200720
- add "---"
Change since v1:
- remove the phandle usage, search for infracfg instead [3]
- use infracfg instead of infracfg_regmap
- move infracfg definitaions to linux/soc/mediatek/infracfg.h
- update enable_4GB only when has_4gb_mode
---
drivers/iommu/mtk_iommu.c | 34 +++
include/linux/soc/mediatek/infracfg.h | 3 +++
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 785b228d39a6..adc350150492 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -3,7 +3,6 @@
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu
*/
-#include
#include
#include
#include
@@ -15,13 +14,16 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -640,8 +642,11 @@ static int mtk_iommu_probe(struct platform_device *pdev)
struct resource *res;
resource_size_t ioaddr;
struct component_match *match = NULL;
+ struct regmap *infracfg;
void*protect;
int i, larb_nr, ret;
+ u32 val;
+ char*p;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -655,10 +660,29 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return -ENOMEM;
data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
- /* Whether the current dram is over 4GB */
- data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
- if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
- data->enable_4GB = false;
+ data->enable_4GB = false;
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE)) {
+ switch (data->plat_data->m4u_plat) {
+ case M4U_MT2712:
+ p = "mediatek,mt2712-infracfg";
+ break;
+ case M4U_MT8173:
+ p = "mediatek,mt8173-infracfg";
+ break;
+ default:
+ p = NULL;
+ }
+
+ infracfg = syscon_regmap_lookup_by_compatible(p);
+
+ if (IS_ERR(infracfg))
+ return PTR_ERR(infracfg);
+
+ ret = regmap_read(infracfg, REG_INFRA_MISC, );
+ if (ret)
+ return ret;
+ data->enable_4GB = !!(val & F_DDR_4GB_SUPPORT_EN);
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
data->base = devm_ioremap_resource(dev, res);
diff --git a/include/linux/soc/mediatek/infracfg.h
b/include/linux/soc/mediatek/infracfg.h
index fd25f0148566..233463d789c6 100644
--- a/include/linux/soc/mediatek/infracfg.h
+++ b/include/linux/soc/mediatek/infracfg.h
@@ -32,6 +32,9 @@
#define MT7622_TOP_AXI_PROT_EN_WB (BIT(2) | BIT(6) | \
BIT(7) | BIT(8))
+#define REG_INFRA_MISC0xf00
+#define F_DDR_4GB_SUPPORT_EN BIT(13)
+
int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
bool reg_update);
int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] iommu/mediatek: check 4GB mode by reading infracfg
On 22/07/2020 16:19, Miles Chen wrote:
In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the un-exported symbol max_pfn.
This is a step towards building mtk_iommu as a kernel module.
---
That's wrong. The commit message would be cut after this '---' so we would loose
the Cc and Signed-of-by tags.
Change since v2:
- determine compatible string by m4u_plat
- rebase to next-20200720
- add "---"
Change since v1:
- remove the phandle usage, search for infracfg instead [3]
- use infracfg instead of infracfg_regmap
- move infracfg definitaions to linux/soc/mediatek/infracfg.h
- update enable_4GB only when has_4gb_mode
[1] https://lkml.org/lkml/2020/6/3/733
[2] https://lkml.org/lkml/2020/6/4/136
I think using links to lore.kernel.org would make sure that the URL does not
change over time. As the commit log will stay there for ever, but who konws what
happens with lkml.org
[3] https://lkml.org/lkml/2020/7/15/1147
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: Yong Wu
Cc: Yingjoe Chen
Cc: Christoph Hellwig
Cc: Rob Herring
Cc: Matthias Brugger
Signed-off-by: Miles Chen
The formating should look like this:
In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the un-exported symbol max_pfn.
This is a step towards building mtk_iommu as a kernel module.
[1] https://lkml.org/lkml/2020/6/3/733
[2] https://lkml.org/lkml/2020/6/4/136
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: Yong Wu
Cc: Yingjoe Chen
Cc: Christoph Hellwig
Cc: Rob Herring
Cc: Matthias Brugger
Signed-off-by: Miles Chen
---
Change since v2:
- determine compatible string by m4u_plat
- rebase to next-20200720
- add "---"
Change since v1:
- remove the phandle usage, search for infracfg instead
https://lkml.org/lkml/2020/7/15/1147
- use infracfg instead of infracfg_regmap
- move infracfg definitaions to linux/soc/mediatek/infracfg.h
- update enable_4GB only when has_4gb_mode
---
drivers/iommu/mtk_iommu.c | 34 +++
include/linux/soc/mediatek/infracfg.h | 3 +++
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 59e5a62a34db..9ec666168822 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -3,7 +3,6 @@
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu
*/
-#include
#include
#include
#include
@@ -15,13 +14,16 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -640,8 +642,11 @@ static int mtk_iommu_probe(struct platform_device *pdev)
struct resource *res;
resource_size_t ioaddr;
struct component_match *match = NULL;
+ struct regmap *infracfg;
void*protect;
int i, larb_nr, ret;
+ u32 val;
+ char*p;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -655,10 +660,29 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return -ENOMEM;
data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
- /* Whether the current dram is over 4GB */
- data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
- if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
- data->enable_4GB = false;
+ data->enable_4GB = false;
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE)) {
+ switch (data->plat_data->m4u_plat) {
+ case M4U_MT2712:
+ p = "mediatek,mt2712-infracfg";
+ break;
+ case M4U_MT8173:
+ p = "mediatek,mt8173-infracfg";
+ break;
+ default:
+ p = NULL;
+ }
+
+ infracfg = syscon_regmap_lookup_by_compatible(p);
if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE)) {
switch (data->plat_data->m4u_plat) {
case M4U_MT2712:
infracfg =
syscon_regmap_lookup_by_compatible("mediatek,mt2712-infracfg");
break;
case M4U_MT8173:
infracfg =
syscon_regmap_lookup_by_compatible("mediatek,mt8173-infracfg");
break;
default:
infracfg = -ENODEV;
}
+
+ if (IS_ERR(infracfg))
+
Re: [PATCH v2] iommu/mediatek: check 4GB mode by reading infracfg
On 21/07/2020 13:24, Yong Wu wrote:
On Tue, 2020-07-21 at 11:40 +0200, Matthias Brugger wrote:
On 21/07/2020 04:16, Miles Chen wrote:
In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the un-exported symbol max_pfn.
This is a step towards building mtk_iommu as a kernel module.
Change since v1:
1. remove the phandle usage, search for infracfg instead [3]
2. use infracfg instead of infracfg_regmap
3. move infracfg definitaions to linux/soc/mediatek/infracfg.h
4. update enable_4GB only when has_4gb_mode
[1] https://lkml.org/lkml/2020/6/3/733
[2] https://lkml.org/lkml/2020/6/4/136
[3] https://lkml.org/lkml/2020/7/15/1147
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: Yong Wu
Cc: Yingjoe Chen
Cc: Christoph Hellwig
Cc: Yong Wu
Cc: Chao Hao
Cc: Rob Herring
Cc: Matthias Brugger
Signed-off-by: Miles Chen
---
drivers/iommu/mtk_iommu.c | 26 +-
include/linux/soc/mediatek/infracfg.h | 3 +++
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 2be96f1cdbd2..16765f532853 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -3,7 +3,6 @@
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu
*/
-#include
#include
#include
#include
@@ -15,13 +14,16 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -599,8 +601,10 @@ static int mtk_iommu_probe(struct platform_device *pdev)
struct resource *res;
resource_size_t ioaddr;
struct component_match *match = NULL;
+ struct regmap *infracfg;
void*protect;
int i, larb_nr, ret;
+ u32 val;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -614,10 +618,22 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return -ENOMEM;
data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
- /* Whether the current dram is over 4GB */
- data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
- if (!data->plat_data->has_4gb_mode)
- data->enable_4GB = false;
+ data->enable_4GB = false;
+ if (data->plat_data->has_4gb_mode) {
+ infracfg = syscon_regmap_lookup_by_compatible(
+ "mediatek,mt8173-infracfg");
+ if (IS_ERR(infracfg)) {
+ infracfg = syscon_regmap_lookup_by_compatible(
+ "mediatek,mt2712-infracfg");
+ if (IS_ERR(infracfg))
+ return PTR_ERR(infracfg);
I think we should check m4u_plat instead to decide which compatible we have to
look for.
Another option would be to add a general compatible something like
"mtk-infracfg" and search for that. That would need an update of all DTS having
a infracfg compatible right now. After thinking twice, this would break newer
kernel with older device tree, so maybe it's better to go with m4u_plat switch
statement.
Add a "char *infracfg" in the plat_data, Use the mt2712, mt8173
corresponding string in it. If it is NULL, It means the "enable_4GB"
always is false. Then we also can remove the flag "has_4gb_mode".
is this OK?
It's an option, but I personally find that a bit hacky.
Regards,
Matthias
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/mediatek: check 4GB mode by reading infracfg
On 21/07/2020 04:16, Miles Chen wrote:
In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the un-exported symbol max_pfn.
This is a step towards building mtk_iommu as a kernel module.
Change since v1:
1. remove the phandle usage, search for infracfg instead [3]
2. use infracfg instead of infracfg_regmap
3. move infracfg definitaions to linux/soc/mediatek/infracfg.h
4. update enable_4GB only when has_4gb_mode
[1] https://lkml.org/lkml/2020/6/3/733
[2] https://lkml.org/lkml/2020/6/4/136
[3] https://lkml.org/lkml/2020/7/15/1147
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: Yong Wu
Cc: Yingjoe Chen
Cc: Christoph Hellwig
Cc: Yong Wu
Cc: Chao Hao
Cc: Rob Herring
Cc: Matthias Brugger
Signed-off-by: Miles Chen
---
drivers/iommu/mtk_iommu.c | 26 +-
include/linux/soc/mediatek/infracfg.h | 3 +++
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 2be96f1cdbd2..16765f532853 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -3,7 +3,6 @@
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu
*/
-#include
#include
#include
#include
@@ -15,13 +14,16 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -599,8 +601,10 @@ static int mtk_iommu_probe(struct platform_device *pdev)
struct resource *res;
resource_size_t ioaddr;
struct component_match *match = NULL;
+ struct regmap *infracfg;
void*protect;
int i, larb_nr, ret;
+ u32 val;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -614,10 +618,22 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return -ENOMEM;
data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
- /* Whether the current dram is over 4GB */
- data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
- if (!data->plat_data->has_4gb_mode)
- data->enable_4GB = false;
+ data->enable_4GB = false;
+ if (data->plat_data->has_4gb_mode) {
+ infracfg = syscon_regmap_lookup_by_compatible(
+ "mediatek,mt8173-infracfg");
+ if (IS_ERR(infracfg)) {
+ infracfg = syscon_regmap_lookup_by_compatible(
+ "mediatek,mt2712-infracfg");
+ if (IS_ERR(infracfg))
+ return PTR_ERR(infracfg);
I think we should check m4u_plat instead to decide which compatible we have to
look for.
Another option would be to add a general compatible something like
"mtk-infracfg" and search for that. That would need an update of all DTS having
a infracfg compatible right now. After thinking twice, this would break newer
kernel with older device tree, so maybe it's better to go with m4u_plat switch
statement.
Regards,
Matthias
+
+ }
+ ret = regmap_read(infracfg, REG_INFRA_MISC, );
+ if (ret)
+ return ret;
+ data->enable_4GB = !!(val & F_DDR_4GB_SUPPORT_EN);
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
data->base = devm_ioremap_resource(dev, res);
diff --git a/include/linux/soc/mediatek/infracfg.h
b/include/linux/soc/mediatek/infracfg.h
index fd25f0148566..233463d789c6 100644
--- a/include/linux/soc/mediatek/infracfg.h
+++ b/include/linux/soc/mediatek/infracfg.h
@@ -32,6 +32,9 @@
#define MT7622_TOP_AXI_PROT_EN_WB (BIT(2) | BIT(6) | \
BIT(7) | BIT(8))
+#define REG_INFRA_MISC0xf00
+#define F_DDR_4GB_SUPPORT_EN BIT(13)
+
int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
bool reg_update);
int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 4/4] iommu/mediatek: check 4GB mode by reading infracfg
On 02/07/2020 11:37, Miles Chen wrote:
In previous disscusion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the unexported symbol max_pfn.
[1] https://lkml.org/lkml/2020/6/3/733
[2] https://lkml.org/lkml/2020/6/4/136
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: Yong Wu
Cc: Yingjoe Chen
Cc: Christoph Hellwig
Signed-off-by: Miles Chen
---
drivers/iommu/mtk_iommu.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 2be96f1cdbd2..09be57bd8d74 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -3,7 +3,6 @@
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu
*/
-#include
#include
#include
#include
@@ -15,11 +14,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -91,6 +92,9 @@
#define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
#define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
+#define REG_INFRA_MISC0xf00
+#define F_DDR_4GB_SUPPORT_EN BIT(13)
+
As this is used for infracfg, I think it would be good to add it to
include/linux/soc/mediatek/infracfg.h and include that file here.
#define MTK_PROTECT_PA_ALIGN 128
/*
@@ -599,8 +603,10 @@ static int mtk_iommu_probe(struct platform_device *pdev)
struct resource *res;
resource_size_t ioaddr;
struct component_match *match = NULL;
+ struct regmap *infracfg_regmap;
Maybe call it just infracfg.
void*protect;
int i, larb_nr, ret;
+ u32 val;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -614,10 +620,18 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return -ENOMEM;
data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
- /* Whether the current dram is over 4GB */
- data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
- if (!data->plat_data->has_4gb_mode)
+ if (data->plat_data->has_4gb_mode) {
+ infracfg_regmap = syscon_regmap_lookup_by_phandle(dev->of_node,
+ "mediatek,infracfg");
+ if (IS_ERR(infracfg_regmap))
+ return PTR_ERR(infracfg_regmap);
Do we need to error out, or could we be conservative and set endable_4GB =
false?
+ ret = regmap_read(infracfg_regmap, REG_INFRA_MISC, );
+ if (ret)
+ return ret;
+ data->enable_4GB = !!(val & F_DDR_4GB_SUPPORT_EN);
+ } else {
data->enable_4GB = false;
Move that before the if() and update enable_4GB only in case of has_4gb_mode.
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
data->base = devm_ioremap_resource(dev, res);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/mediatek: Include liunx/dma-mapping.h
On 13/07/2020 12:16, Joerg Roedel wrote: From: Joerg Roedel This fixes a compile error when cross-compiling the driver on x86-32. Signed-off-by: Joerg Roedel Reviewed-by: Matthias Brugger --- drivers/iommu/mtk_iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h index 6ff62452bbf9..122925dbe547 100644 --- a/drivers/iommu/mtk_iommu.h +++ b/drivers/iommu/mtk_iommu.h @@ -15,6 +15,7 @@ #include #include #include +#include #include #define MTK_LARB_COM_MAX 8 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 01/21] dt-binding: memory: mediatek: Add a common larb-port header file
On 11/07/2020 08:48, Yong Wu wrote: Put all the macros about smi larb/port togethers, this is a preparing patch for extending LARB_NR and adding new dom-id support. Signed-off-by: Yong Wu --- include/dt-bindings/memory/mt2712-larb-port.h | 2 +- include/dt-bindings/memory/mt6779-larb-port.h | 2 +- include/dt-bindings/memory/mt8173-larb-port.h | 2 +- include/dt-bindings/memory/mt8183-larb-port.h | 2 +- include/dt-bindings/memory/mtk-smi-larb-port.h | 15 +++ 5 files changed, 19 insertions(+), 4 deletions(-) create mode 100644 include/dt-bindings/memory/mtk-smi-larb-port.h diff --git a/include/dt-bindings/memory/mt2712-larb-port.h b/include/dt-bindings/memory/mt2712-larb-port.h index 6f9aa7349cef..b6b2c6bf4459 100644 --- a/include/dt-bindings/memory/mt2712-larb-port.h +++ b/include/dt-bindings/memory/mt2712-larb-port.h @@ -6,7 +6,7 @@ #ifndef __DTS_IOMMU_PORT_MT2712_H #define __DTS_IOMMU_PORT_MT2712_H -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#include #define M4U_LARB0_ID 0 #define M4U_LARB1_ID 1 diff --git a/include/dt-bindings/memory/mt6779-larb-port.h b/include/dt-bindings/memory/mt6779-larb-port.h index 2ad0899fbf2f..60f57f54393e 100644 --- a/include/dt-bindings/memory/mt6779-larb-port.h +++ b/include/dt-bindings/memory/mt6779-larb-port.h @@ -7,7 +7,7 @@ #ifndef _DTS_IOMMU_PORT_MT6779_H_ #define _DTS_IOMMU_PORT_MT6779_H_ -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#include #define M4U_LARB0_ID 0 #define M4U_LARB1_ID 1 diff --git a/include/dt-bindings/memory/mt8173-larb-port.h b/include/dt-bindings/memory/mt8173-larb-port.h index 9f31ccfeca21..d8c99c946053 100644 --- a/include/dt-bindings/memory/mt8173-larb-port.h +++ b/include/dt-bindings/memory/mt8173-larb-port.h @@ -6,7 +6,7 @@ #ifndef __DTS_IOMMU_PORT_MT8173_H #define __DTS_IOMMU_PORT_MT8173_H -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#include #define M4U_LARB0_ID 0 #define M4U_LARB1_ID 1 diff --git a/include/dt-bindings/memory/mt8183-larb-port.h b/include/dt-bindings/memory/mt8183-larb-port.h index 2c579f305162..275c095a6fd6 100644 --- a/include/dt-bindings/memory/mt8183-larb-port.h +++ b/include/dt-bindings/memory/mt8183-larb-port.h @@ -6,7 +6,7 @@ #ifndef __DTS_IOMMU_PORT_MT8183_H #define __DTS_IOMMU_PORT_MT8183_H -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#include #define M4U_LARB0_ID 0 #define M4U_LARB1_ID 1 diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h new file mode 100644 index ..2ec7fe5ce4e9 --- /dev/null +++ b/include/dt-bindings/memory/mtk-smi-larb-port.h @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2020 MediaTek Inc. + * Author: Yong Wu + */ +#ifndef __DTS_MTK_IOMMU_PORT_H_ +#define __DTS_MTK_IOMMU_PORT_H_ + +#define MTK_LARB_NR_MAX16 include/soc/mediatek/smi.h has the very same define. Should smi.h include this file? Regards, Matthias + +#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#define MTK_M4U_TO_LARB(id)(((id) >> 5) & 0xf) +#define MTK_M4U_TO_PORT(id)((id) & 0x1f) + +#endif ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 07/10] iommu/mediatek: Add REG_MMU_WR_LEN_CTRL register definition
On 03/07/2020 06:41, Chao Hao wrote:
Some platforms(ex: mt6779) need to improve performance by setting
REG_MMU_WR_LEN_CTRL 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
Signed-off-by: Chao Hao
Reviewed-by: Matthias Brugger
---
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 0d96dcd8612b..5c8e141668fc 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -46,6 +46,8 @@
#define F_MMU_STANDARD_AXI_MODE_MASK (BIT(3) | BIT(19))
#define REG_MMU_DCM_DIS0x050
+#define REG_MMU_WR_LEN_CTRL0x054
+#define F_MMU_WR_THROT_DIS_MASK(BIT(5) | BIT(21))
#define REG_MMU_CTRL_REG 0x110
#define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
@@ -112,6 +114,7 @@
#define RESET_AXI BIT(3)
#define OUT_ORDER_WR_EN BIT(4)
#define HAS_SUB_COMM BIT(5)
+#define WR_THROT_ENBIT(6)
#define MTK_IOMMU_HAS_FLAG(pdata, _x) \
pdata)->flags) & (_x)) == (_x))
@@ -593,6 +596,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_CTRL);
+ regval &= ~F_MMU_WR_THROT_DIS_MASK;
+ writel_relaxed(regval, data->base + REG_MMU_WR_LEN_CTRL);
+ }
if (MTK_IOMMU_HAS_FLAG(data->plat_data, RESET_AXI)) {
/* The register is called STANDARD_AXI_MODE in this case */
@@ -747,6 +756,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device
*dev)
struct mtk_iommu_suspend_reg *reg = >reg;
void __iomem *base = data->base;
+ reg->wr_len_ctrl = readl_relaxed(base + REG_MMU_WR_LEN_CTRL);
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);
@@ -771,6 +781,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_ctrl, base + REG_MMU_WR_LEN_CTRL);
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 46d0d47b22e1..31edd05e2eb1 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -31,6 +31,7 @@ struct mtk_iommu_suspend_reg {
u32 int_main_control;
u32 ivrp_paddr;
u32 vld_pa_rng;
+ u32 wr_len_ctrl;
};
enum mtk_iommu_plat {
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 09/10] iommu/mediatek: Modify MMU_CTRL register setting
On 03/07/2020 06:41, Chao Hao wrote:
> The MMU_CTRL register 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.
>
> Cc: Matthias Brugger
> Cc: Yong Wu
> Signed-off-by: Chao Hao
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index e71003037ffa..a816030d00f1 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -555,11 +555,13 @@ static int mtk_iommu_hw_init(const struct
> mtk_iommu_data *data)
> return ret;
> }
>
> - if (data->plat_data->m4u_plat == M4U_MT8173)
> + 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;
> + } else {
> + regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
> + 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
Re: [PATCH v6 06/10] iommu/mediatek: Add sub_comm id in translation fault
On 03/07/2020 06:41, 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'd03'd13'd23'd3 ... 3'd7 <-common_id(max is 8)
> | | | | ||
> Larb0 Larb1 | Larb3 ... Larb7
> |
> smi sub common
> |
> --
> || | |
> 2'd0 2'd12'd22'd3 <-sub_common_id(max is 4)
> || | |
>Larb8Larb9 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
> Signed-off-by: Chao Hao
> Reviewed-by: Yong Wu
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 21 ++---
> drivers/iommu/mtk_iommu.h | 5 -
> 2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 533b8f76f592..0d96dcd8612b 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -91,6 +91,8 @@
> #define REG_MMU1_INVLD_PA0x148
> #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)
>
> @@ -109,6 +111,7 @@
> #define HAS_VLD_PA_RNG BIT(2)
> #define RESET_AXIBIT(3)
> #define OUT_ORDER_WR_EN BIT(4)
> +#define HAS_SUB_COMM BIT(5)
>
> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> pdata)->flags) & (_x)) == (_x))
> @@ -239,7 +242,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 */
> @@ -255,10 +258,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(>domain, data->dev, fault_iova,
> write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
> @@ -785,21 +792,21 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> .flags= HAS_4GB_MODE | HAS_BCLK | HAS_VLD_PA_RNG,
> .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> - .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 = {
> .m4u_plat = M4U_MT8173,
> .flags= HAS_4GB_MODE | HAS_BCLK | RESET_AXI,
> .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
>
Re: [PATCH v6 04/10] iommu/mediatek: Setting MISC_CTRL register
On 03/07/2020 06:41, Chao Hao wrote:
> Add F_MMU_IN_ORDER_WR_EN_MASK and F_MMU_STANDARD_AXI_MODE_EN_MASK
> definitions in MISC_CTRL register.
> F_MMU_STANDARD_AXI_MODE_EN_MASK:
> 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_MASK:
> 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 commands 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
> Suggested-by: Yong Wu
> Signed-off-by: Chao Hao
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 40ca564d97af..219d7aa6f059 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_CTRL0x048
> +#define F_MMU_IN_ORDER_WR_EN_MASK(BIT(1) | BIT(17))
> +#define F_MMU_STANDARD_AXI_MODE_MASK (BIT(3) | BIT(19))
> +
> #define REG_MMU_DCM_DIS 0x050
>
> #define REG_MMU_CTRL_REG 0x110
> @@ -105,6 +108,7 @@
> #define HAS_BCLK BIT(1)
> #define HAS_VLD_PA_RNG BIT(2)
> #define RESET_AXIBIT(3)
> +#define OUT_ORDER_WR_EN BIT(4)
>
> #define MTK_IOMMU_HAS_FLAG(pdata, _x) \
> pdata)->flags) & (_x)) == (_x))
> @@ -585,8 +589,14 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
>
> 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 {
> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> + regval &= ~F_MMU_STANDARD_AXI_MODE_MASK;
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data, OUT_ORDER_WR_EN))
> + regval &= ~F_MMU_IN_ORDER_WR_EN_MASK;
> }
> + 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)) {
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 03/10] iommu/mediatek: Use a u32 flags to describe different HW features
On 04/07/2020 03:16, Yingjoe Chen wrote:
> On Fri, 2020-07-03 at 12:41 +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.
>>
>> Cc: Yong Wu
>> Suggested-by: Matthias Brugger
>> Signed-off-by: Chao Hao
>> Reviewed-by: Matthias Brugger
>> ---
>> drivers/iommu/mtk_iommu.c | 28 +---
>> drivers/iommu/mtk_iommu.h | 7 +--
>> 2 files changed, 18 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>> index 88d3df5b91c2..40ca564d97af 100644
>> --- a/drivers/iommu/mtk_iommu.c
>> +++ b/drivers/iommu/mtk_iommu.c
>> @@ -100,6 +100,15 @@
>> #define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0xf)
>> #define MTK_M4U_TO_PORT(id) ((id) & 0x1f)
>>
>> +#define HAS_4GB_MODEBIT(0)
>> +/* HW will use the EMI clock if there isn't the "bclk". */
>> +#define HAS_BCLKBIT(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_domain {
>> struct io_pgtable_cfg cfg;
>> struct io_pgtable_ops *iop;
>> @@ -563,7 +572,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__ to 0x1__. here record bit[32:30].
>> @@ -573,7 +583,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 +628,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 +641,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 +773,19 @@ 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/m
Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
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
>>> Signed-off-by: Chao Hao
>>> ---
>>> 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_DIS0x050
>>> +#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 = >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);
Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
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
>>> Suggested-by: Yong Wu
>>> Signed-off-by: Chao Hao
>>> ---
>>> 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_EN1BIT(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_DIS0x050
>>>
>>> #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,
>>
Re: [PATCH v5 10/10] iommu/mediatek: Add mt6779 basic support
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
> Cc: Matthias Brugger
> Signed-off-by: Chao Hao
Reviewed by: Matthias Brugger
> ---
> 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_A0x024
> #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 = _data},
> + { .compatible = "mediatek,mt6779-m4u", .data = _data},
> { .compatible = "mediatek,mt8173-m4u", .data = _data},
> { .compatible = "mediatek,mt8183-m4u", .data = _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
Re: [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting
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 > Suggested-by: Yong Wu > Signed-off-by: Chao Hao > --- > 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
Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition
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
> Signed-off-by: Chao Hao
> ---
> 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 = >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_AXIBIT(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
Re: [PATCH v5 08/10] iommu/mediatek: Extend protect pa alignment value
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 > Signed-off-by: Chao Hao Reviewed-by: Matthias Brugger > --- > 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
Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register
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
> Suggested-by: Yong Wu
> Signed-off-by: Chao Hao
> ---
> 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_CTRL0x048
> +#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_AXIBIT(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
Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure
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
> Signed-off-by: Chao Hao
Reviewed-by: Matthias Brugger
> ---
> 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__ to 0x1__. 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
> #include
>
> +#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_AXIBIT(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;
> - boolhas_4gb_mode;
> -
> - /* HW will use the EMI clock if there isn't the "bclk". */
> - boolhas_bclk;
> - boolhas_vld_pa_rng;
> - boolreset_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
Re: [PATCH v4 6/7] iommu/mediatek: Add REG_MMU_WR_LEN definition preparing for mt6779
On 19/06/2020 12:56, chao hao wrote:
> On Wed, 2020-06-17 at 11:22 +0200, Matthias Brugger wrote:
>>
>> On 17/06/2020 05:00, Chao Hao wrote:
>>> Some platforms(ex: mt6779) have a new register called by REG_MMU_WR_LEN
>>> to improve performance.
>>> This patch add this register definition.
>>
>> Please be more specific what this register is about.
>>
> OK. thanks.
> We can use "has_wr_len" flag 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.
>
> I will write description above to commit message in next version
>
>>>
>>> Signed-off-by: Chao Hao
>>> ---
>>> 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 a687e8db0e51..c706bca6487e 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_DIS0x050
>>> +#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)
>>> @@ -581,6 +583,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 (data->plat_data->has_wr_len) {
>>> + /* 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);
>>> + }
>>>
>>> if (data->plat_data->reset_axi) {
>>> /* The register is called STANDARD_AXI_MODE in this case */
>>> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct
>>> device *dev)
>>> struct mtk_iommu_suspend_reg *reg = >reg;
>>> void __iomem *base = data->base;
>>>
>>> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
>>
>> Can we read/write the register without any side effect although hardware has
>> not
>> implemented it (!has_wr_len)?
>
> It doesn't have side effect. Becasue all the MTK platform have the
> register for iommu HW. If we need to have requirement for performance,
> we can set it by has_wr_len.
> But I'm Sorry, the name of flag(has_wr_len) is not exact, I will rename
> it in next version, ex: "wr_throt_en"
>
>>
>>
>>> 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 d51ff99c2c71..9971cedd72ea 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -25,6 +25,7 @@ struct mtk_iommu_suspend_reg {
>>> u32 int_main_control;
>>> u32 ivrp_paddr;
>>> u32 vld_pa_rng;
>>> + u32 wr_len;
>>> };
>>>
>>> enum mtk_iom
Re: [PATCH v4 7/7] iommu/mediatek: Add mt6779 basic support
On 18/06/2020 13:54, chao hao wrote:
> On Wed, 2020-06-17 at 11:33 +0200, Matthias Brugger wrote:
>>
>> On 17/06/2020 05:00, 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. Change PROTECT_PA_ALIGN from 128 byte to 256 byte.
>>> 3. For REG_MMU_CTRL_REG register, we only need to change bit[2:0],
>>>others bits keep default value, ex: enable victim tlb.
>>> 4. Add mt6779_data to support mm_iommu HW init.
>>>
>>> Change since v3:
>>> 1. When setting MMU_CTRL_REG, we don't need to include mt8173.
>>>
>>> Cc: Yong Wu
>>> Signed-off-by: Chao Hao
>>> ---
>>> drivers/iommu/mtk_iommu.c | 20 ++--
>>> drivers/iommu/mtk_iommu.h | 1 +
>>> 2 files changed, 19 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index c706bca6487e..def2e996683f 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -37,6 +37,11 @@
>>> #define REG_MMU_INVLD_START_A 0x024
>>> #define REG_MMU_INVLD_END_A0x028
>>>
>>> +/* In latest Coda, MMU_INV_SEL's offset is changed to 0x02c.
>>> + * So we named offset = 0x02c to "REG_MMU_INV_SEL_GEN2"
>>> + * and offset = 0x038 to "REG_MMU_INV_SEL_GEN1".
>>> + */
>>
>> Please delete the comment, this should be understandable from the git history
>
> ok, thanks
>
>>
>>> +#define REG_MMU_INV_SEL_GEN2 0x02c
>>> #define REG_MMU_INV_SEL_GEN1 0x038
>>> #define F_INVLD_EN0BIT(0)
>>> #define F_INVLD_EN1BIT(1)
>>> @@ -98,7 +103,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
>>
>> Do we need 512 bytes for all gen2 IOMMUs?
>> I'm not sure if we should add this in plat_data or if we should just bump up
>> the
>> value for all SoCs.
>> In both cases this should be a separate patch.
>>
> From mt6779, MTK_PROTECT_PA_ALIGN is extend to 256 bytes and don't be
> changed for a long time from our HW designer comment. The legacy iommu
> also can use it, mabye it doesn't set it by platform.
>
Ok then just bump it to 256 in a new patch. Thanks for clarification.
>
>>>
>>> /*
>>> * Get the local arbiter ID and the portid within the larb arbiter
>>> @@ -543,11 +548,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;
>>
>> Why do we change this, is it that the bootloader for mt6779 set some values
>> in
>> the register we have to keep? In this case I think we should update the
>> regval
>> accordingly.
>
> For REG_MMU_CTRL_REG, bit[12] represents victim_tlb_en feature and
> victim_tlb is enable defaultly(bit[12]=1),but if we use "regval =
> F_MMU_TF_PROT_TO_PROGRAM_ADDR", victim_tlb will disable, it will drop
> iommu performace for mt6779
>
Got it. Please put that in a separate patch then.
Regards,
Matthias
>
>>
>>> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>>>
>>> regval = F_L2_MULIT_HIT_EN |
>>> @@ -797,6 +803,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,
>>> + .has_sub_comm = true,
>>> + .has_wr_len= true,
>>> + .has_misc_ctrl = true,
>>> + .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
>>> + .larbid_remap = {{0}, {1}, {2}, {3}, {5},
Re: [PATCH v4 3/7] iommu/mediatek: Set MISC_CTRL register
On 17/06/2020 05:00, Chao Hao wrote:
> Add F_MMU_IN_ORDER_WR_EN definition in MISC_CTRL.
> In order to improve performance, we always disable STANDARD_AXI_MODE
> and IN_ORDER_WR_EN in MISC_CTRL.
>
> Change since v3:
The changelog should go below the '---' as we don't want this in the git history
once the patch get's accepted.
> 1. Rename Disable STANDARD_AXI_MODE in MISC_CTRL to Set MISC_CTRL register
> 2. Add F_MMU_IN_DRDER_WR_EN definition in MISC_CTRL
>We need to disable in_order_write to improve performance
>
> Cc: Yong Wu
> Signed-off-by: Chao Hao
> ---
> 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 88d3df5b91c2..239d2cdbbc9f 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_CTRL0x048
> +#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
> @@ -578,6 +581,14 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> writel_relaxed(0, data->base + REG_MMU_MISC_CTRL);
> }
>
> + if (data->plat_data->has_misc_ctrl) {
That's confusing. We renamed the register to misc_ctrl, but it's present in all
SoCs. We should find a better name for this flag to describe what the hardware
supports.
Regards,
Matthias
> + /* For mm_iommu, it can improve performance by the setting */
> + regval = readl_relaxed(data->base + REG_MMU_MISC_CTRL);
> + regval &= ~F_MMU_STANDARD_AXI_MODE_BIT;
> + 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)) {
> writel_relaxed(0, data->base + REG_MMU_PT_BASE_ADDR);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 1b6ea839b92c..d711ac630037 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -40,6 +40,7 @@ struct mtk_iommu_plat_data {
>
> /* HW will use the EMI clock if there isn't the "bclk". */
> boolhas_bclk;
> + boolhas_misc_ctrl;
> boolhas_vld_pa_rng;
> boolreset_axi;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 7/7] iommu/mediatek: Add mt6779 basic support
On 17/06/2020 05:00, 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. Change PROTECT_PA_ALIGN from 128 byte to 256 byte.
> 3. For REG_MMU_CTRL_REG register, we only need to change bit[2:0],
>others bits keep default value, ex: enable victim tlb.
> 4. Add mt6779_data to support mm_iommu HW init.
>
> Change since v3:
> 1. When setting MMU_CTRL_REG, we don't need to include mt8173.
>
> Cc: Yong Wu
> Signed-off-by: Chao Hao
> ---
> drivers/iommu/mtk_iommu.c | 20 ++--
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index c706bca6487e..def2e996683f 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -37,6 +37,11 @@
> #define REG_MMU_INVLD_START_A0x024
> #define REG_MMU_INVLD_END_A 0x028
>
> +/* In latest Coda, MMU_INV_SEL's offset is changed to 0x02c.
> + * So we named offset = 0x02c to "REG_MMU_INV_SEL_GEN2"
> + * and offset = 0x038 to "REG_MMU_INV_SEL_GEN1".
> + */
Please delete the comment, this should be understandable from the git history
> +#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)
> @@ -98,7 +103,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
Do we need 512 bytes for all gen2 IOMMUs?
I'm not sure if we should add this in plat_data or if we should just bump up the
value for all SoCs.
In both cases this should be a separate patch.
>
> /*
> * Get the local arbiter ID and the portid within the larb arbiter
> @@ -543,11 +548,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;
Why do we change this, is it that the bootloader for mt6779 set some values in
the register we have to keep? In this case I think we should update the regval
accordingly.
> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>
> regval = F_L2_MULIT_HIT_EN |
> @@ -797,6 +803,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,
> + .has_sub_comm = true,
> + .has_wr_len= true,
> + .has_misc_ctrl = true,
> + .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,
> .has_4gb_mode = true,
> @@ -815,6 +830,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 = _data},
> + { .compatible = "mediatek,mt6779-m4u", .data = _data},
> { .compatible = "mediatek,mt8173-m4u", .data = _data},
> { .compatible = "mediatek,mt8183-m4u", .data = _data},
> {}
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 9971cedd72ea..fb79e710c8d9 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -31,6 +31,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
Re: [PATCH v4 6/7] iommu/mediatek: Add REG_MMU_WR_LEN definition preparing for mt6779
On 17/06/2020 05:00, Chao Hao wrote:
> Some platforms(ex: mt6779) have a new register called by REG_MMU_WR_LEN
> to improve performance.
> This patch add this register definition.
Please be more specific what this register is about.
>
> Signed-off-by: Chao Hao
> ---
> 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 a687e8db0e51..c706bca6487e 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)
> @@ -581,6 +583,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 (data->plat_data->has_wr_len) {
> + /* 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);
> + }
>
> if (data->plat_data->reset_axi) {
> /* The register is called STANDARD_AXI_MODE in this case */
> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device
> *dev)
> struct mtk_iommu_suspend_reg *reg = >reg;
> void __iomem *base = data->base;
>
> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
Can we read/write the register without any side effect although hardware has not
implemented it (!has_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 d51ff99c2c71..9971cedd72ea 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -25,6 +25,7 @@ struct mtk_iommu_suspend_reg {
> u32 int_main_control;
> u32 ivrp_paddr;
> u32 vld_pa_rng;
> + u32 wr_len;
> };
>
> enum mtk_iommu_plat {
> @@ -43,6 +44,7 @@ struct mtk_iommu_plat_data {
> boolhas_misc_ctrl;
> boolhas_sub_comm;
> boolhas_vld_pa_rng;
> + boolhas_wr_len;
Given the fact that we are adding more and more plat_data bool values, I think
it would make sense to use a u32 flags register and add the appropriate macro
definitions to set and check for a flag present.
Regards,
Matthias
> boolreset_axi;
> u32 inv_sel_reg;
> unsigned char larbid_remap[8][4];
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 5/7] iommu/mediatek: Add sub_comm id in translation fault
On 17/06/2020 05:00, 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 variable, we could get the real larb number when
> translation fault happen.
> The diagram is as below:
>EMI
> |
> IOMMU
> |
>-
> | |
> common1 common0
> | |
> -
> |
> smi common
> |
>
> | | | | ||
> 3'd03'd13'd23'd3 ... 3'd7 <-common_id(max is 8)
> | | | | ||
> Larb0 Larb1 | Larb3 ... Larb7
> |
> smi sub common
> |
> --
> || | |
> 2'd0 2'd12'd22'd3 <-sub_common_id(max is 4)
> || | |
>Larb8Larb9 Larb10 Larb11
>
> In this patch we extern larb_remap[] to larb_remap[8][4] for this.
extern -> extend
> larb_remap[x][y]: x mean common-id above, y means subcommon_id above.
mean -> means
>
> We can also distinguish if the M4U HW has sub_common by has_sub_comm
> property.
>
> Signed-off-by: Chao Hao
> Reviewed-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 20 +---
> drivers/iommu/mtk_iommu.h | 3 ++-
> 2 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index f23919feba4e..a687e8db0e51 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -91,6 +91,8 @@
> #define REG_MMU1_INVLD_PA0x148
> #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 (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(>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 = true,
> .has_vld_pa_rng = true,
> .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 = true,
> .reset_axi= true,
> .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,
> .reset_axi= true,
> .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 afd7a2de5c1e..d51ff99c2c71 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -41,10 +41,11 @@ struct mtk_iommu_plat_data {
> /* HW will use the EMI clock if
Re: [PATCH v4 4/7] iommu/mediatek: Move inv_sel_reg into the plat_data
On 17/06/2020 05:00, Chao Hao wrote:
> 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.
>
> Change since v3:
> 1. Fix coding style
>
> Cc: Yong Wu
> Signed-off-by: Chao Hao
Reviewed-by: Mattias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 19 +++
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 239d2cdbbc9f..f23919feba4e 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -37,7 +37,7 @@
> #define REG_MMU_INVLD_START_A0x024
> #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(>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,
> @@ -773,11 +773,12 @@ 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,
> - .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> + .m4u_plat = M4U_MT2712,
> + .has_4gb_mode = true,
> + .has_bclk = true,
> + .has_vld_pa_rng = true,
> + .inv_sel_reg= REG_MMU_INV_SEL_GEN1,
> + .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> @@ -785,12 +786,14 @@ static const struct mtk_iommu_plat_data mt8173_data = {
> .has_4gb_mode = true,
> .has_bclk = true,
> .reset_axi= true,
> + .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,
> .reset_axi= true,
> + .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 d711ac630037..afd7a2de5c1e 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -43,6 +43,7 @@ struct mtk_iommu_plat_data {
> boolhas_misc_ctrl;
> boolhas_vld_pa_rng;
> boolreset_axi;
> + u32 inv_sel_reg;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 2/7] iommu/mediatek: Rename the register STANDARD_AXI_MODE(0x48) to MISC_CTRL
On 17/06/2020 05:00, 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
> Reviewed-by: Yong Wu
Reviewed-by: Matthias Brugger
> ---
> 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_MODE0x048
> +#define REG_MMU_MISC_CTRL0x048
> #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 = >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
>
> struct mtk_iommu_suspend_reg {
> - u32 standard_axi_mode;
> + u32 misc_ctrl;
> u32 dcm_dis;
> u32 ctrl_reg;
> u32 int_control0;
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/3] arm64: mm: reserve hugetlb CMA after numa_init
On 08/06/2020 02:50, Song Bao Hua (Barry Song) wrote:
>
>
>> -Original Message-----
>> From: Matthias Brugger [mailto:matthias@gmail.com]
>> Sent: Monday, June 8, 2020 8:15 AM
>> To: Roman Gushchin ; Song Bao Hua (Barry Song)
>>
>> Cc: catalin.mari...@arm.com; John Garry ;
>> linux-ker...@vger.kernel.org; Linuxarm ;
>> iommu@lists.linux-foundation.org; Zengtao (B) ;
>> Jonathan Cameron ;
>> robin.mur...@arm.com; h...@lst.de; linux-arm-ker...@lists.infradead.org;
>> m.szyprow...@samsung.com
>> Subject: Re: [PATCH 2/3] arm64: mm: reserve hugetlb CMA after numa_init
>>
>>
>>
>> On 03/06/2020 05:22, Roman Gushchin wrote:
>>> On Wed, Jun 03, 2020 at 02:42:30PM +1200, Barry Song wrote:
>>>> hugetlb_cma_reserve() is called at the wrong place. numa_init has not been
>>>> done yet. so all reserved memory will be located at node0.
>>>>
>>>> Cc: Roman Gushchin
>>>> Signed-off-by: Barry Song
>>>
>>> Acked-by: Roman Gushchin
>>>
>>
>> When did this break or was it broken since the beginning?
>> In any case, could you provide a "Fixes" tag for it, so that it can easily be
>> backported to older releases.
>
> I guess it was broken at the first beginning.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf11e85fc08cc
>
> Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages
> using cma")
>
> Would you think it is better for me to send v2 for this patch separately with
> this tag and take this out of my original patch set for per-numa CMA?
> Please give your suggestion.
>
I'm not the maintainer but I think it could help to get the patch accepted
earlier while you address the rest of the series.
Regards,
Matthias
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/3] arm64: mm: reserve hugetlb CMA after numa_init
On 03/06/2020 05:22, Roman Gushchin wrote: > On Wed, Jun 03, 2020 at 02:42:30PM +1200, Barry Song wrote: >> hugetlb_cma_reserve() is called at the wrong place. numa_init has not been >> done yet. so all reserved memory will be located at node0. >> >> Cc: Roman Gushchin >> Signed-off-by: Barry Song > > Acked-by: Roman Gushchin > When did this break or was it broken since the beginning? In any case, could you provide a "Fixes" tag for it, so that it can easily be backported to older releases. Regards, Matthias > Thanks! > >> --- >> arch/arm64/mm/init.c | 10 +- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c >> index e42727e3568e..8f0e70ebb49d 100644 >> --- a/arch/arm64/mm/init.c >> +++ b/arch/arm64/mm/init.c >> @@ -458,11 +458,6 @@ void __init arm64_memblock_init(void) >> high_memory = __va(memblock_end_of_DRAM() - 1) + 1; >> >> dma_contiguous_reserve(arm64_dma32_phys_limit); >> - >> -#ifdef CONFIG_ARM64_4K_PAGES >> -hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); >> -#endif >> - >> } >> >> void __init bootmem_init(void) >> @@ -478,6 +473,11 @@ void __init bootmem_init(void) >> min_low_pfn = min; >> >> arm64_numa_init(); >> + >> +#ifdef CONFIG_ARM64_4K_PAGES >> +hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); >> +#endif >> + >> /* >> * Sparsemem tries to allocate bootmem in memory_present(), so must be >> * done after the fixed reservations. >> -- >> 2.23.0 >> >> > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v10 23/23] iommu/mediatek: Clean up struct mtk_smi_iommu
On 21/08/2019 15:53, Yong Wu wrote:
> Remove the "struct mtk_smi_iommu" to simplify the code since it has only
> one item in it right now.
>
> Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c| 4 ++--
> drivers/iommu/mtk_iommu.h| 6 +++---
> drivers/iommu/mtk_iommu_v1.c | 4 ++--
> drivers/memory/mtk-smi.c | 6 +++---
> include/soc/mediatek/smi.h | 4
> 5 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index cc81de2..400066d 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -278,7 +278,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
> for (i = 0; i < fwspec->num_ids; ++i) {
> larbid = MTK_M4U_TO_LARB(fwspec->ids[i]);
> portid = MTK_M4U_TO_PORT(fwspec->ids[i]);
> - larb_mmu = >smi_imu.larb_imu[larbid];
> + larb_mmu = >larb_imu[larbid];
>
> dev_dbg(dev, "%s iommu port: %d\n",
> enable ? "enable" : "disable", portid);
> @@ -680,7 +680,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> of_node_put(larbnode);
> return -EPROBE_DEFER;
> }
> - data->smi_imu.larb_imu[id].dev = >dev;
> + data->larb_imu[id].dev = >dev;
>
> component_match_add_release(dev, , release_of,
> compare_of, larbnode);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 56b579c..fc0f16e 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -56,7 +56,6 @@ struct mtk_iommu_data {
> struct mtk_iommu_suspend_regreg;
> struct mtk_iommu_domain *m4u_dom;
> struct iommu_group *m4u_group;
> - struct mtk_smi_iommusmi_imu; /* SMI larb iommu info */
> boolenable_4GB;
> booltlb_flush_active;
>
> @@ -64,6 +63,7 @@ struct mtk_iommu_data {
> const struct mtk_iommu_plat_data *plat_data;
>
> struct list_headlist;
> + struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
> };
>
> static inline int compare_of(struct device *dev, void *data)
> @@ -80,14 +80,14 @@ static inline int mtk_iommu_bind(struct device *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
>
> - return component_bind_all(dev, >smi_imu);
> + return component_bind_all(dev, >larb_imu);
> }
>
> static inline void mtk_iommu_unbind(struct device *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
>
> - component_unbind_all(dev, >smi_imu);
> + component_unbind_all(dev, >larb_imu);
> }
>
> #endif
> diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
> index 3922358..860926c 100644
> --- a/drivers/iommu/mtk_iommu_v1.c
> +++ b/drivers/iommu/mtk_iommu_v1.c
> @@ -206,7 +206,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
> for (i = 0; i < fwspec->num_ids; ++i) {
> larbid = mt2701_m4u_to_larb(fwspec->ids[i]);
> portid = mt2701_m4u_to_port(fwspec->ids[i]);
> - larb_mmu = >smi_imu.larb_imu[larbid];
> + larb_mmu = >larb_imu[larbid];
>
> dev_dbg(dev, "%s iommu port: %d\n",
> enable ? "enable" : "disable", portid);
> @@ -610,7 +610,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> }
> }
>
> - data->smi_imu.larb_imu[larb_nr].dev = >dev;
> + data->larb_imu[larb_nr].dev = >dev;
> component_match_add_release(dev, , release_of,
> compare_of, larb_spec.np);
> larb_nr++;
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index d6dc62f..439d7d8 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -143,13 +143,13 @@ void mtk_smi_larb_put(struct device *larbdev)
> mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
> {
> struct mtk_smi_larb *larb = dev_get_drvdata(dev);
> - struct mtk_smi_iommu *smi_iommu = data;
> + struct mtk_smi_larb_iommu *larb_mmu = data;
> unsigned int i;
>
> for (i = 0; i < MTK_LARB_NR_MAX; i++) {
> - if (dev == smi_iommu->larb_imu[i
Re: [PATCH v7 19/21] iommu/mediatek: Rename enable_4GB to dram_is_4gb
On 20/06/2019 15:59, Yong Wu wrote:
> On Tue, 2019-06-18 at 18:06 +0200, Matthias Brugger wrote:
>>
>> On 10/06/2019 14:17, Yong Wu wrote:
>>> This patch only rename the variable name from enable_4GB to
>>> dram_is_4gb for readable.
>>
>> From my understanding this is true when available RAM > 4GB so I think the
>> name
>> should be something like dram_bigger_4gb otherwise it may create confusion
>> again.
>
> Strictly, It is not "dram_bigger_4gb". actually if the dram size is over
> 3GB (the first 1GB is the register space), the "4GB mode" will be
> enabled. then how about the name "dram_enable_32bit"?(the PA 32bit will
> be enabled in the 4GB mode.)
Ok I think dram_is_4gb is ok then. But I'd suggest to add an explanation above
the struct mtk_iommu_data to explain exactly what this means.
>
> There is another option, please see the last part in [1] suggested by
> Evan, something like below:
>
> data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> if (!data->plat_data->has_4gb_mode)
> data->enable_4GB = false;
> Then mtk_iommu_map would only have:
> if (data->enable_4GB)
> paddr |= BIT_ULL(32);
>
I think that's a nicer way to handle it.
Regards,
Matthias
>
> Which one do you prefer?
>
> [1] https://lore.kernel.org/patchwork/patch/1028421/
>
>>
>> Also from my point of view this patch should be done before
>> "[PATCH 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode"
>
> OK.
>
>>
>> Regards,
>> Matthias
>>
>>>
>>> Signed-off-by: Yong Wu
>>> Reviewed-by: Evan Green
>>> ---
>>> drivers/iommu/mtk_iommu.c | 10 +-
>>> drivers/iommu/mtk_iommu.h | 2 +-
>>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index 86158d8..67cab2d 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -382,7 +382,7 @@ static int mtk_iommu_map(struct iommu_domain *domain,
>>> unsigned long iova,
>>> int ret;
>>>
>>> /* The "4GB mode" M4U physically can not use the lower remap of Dram. */
>>> - if (data->plat_data->has_4gb_mode && data->enable_4GB)
>>> + if (data->plat_data->has_4gb_mode && data->dram_is_4gb)
>>> paddr |= BIT_ULL(32);
>>>
>>> spin_lock_irqsave(>pgtlock, flags);
>>> @@ -554,13 +554,13 @@ static int mtk_iommu_hw_init(const struct
>>> mtk_iommu_data *data)
>>> writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
>>>
>>> if (data->plat_data->m4u_plat == M4U_MT8173)
>>> - regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
>>> + regval = (data->protect_base >> 1) | (data->dram_is_4gb << 31);
>>> else
>>> regval = lower_32_bits(data->protect_base) |
>>> 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->dram_is_4gb && data->plat_data->has_vld_pa_rng) {
>>> /*
>>> * If 4GB mode is enabled, the validate PA range is from
>>> * 0x1__ to 0x1__. here record bit[32:30].
>>> @@ -611,8 +611,8 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>>> return -ENOMEM;
>>> data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
>>>
>>> - /* Whether the current dram is over 4GB */
>>> - data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
>>> + /* Whether the current dram is 4GB. */
>>> + data->dram_is_4gb = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
>>>
>>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> data->base = devm_ioremap_resource(dev, res);
>>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
>>> index 753266b..e8114b2 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -65,7 +65,7 @@ struct mtk_iommu_data {
>>> struct mtk_iommu_domain *m4u_dom;
>>> struct iommu_group *m4u_group;
>>> struct mtk_smi_iommusmi_imu; /* SMI larb iommu info */
>>> - boolenable_4GB;
>>> + booldram_is_4gb;
>>> booltlb_flush_active;
>>>
>>> struct iommu_device iommu;
>>>
>
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 05/12] media: mtk-jpeg: Get rid of mtk_smi_larb_get/put
On 10/06/2019 14:55, Yong Wu wrote:
> MediaTek IOMMU has already added device_link between the consumer
> and smi-larb device. If the jpg device call the pm_runtime_get_sync,
> the smi-larb's pm_runtime_get_sync also be called automatically.
Please help me out find this relation. I seem to miss something basic, because I
can't find any between the jpeg IP and the iommu.
Regards,
Matthias
>
> CC: Rick Chang
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
> ---
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 22 --
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 --
> 2 files changed, 24 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> index f761e4d..2f37538 100644
> --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> @@ -29,7 +29,6 @@
> #include
> #include
> #include
> -#include
>
> #include "mtk_jpeg_hw.h"
> #include "mtk_jpeg_core.h"
> @@ -901,11 +900,6 @@ static int mtk_jpeg_queue_init(void *priv, struct
> vb2_queue *src_vq,
>
> static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
> {
> - int ret;
> -
> - ret = mtk_smi_larb_get(jpeg->larb);
> - if (ret)
> - dev_err(jpeg->dev, "mtk_smi_larb_get larbvdec fail %d\n", ret);
> clk_prepare_enable(jpeg->clk_jdec_smi);
> clk_prepare_enable(jpeg->clk_jdec);
> }
> @@ -914,7 +908,6 @@ static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg)
> {
> clk_disable_unprepare(jpeg->clk_jdec);
> clk_disable_unprepare(jpeg->clk_jdec_smi);
> - mtk_smi_larb_put(jpeg->larb);
> }
>
> static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
> @@ -1059,21 +1052,6 @@ static int mtk_jpeg_release(struct file *file)
>
> static int mtk_jpeg_clk_init(struct mtk_jpeg_dev *jpeg)
> {
> - struct device_node *node;
> - struct platform_device *pdev;
> -
> - node = of_parse_phandle(jpeg->dev->of_node, "mediatek,larb", 0);
> - if (!node)
> - return -EINVAL;
> - pdev = of_find_device_by_node(node);
> - if (WARN_ON(!pdev)) {
> - of_node_put(node);
> - return -EINVAL;
> - }
> - of_node_put(node);
> -
> - jpeg->larb = >dev;
> -
> jpeg->clk_jdec = devm_clk_get(jpeg->dev, "jpgdec");
> if (IS_ERR(jpeg->clk_jdec))
> return PTR_ERR(jpeg->clk_jdec);
> diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> index 1a6cdfd..e35fb79 100644
> --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> @@ -55,7 +55,6 @@ enum mtk_jpeg_ctx_state {
> * @dec_reg_base:JPEG registers mapping
> * @clk_jdec:JPEG hw working clock
> * @clk_jdec_smi:JPEG SMI bus clock
> - * @larb:SMI device
> */
> struct mtk_jpeg_dev {
> struct mutexlock;
> @@ -69,7 +68,6 @@ struct mtk_jpeg_dev {
> void __iomem*dec_reg_base;
> struct clk *clk_jdec;
> struct clk *clk_jdec_smi;
> - struct device *larb;
> };
>
> /**
>
Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
CCing Sascha
On 20/06/2019 11:35, Matthias Brugger wrote:
>
>
> On 13/06/2019 10:14, Pi-Hsun Shih wrote:
>> Hi,
>> When I tested this patch series (Based on linux 5.2.0-rc2, and with
>> various other patch series about MT8183) with lockdep enabled, and I'm
>> seeing the following lockdep warning on boot.
>>
>> By bisecting the commits, the first commit that introduce this warning
>> is this patch. The warning also doesn't appear if
>> https://lore.kernel.org/patchwork/patch/1086582/ and
>> https://lore.kernel.org/patchwork/patch/1086583/ are not applied.
>>
>> Do anyone have idea on why this is happening, or any suggestion on
>> which part I should be digging into to figure this out? Thanks.
>>
>> [4.664194] ==
>> [4.670368] WARNING: possible circular locking dependency detected
>> [4.676545] 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20 Tainted: G S
>> [4.684539] --
>> [4.690714] kworker/4:1/51 is trying to acquire lock:
>> [4.695760] (ptrval) (regulator_list_mutex){+.+.},
>> at:regulator_lock_dependent+0xdc/0x6c4
>> [4.704732]
>> [4.704732] but task is already holding lock:
>> [4.710556] (ptrval) (>mlock/1){+.+.},
>> at:genpd_lock_nested_mtx+0x24/0x30
>> [4.718740]
>> [4.718740] which lock already depends on the new lock.
>> [4.718740]
>> [4.726908]
>> [4.726908] the existing dependency chain (in reverse order) is:
>> [4.734382]
>> [4.734382] -> #4 (>mlock/1){+.+.}:
>> [4.739963]__mutex_lock_common+0x1a0/0x1fe8
>> [4.744836]mutex_lock_nested+0x40/0x50
>> [4.749275]genpd_lock_nested_mtx+0x24/0x30
>> [4.754063]genpd_add_subdomain+0x150/0x524
>> [4.758850]pm_genpd_add_subdomain+0x3c/0x5c
>> [4.763723]scpsys_probe+0x520/0xe78
>> [4.767902]platform_drv_probe+0xf4/0x134
>> [4.772517]really_probe+0x214/0x4dc
>> [4.776696]driver_probe_device+0xcc/0x1d4
>> [4.781396]__device_attach_driver+0x10c/0x180
>> [4.786442]bus_for_each_drv+0x124/0x184
>> [4.790968]__device_attach+0x1c0/0x2d8
>> [4.795407]device_initial_probe+0x20/0x2c
>> [4.800106]bus_probe_device+0x80/0x16c
>> [4.804546]deferred_probe_work_func+0x120/0x168
>> [4.809767]process_one_work+0x858/0x1208
>> [4.814379]worker_thread+0x9ec/0xcb8
>> [4.818644]kthread+0x2b8/0x2d0
>> [4.822391]ret_from_fork+0x10/0x18
>> [4.826480]
>> [4.826480] -> #3 (>mlock){+.+.}:
>> [4.831880]__mutex_lock_common+0x1a0/0x1fe8
>> [4.836752]mutex_lock_nested+0x40/0x50
>> [4.841190]genpd_lock_mtx+0x20/0x2c
>> [4.845369]genpd_runtime_resume+0x140/0x434
>> [4.850241]__rpm_callback+0xb0/0x1e4
>> [4.854506]rpm_callback+0x54/0x1a8
>> [4.858597]rpm_resume+0xc6c/0x10c4
>> [4.862689]__pm_runtime_resume+0xb4/0x124
>> [4.867387]device_link_add+0x598/0x8d0
>
> For this looks as if you have also patch
> [PATCH v2 04/12] memory: mtk-smi: Add device-link between smi-larb and
> smi-common
> from series
> [PATCH v2 00/12] Clean up "mediatek,larb" after adding device_link
> applied.
>
My guess is, that we run into this, because we call genpd_runtime_resume before
we have finished the subdomain registration in scpsys_probe.
That implies that you also have the scpsys series for mt8183 added to your tree.
Anyway it looks to me as if we have to add the subdomains before we call
of_genpd_add_provider_onecell().
Regards,
Matthias
> Regards,
> Matthias
>
>> [4.871829]mtk_smi_larb_probe+0x2b0/0x340
>> [4.876528]platform_drv_probe+0xf4/0x134
>> [4.881141]really_probe+0x214/0x4dc
>> [4.885320]driver_probe_device+0xcc/0x1d4
>> [4.890020]__device_attach_driver+0x10c/0x180
>> [4.895066]bus_for_each_drv+0x124/0x184
>> [4.899591]__device_attach+0x1c0/0x2d8
>> [4.904031]device_initial_probe+0x20/0x2c
>> [4.908730]bus_probe_device+0x80/0x16c
>> [4.913169]deferred_probe_work_func+0x120/0x168
>> [4.918387]process_one_work+0x858/0x1208
>> [4.923000]worker_thread+0x9ec/0xcb8
>> [4.927264]kthread+0x2b8/0x2d0
>> [4.931009]
Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
d8/0x6a0
> [5.449310] genpd_power_off+0x530/0x6a0
> [5.453229] genpd_power_off_work_fn+0x74/0xc0
> [5.457667] process_one_work+0x858/0x1208
> [5.461758] worker_thread+0x9ec/0xcb8
> [5.465503] kthread+0x2b8/0x2d0
> [5.468727] ret_from_fork+0x10/0x18
>
> On Mon, Jun 10, 2019 at 8:21 PM Yong Wu wrote:
>> ...
>
>
> On Mon, Jun 10, 2019 at 8:21 PM Yong Wu wrote:
>
>> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
>> mmu0 or mmu1 to balance the bandwidth via the smi-common register
>> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>>
>> In mt8183, For better performance, we switch larb1/2/5/7 to enter
>> mmu1 while the others still keep enter mmu0.
>>
>> In mt8173 and mt2712, we don't get the performance issue,
>> Keep its default value(0x0), that means all the larbs enter mmu0.
>>
>> Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
>>
>> And, the base of smi-common is completely different with smi_ao_base
>> of gen1, thus I add new variable for that.
>>
>> CC: Matthias Brugger
>> Signed-off-by: Yong Wu
>> Reviewed-by: Evan Green
>> ---
>> drivers/memory/mtk-smi.c | 22 --
>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>> index 9790801..08cf40d 100644
>> --- a/drivers/memory/mtk-smi.c
>> +++ b/drivers/memory/mtk-smi.c
>> @@ -49,6 +49,12 @@
>> #define SMI_LARB_NONSEC_CON(id)(0x380 + ((id) * 4))
>> #define F_MMU_EN BIT(0)
>>
>> +/* SMI COMMON */
>> +#define SMI_BUS_SEL0x220
>> +#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
>> +/* All are MMU0 defaultly. Only specialize mmu1 here. */
>> +#define F_MMU1_LARB(larbid)(0x1 << SMI_BUS_LARB_SHIFT(larbid))
>> +
>> enum mtk_smi_gen {
>> MTK_SMI_GEN1,
>> MTK_SMI_GEN2
>> @@ -57,6 +63,7 @@ enum mtk_smi_gen {
>> struct mtk_smi_common_plat {
>> enum mtk_smi_gen gen;
>> bool has_gals;
>> + u32 bus_sel; /* Balance some larbs to enter mmu0 or
>> mmu1 */
>> };
>>
>> struct mtk_smi_larb_gen {
>> @@ -72,8 +79,8 @@ struct mtk_smi {
>> struct clk *clk_apb, *clk_smi;
>> struct clk *clk_gals0, *clk_gals1;
>> struct clk *clk_async; /*only needed by
>> mt2701*/
>> - void __iomem*smi_ao_base;
>> -
>> + void __iomem*smi_ao_base; /* only for gen1 */
>> + void __iomem*base;/* only for gen2 */
>> const struct mtk_smi_common_plat *plat;
>> };
>>
>> @@ -410,6 +417,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
>> device *dev)
>> static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
>> .gen = MTK_SMI_GEN2,
>> .has_gals = true,
>> + .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
>> + F_MMU1_LARB(7),
>> };
>>
>> static const struct of_device_id mtk_smi_common_of_ids[] = {
>> @@ -482,6 +491,11 @@ static int mtk_smi_common_probe(struct
>> platform_device *pdev)
>> ret = clk_prepare_enable(common->clk_async);
>> if (ret)
>> return ret;
>> + } else {
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + common->base = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(common->base))
>> + return PTR_ERR(common->base);
>> }
>> pm_runtime_enable(dev);
>> platform_set_drvdata(pdev, common);
>> @@ -497,6 +511,7 @@ static int mtk_smi_common_remove(struct
>> platform_device *pdev)
>> static int __maybe_unused mtk_smi_common_resume(struct device *dev)
>> {
>> struct mtk_smi *common = dev_get_drvdata(dev);
>> + u32 bus_sel = common->plat->bus_sel;
>> int ret;
>>
>> ret = mtk_smi_clk_enable(common);
>> @@ -504,6 +519,9 @@ static int __maybe_unused mtk_smi_common_resume(struct
>> device *dev)
>> dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
>> return ret;
>> }
>> +
>> + if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
>> + writel(bus_sel, common->base + SMI_BUS_SEL);
>> return 0;
>> }
>>
>> --
>> 1.9.1
>>
>>
>
Re: [PATCH v2 02/12] iommu/mediatek: Add probe_defer for smi-larb
On 10/06/2019 14:55, Yong Wu wrote:
> The iommu consumer should use device_link to connect with the
> smi-larb(supplier). then the smi-larb should run before the iommu
> consumer. Here we delay the iommu driver until the smi driver is
> ready, then all the iommu consumer always is after the smi driver.
>
> When there is no this patch, if some consumer drivers run before
> smi-larb, the supplier link_status is DL_DEV_NO_DRIVER(0) in the
> device_link_add, then device_links_driver_bound will use WARN_ON
> to complain that the link_status of supplier is not right.
>
> This is a preparing patch for adding device_link.
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c| 2 +-
> drivers/iommu/mtk_iommu_v1.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 6fe3369..f7599d8 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -664,7 +664,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> id = i;
>
> plarbdev = of_find_device_by_node(larbnode);
> - if (!plarbdev) {
> + if (!plarbdev || !plarbdev->dev.driver) {
can't we use:
device_lock()
device_is_bound(struct device *dev)
device_unlock()
> of_node_put(larbnode);
> return -EPROBE_DEFER;
> }
> diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
> index 0b0908c..c43c4a0 100644
> --- a/drivers/iommu/mtk_iommu_v1.c
> +++ b/drivers/iommu/mtk_iommu_v1.c
> @@ -604,7 +604,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> plarbdev = of_platform_device_create(
> larb_spec.np, NULL,
> platform_bus_type.dev_root);
> - if (!plarbdev) {
> + if (!plarbdev || !plarbdev->dev.driver) {
> of_node_put(larb_spec.np);
> return -EPROBE_DEFER;
> }
>
Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
On 18/06/2019 14:10, Yong Wu wrote:
> On Mon, 2019-06-17 at 18:23 +0200, Matthias Brugger wrote:
>>
>> On 10/06/2019 14:17, Yong Wu wrote:
>>> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
>>> mmu0 or mmu1 to balance the bandwidth via the smi-common register
>>> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>>>
>>> In mt8183, For better performance, we switch larb1/2/5/7 to enter
>>> mmu1 while the others still keep enter mmu0.
>>>
>>> In mt8173 and mt2712, we don't get the performance issue,
>>> Keep its default value(0x0), that means all the larbs enter mmu0.
>>>
>>> Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
>>>
>>> And, the base of smi-common is completely different with smi_ao_base
>>> of gen1, thus I add new variable for that.
>>>
>>> CC: Matthias Brugger
>>> Signed-off-by: Yong Wu
>>> Reviewed-by: Evan Green
>>> ---
>>> drivers/memory/mtk-smi.c | 22 --
>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>>> index 9790801..08cf40d 100644
>>> --- a/drivers/memory/mtk-smi.c
>>> +++ b/drivers/memory/mtk-smi.c
>>> @@ -49,6 +49,12 @@
>>> #define SMI_LARB_NONSEC_CON(id)(0x380 + ((id) * 4))
>>> #define F_MMU_EN BIT(0)
>>>
>>> +/* SMI COMMON */
>>> +#define SMI_BUS_SEL0x220
>>> +#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
>>> +/* All are MMU0 defaultly. Only specialize mmu1 here. */
>>> +#define F_MMU1_LARB(larbid)(0x1 <<
>>> SMI_BUS_LARB_SHIFT(larbid))
>>> +
>>> enum mtk_smi_gen {
>>> MTK_SMI_GEN1,
>>> MTK_SMI_GEN2
>>> @@ -57,6 +63,7 @@ enum mtk_smi_gen {
>>> struct mtk_smi_common_plat {
>>> enum mtk_smi_gen gen;
>>> bool has_gals;
>>> + u32 bus_sel; /* Balance some larbs to enter mmu0 or mmu1 */
>>> };
>>>
>>> struct mtk_smi_larb_gen {
>>> @@ -72,8 +79,8 @@ struct mtk_smi {
>>> struct clk *clk_apb, *clk_smi;
>>> struct clk *clk_gals0, *clk_gals1;
>>> struct clk *clk_async; /*only needed by mt2701*/
>>> - void __iomem*smi_ao_base;
>>> -
>>> + void __iomem*smi_ao_base; /* only for gen1 */
>>> + void __iomem*base;/* only for gen2 */
>>
>> union {} maybe?
>
> Yes. Thanks.
>
> I will add it.
>
>>
>>> const struct mtk_smi_common_plat *plat;
>>> };
>>>
>>> @@ -410,6 +417,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
>>> device *dev)
>>> static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
>>> .gen = MTK_SMI_GEN2,
>>> .has_gals = true,
>>> + .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
>>> + F_MMU1_LARB(7),
>>> };
>>>
>>> static const struct of_device_id mtk_smi_common_of_ids[] = {
>>> @@ -482,6 +491,11 @@ static int mtk_smi_common_probe(struct platform_device
>>> *pdev)
>>> ret = clk_prepare_enable(common->clk_async);
>>> if (ret)
>>> return ret;
>>> + } else {
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + common->base = devm_ioremap_resource(dev, res);
>>> + if (IS_ERR(common->base))
>>> + return PTR_ERR(common->base);
>>
>> We must be backwards compatible with DT which does not have the base defined.
>
> The smi-common node in the previous mt2712 and mt8173 also have the
> "reg" property even though they didn't use this base, Thus, It looks ok
> for all the cases.
>
Correct, it is defined as a required property in the binding description so we
are good.
Sorry for the noise.
With the union added you can add:
Reviewed-by: Matthias Brugger
>>
>> Regards,
>> Matthias
>>
>>> }
>>> pm_runtime_enable(dev);
>>> platform_set_drvdata(pdev, common);
>>> @@ -497,6 +511,7 @@ static int mtk_smi_common_remove(struct platform_device
>>> *pdev)
>>> static int __maybe_unused mtk_smi_common_resume(struct device *dev)
>>> {
>>> struct mtk_smi *common = dev_get_drvdata(dev);
>>> + u32 bus_sel = common->plat->bus_sel;
>>> int ret;
>>>
>>> ret = mtk_smi_clk_enable(common);
>>> @@ -504,6 +519,9 @@ static int __maybe_unused mtk_smi_common_resume(struct
>>> device *dev)
>>> dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
>>> return ret;
>>> }
>>> +
>>> + if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
>>> + writel(bus_sel, common->base + SMI_BUS_SEL);
>>> return 0;
>>> }
>>>
>>>
>
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
On 10/06/2019 14:17, Yong Wu wrote:
> In the 4GB mode, the physical address is remapped,
>
> Here is the detailed remap relationship.
> CPU PA ->HW PA
> 0x4000_ 0x1_4000_ (Add bit32)
> 0x8000_ 0x1_8000_ ...
> 0xc000_ 0x1_c000_ ...
> 0x1__0x1__ (No change)
>
> Thus, we always add bit32 for PA when entering mtk_iommu_map.
> But in the iova_to_phys, the CPU don't need this bit32 if the
> PA is from 0x1_4000_ to 0x1__.
> This patch discards the bit32 in this iova_to_phys in the 4GB mode.
>
> Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
> for 4GB mode")
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 67cab2d..34f2e40 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -119,6 +119,19 @@ struct mtk_iommu_domain {
>
> static const struct iommu_ops mtk_iommu_ops;
>
> +/*
> + * In M4U 4GB mode, the physical address is remapped as below:
> + * CPU PA -> M4U HW PA
> + * 0x4000_ 0x1_4000_ (Add bit32)
> + * 0x8000_ 0x1_8000_ ...
> + * 0xc000_ 0x1_c000_ ...
> + * 0x1__ 0x1__ (No change)
> + *
> + * Thus, We always add BIT32 in the iommu_map and disable BIT32 if PA is >=
> + * 0x1_4000_ in the iova_to_phys.
> + */
> +#define MTK_IOMMU_4GB_MODE_PA_14000 0x14000UL
> +
> static LIST_HEAD(m4ulist); /* List all the M4U HWs */
>
> #define for_each_m4u(data) list_for_each_entry(data, , list)
> @@ -415,6 +428,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct
> iommu_domain *domain,
> dma_addr_t iova)
> {
> struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> + struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
> unsigned long flags;
> phys_addr_t pa;
>
> @@ -422,6 +436,10 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct
> iommu_domain *domain,
> pa = dom->iop->iova_to_phys(dom->iop, iova);
> spin_unlock_irqrestore(>pgtlock, flags);
>
> + if (data->plat_data->has_4gb_mode && data->dram_is_4gb &&
> + pa >= MTK_IOMMU_4GB_MODE_PA_14000)
> + pa &= ~BIT_ULL(32);
> +
Hm, I wonder if we could fix this as first patch in the series, especially
before:
"[PATCH 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode"
This would make it easier for the stable maintainer to cherry-pick the fix.
Without 100% understanding the code, it seems suspicious to me, that you first
move the setting of the bit32 and bit33 into v7s and later explicitly clean the
bits here.
So my take on this is, that patch 6/21 introduced the regression you are trying
to fix here. As said that is speculation as I don't understand the code in its
whole.
Any clarification would be useful.
Regards,
Matthias
> return pa;
> }
>
>
Re: [PATCH v7 19/21] iommu/mediatek: Rename enable_4GB to dram_is_4gb
On 10/06/2019 14:17, Yong Wu wrote:
> This patch only rename the variable name from enable_4GB to
> dram_is_4gb for readable.
>From my understanding this is true when available RAM > 4GB so I think the name
should be something like dram_bigger_4gb otherwise it may create confusion
again.
Also from my point of view this patch should be done before
"[PATCH 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode"
Regards,
Matthias
>
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
> ---
> drivers/iommu/mtk_iommu.c | 10 +-
> drivers/iommu/mtk_iommu.h | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 86158d8..67cab2d 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -382,7 +382,7 @@ static int mtk_iommu_map(struct iommu_domain *domain,
> unsigned long iova,
> int ret;
>
> /* The "4GB mode" M4U physically can not use the lower remap of Dram. */
> - if (data->plat_data->has_4gb_mode && data->enable_4GB)
> + if (data->plat_data->has_4gb_mode && data->dram_is_4gb)
> paddr |= BIT_ULL(32);
>
> spin_lock_irqsave(>pgtlock, flags);
> @@ -554,13 +554,13 @@ static int mtk_iommu_hw_init(const struct
> mtk_iommu_data *data)
> writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
>
> if (data->plat_data->m4u_plat == M4U_MT8173)
> - regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
> + regval = (data->protect_base >> 1) | (data->dram_is_4gb << 31);
> else
> regval = lower_32_bits(data->protect_base) |
>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->dram_is_4gb && data->plat_data->has_vld_pa_rng) {
> /*
>* If 4GB mode is enabled, the validate PA range is from
>* 0x1__ to 0x1__. here record bit[32:30].
> @@ -611,8 +611,8 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> return -ENOMEM;
> data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
>
> - /* Whether the current dram is over 4GB */
> - data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
> + /* Whether the current dram is 4GB. */
> + data->dram_is_4gb = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> data->base = devm_ioremap_resource(dev, res);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 753266b..e8114b2 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -65,7 +65,7 @@ struct mtk_iommu_data {
> struct mtk_iommu_domain *m4u_dom;
> struct iommu_group *m4u_group;
> struct mtk_smi_iommusmi_imu; /* SMI larb iommu info */
> - boolenable_4GB;
> + booldram_is_4gb;
> booltlb_flush_active;
>
> struct iommu_device iommu;
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 17/21] memory: mtk-smi: Get rid of need_larbid
On 10/06/2019 14:17, Yong Wu wrote:
> The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
> It's no need to parse it again in SMI driver. Only clean some codes.
> This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
> and mt8183.
>
> After this patch, the "mediatek,larb-id" only be needed for mt2712
> which have 2 M4Us. In the other SoCs, we can get the larb-id from M4U
> in which the larbs in the "mediatek,larbs" always are ordered.
>
> Correspondingly, the larb_nr in the "struct mtk_smi_iommu" could also
> be deleted.
>
I think we can get rid of struct mtk_smi_iommu and just add the
struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX] directly to mtk_iommu_data,
passing just that array to the components bind function.
Never the less this patch looks fine:
Reviewed-by: Matthias Brugger
> CC: Matthias Brugger
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
> ---
> drivers/iommu/mtk_iommu.c| 1 -
> drivers/iommu/mtk_iommu_v1.c | 2 --
> drivers/memory/mtk-smi.c | 26 ++
> include/soc/mediatek/smi.h | 1 -
> 4 files changed, 2 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index ec4ce74..6053b8b 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -634,7 +634,6 @@ static int mtk_iommu_probe(struct platform_device *pdev)
>"mediatek,larbs", NULL);
> if (larb_nr < 0)
> return larb_nr;
> - data->smi_imu.larb_nr = larb_nr;
>
> for (i = 0; i < larb_nr; i++) {
> struct device_node *larbnode;
> diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
> index 52b01e3..73308ad 100644
> --- a/drivers/iommu/mtk_iommu_v1.c
> +++ b/drivers/iommu/mtk_iommu_v1.c
> @@ -624,8 +624,6 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> larb_nr++;
> }
>
> - data->smi_imu.larb_nr = larb_nr;
> -
> platform_set_drvdata(pdev, data);
>
> ret = mtk_iommu_hw_init(data);
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index 08cf40d..10e6493 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -67,7 +67,6 @@ struct mtk_smi_common_plat {
> };
>
> struct mtk_smi_larb_gen {
> - bool need_larbid;
> int port_in_larb[MTK_LARB_NR_MAX + 1];
> void (*config_port)(struct device *);
> unsigned int larb_direct_to_common_mask;
> @@ -153,18 +152,9 @@ void mtk_smi_larb_put(struct device *larbdev)
> struct mtk_smi_iommu *smi_iommu = data;
> unsigned int i;
>
> - if (larb->larb_gen->need_larbid) {
> - larb->mmu = _iommu->larb_imu[larb->larbid].mmu;
> - return 0;
> - }
> -
> - /*
> - * If there is no larbid property, Loop to find the corresponding
> - * iommu information.
> - */
> - for (i = 0; i < smi_iommu->larb_nr; i++) {
> + for (i = 0; i < MTK_LARB_NR_MAX; i++) {
> if (dev == smi_iommu->larb_imu[i].dev) {
> - /* The 'mmu' may be updated in iommu-attach/detach. */
> + larb->larbid = i;
> larb->mmu = _iommu->larb_imu[i].mmu;
> return 0;
> }
> @@ -243,7 +233,6 @@ static void mtk_smi_larb_config_port_gen1(struct device
> *dev)
> };
>
> static const struct mtk_smi_larb_gen mtk_smi_larb_mt2701 = {
> - .need_larbid = true,
> .port_in_larb = {
> LARB0_PORT_OFFSET, LARB1_PORT_OFFSET,
> LARB2_PORT_OFFSET, LARB3_PORT_OFFSET
> @@ -252,7 +241,6 @@ static void mtk_smi_larb_config_port_gen1(struct device
> *dev)
> };
>
> static const struct mtk_smi_larb_gen mtk_smi_larb_mt2712 = {
> - .need_larbid = true,
> .config_port= mtk_smi_larb_config_port_gen2_general,
> .larb_direct_to_common_mask = BIT(8) | BIT(9), /* bdpsys */
> };
> @@ -291,7 +279,6 @@ static int mtk_smi_larb_probe(struct platform_device
> *pdev)
> struct device *dev = >dev;
> struct device_node *smi_node;
> struct platform_device *smi_pdev;
> - int err;
>
> larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
> if (!larb)
> @@ -321,15 +308,6 @@ static int mtk_smi_larb_probe(struct platform_device
> *pdev)
> }
> larb->smi.dev = dev;
>
> - if (larb->larb_gen->need_larbid) {
> - err = of_property_read_u32(dev->of_node, "m
Re: [PATCH v7 21/21] iommu/mediatek: Switch to SPDX license identifier
On 10/06/2019 14:18, Yong Wu wrote: > Switch to SPDX license identifier for MediaTek iommu/smi and their > header files. > > Signed-off-by: Yong Wu > Reviewed-by: Rob Herring > Reviewed-by: Evan Green Reviewed-by: Matthias Brugger > --- > drivers/iommu/mtk_iommu.c | 10 +- > drivers/iommu/mtk_iommu.h | 10 +- > drivers/iommu/mtk_iommu_v1.c | 10 +- > drivers/memory/mtk-smi.c | 10 +- > include/dt-bindings/memory/mt2701-larb-port.h | 10 +- > include/dt-bindings/memory/mt8173-larb-port.h | 10 +- > include/soc/mediatek/smi.h| 10 +- > 7 files changed, 7 insertions(+), 63 deletions(-) > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > index 34f2e40..6fe3369 100644 > --- a/drivers/iommu/mtk_iommu.c > +++ b/drivers/iommu/mtk_iommu.c > @@ -1,15 +1,7 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Copyright (c) 2015-2016 MediaTek Inc. > * Author: Yong Wu > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > */ > #include > #include > diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h > index e8114b2..b24cfd3 100644 > --- a/drivers/iommu/mtk_iommu.h > +++ b/drivers/iommu/mtk_iommu.h > @@ -1,15 +1,7 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > /* > * Copyright (c) 2015-2016 MediaTek Inc. > * Author: Honghui Zhang > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > */ > > #ifndef _MTK_IOMMU_H_ > diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c > index 73308ad..0b0908c 100644 > --- a/drivers/iommu/mtk_iommu_v1.c > +++ b/drivers/iommu/mtk_iommu_v1.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * IOMMU API for MTK architected m4u v1 implementations > * > @@ -5,15 +6,6 @@ > * Author: Honghui Zhang > * > * Based on driver/iommu/mtk_iommu.c > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > */ > #include > #include > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c > index 10e6493..9688341 100644 > --- a/drivers/memory/mtk-smi.c > +++ b/drivers/memory/mtk-smi.c > @@ -1,15 +1,7 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Copyright (c) 2015-2016 MediaTek Inc. > * Author: Yong Wu > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > */ > #include > #include > diff --git a/include/dt-bindings/memory/mt2701-larb-port.h > b/include/dt-bindings/memory/mt2701-larb-port.h > index 6764d74..c511f0f 100644 > --- a/include/dt-bindings/memory/mt2701-larb-port.h > +++ b/include/dt-bindings/memory/mt2701-larb-port.h > @@ -1,15 +1,7 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > /* > * Copyright (c) 2015 MediaTek Inc. > * Author: Honghui Zhang > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software
Re: [PATCH v7 18/21] iommu/mediatek: Fix VLD_PA_RNG register backup when suspend
On 10/06/2019 14:17, Yong Wu wrote:
> The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB
> mode support for mt2712. this patch add it.
>
> Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
> for 4GB mode")
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 2 ++
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 6053b8b..86158d8 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -719,6 +719,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device
> *dev)
> reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
> reg->int_main_control = readl_relaxed(base + REG_MMU_INT_MAIN_CONTROL);
> reg->ivrp_paddr = readl_relaxed(base + REG_MMU_IVRP_PADDR);
> + reg->vld_pa_rng = readl_relaxed(base + REG_MMU_VLD_PA_RNG);
> clk_disable_unprepare(data->bclk);
> return 0;
> }
> @@ -743,6 +744,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
> writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
> writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
> + writel_relaxed(reg->vld_pa_rng, base + REG_MMU_VLD_PA_RNG);
> if (m4u_dom)
> writel(m4u_dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
> base + REG_MMU_PT_BASE_ADDR);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index c0b5c65..753266b 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -32,6 +32,7 @@ struct mtk_iommu_suspend_reg {
> u32 int_control0;
> u32 int_main_control;
> u32 ivrp_paddr;
> + u32 vld_pa_rng;
> };
>
> enum mtk_iommu_plat {
>
Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
On 13/06/2019 10:20, Pi-Hsun Shih wrote:
> (Sorry for the possibly double-posting, my last mail got rejected by
> some mailing lists.)
>
> Hi,
> When I tested this patch series (Based on linux 5.2.0-rc2, and with
> various other patch series about MT8183) with lockdep enabled, and I'm
> seeing the following lockdep warning on boot.
>
> By bisecting the commits, the first commit that introduce this warning
> is this patch. The warning also doesn't appear if
Are you sure about this?
>From the lockdep call graph it looks more like patch
[PATCH v7 15/21] memory: mtk-smi: Invoke pm runtime_callback to enable clocks
has something to do with it.
But not an expert either, sorry.
Regards,
Matthias
> https://lore.kernel.org/patchwork/patch/1086582/ and
> https://lore.kernel.org/patchwork/patch/1086583/ are not applied.
>
> Do anyone have idea on why this is happening, or any suggestion on
> which part I should be digging into to figure this out? Thanks.
>
> [4.664194] ==
> [4.670368] WARNING: possible circular locking dependency detected
> [4.676545] 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20 Tainted: G S
> [4.684539] --
> [4.690714] kworker/4:1/51 is trying to acquire lock:
> [4.695760] (ptrval) (regulator_list_mutex){+.+.},
> at:regulator_lock_dependent+0xdc/0x6c4
> [4.704732]
> [4.704732] but task is already holding lock:
> [4.710556] (ptrval) (>mlock/1){+.+.},
> at:genpd_lock_nested_mtx+0x24/0x30
> [4.718740]
> [4.718740] which lock already depends on the new lock.
> [4.718740]
> [4.726908]
> [4.726908] the existing dependency chain (in reverse order) is:
> [4.734382]
> [4.734382] -> #4 (>mlock/1){+.+.}:
> [4.739963]__mutex_lock_common+0x1a0/0x1fe8
> [4.744836]mutex_lock_nested+0x40/0x50
> [4.749275]genpd_lock_nested_mtx+0x24/0x30
> [4.754063]genpd_add_subdomain+0x150/0x524
> [4.758850]pm_genpd_add_subdomain+0x3c/0x5c
> [4.763723]scpsys_probe+0x520/0xe78
> [4.767902]platform_drv_probe+0xf4/0x134
> [4.772517]really_probe+0x214/0x4dc
> [4.776696]driver_probe_device+0xcc/0x1d4
> [4.781396]__device_attach_driver+0x10c/0x180
> [4.786442]bus_for_each_drv+0x124/0x184
> [4.790968]__device_attach+0x1c0/0x2d8
> [4.795407]device_initial_probe+0x20/0x2c
> [4.800106]bus_probe_device+0x80/0x16c
> [4.804546]deferred_probe_work_func+0x120/0x168
> [4.809767]process_one_work+0x858/0x1208
> [4.814379]worker_thread+0x9ec/0xcb8
> [4.818644]kthread+0x2b8/0x2d0
> [4.822391]ret_from_fork+0x10/0x18
> [4.826480]
> [4.826480] -> #3 (>mlock){+.+.}:
> [4.831880]__mutex_lock_common+0x1a0/0x1fe8
> [4.836752]mutex_lock_nested+0x40/0x50
> [4.841190]genpd_lock_mtx+0x20/0x2c
> [4.845369]genpd_runtime_resume+0x140/0x434
> [4.850241]__rpm_callback+0xb0/0x1e4
> [4.854506]rpm_callback+0x54/0x1a8
> [4.858597]rpm_resume+0xc6c/0x10c4
> [4.862689]__pm_runtime_resume+0xb4/0x124
> [4.867387]device_link_add+0x598/0x8d0
> [4.871829]mtk_smi_larb_probe+0x2b0/0x340
> [4.876528]platform_drv_probe+0xf4/0x134
> [4.881141]really_probe+0x214/0x4dc
> [4.885320]driver_probe_device+0xcc/0x1d4
> [4.890020]__device_attach_driver+0x10c/0x180
> [4.895066]bus_for_each_drv+0x124/0x184
> [4.899591]__device_attach+0x1c0/0x2d8
> [4.904031]device_initial_probe+0x20/0x2c
> [4.908730]bus_probe_device+0x80/0x16c
> [4.913169]deferred_probe_work_func+0x120/0x168
> [4.918387]process_one_work+0x858/0x1208
> [4.923000]worker_thread+0x9ec/0xcb8
> [4.927264]kthread+0x2b8/0x2d0
> [4.931009]ret_from_fork+0x10/0x18
> [4.935098]
> [4.935098] -> #2 (dpm_list_mtx){+.+.}:
> [4.940412]__mutex_lock_common+0x1a0/0x1fe8
> [4.945284]mutex_lock_nested+0x40/0x50
> [4.949722]device_pm_lock+0x1c/0x24
> [4.953900]device_link_add+0x98/0x8d0
> [4.958252]_regulator_get+0x3f0/0x504
> [4.962606]_devm_regulator_get+0x58/0xb8
> [4.967218]devm_regulator_get+0x28/0x34
> [4.971746]pwm_backlight_probe+0x61c/0x1b90
> [4.976617]platform_drv_probe+0xf4/0x134
> [4.981230]really_probe+0x214/0x4dc
> [4.985409]driver_probe_device+0xcc/0x1d4
> [4.990108]device_driver_attach+0xe4/0x104
> [4.994894]__driver_attach+0x134/0x14c
> [4.999333]bus_for_each_dev+0x120/0x180
> [5.003859]driver_attach+0x48/0x54
> [5.007950]
Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
On 10/06/2019 14:17, Yong Wu wrote:
> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
> mmu0 or mmu1 to balance the bandwidth via the smi-common register
> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>
> In mt8183, For better performance, we switch larb1/2/5/7 to enter
> mmu1 while the others still keep enter mmu0.
>
> In mt8173 and mt2712, we don't get the performance issue,
> Keep its default value(0x0), that means all the larbs enter mmu0.
>
> Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
>
> And, the base of smi-common is completely different with smi_ao_base
> of gen1, thus I add new variable for that.
>
> CC: Matthias Brugger
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
> ---
> drivers/memory/mtk-smi.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index 9790801..08cf40d 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -49,6 +49,12 @@
> #define SMI_LARB_NONSEC_CON(id) (0x380 + ((id) * 4))
> #define F_MMU_EN BIT(0)
>
> +/* SMI COMMON */
> +#define SMI_BUS_SEL 0x220
> +#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
> +/* All are MMU0 defaultly. Only specialize mmu1 here. */
> +#define F_MMU1_LARB(larbid) (0x1 << SMI_BUS_LARB_SHIFT(larbid))
> +
> enum mtk_smi_gen {
> MTK_SMI_GEN1,
> MTK_SMI_GEN2
> @@ -57,6 +63,7 @@ enum mtk_smi_gen {
> struct mtk_smi_common_plat {
> enum mtk_smi_gen gen;
> bool has_gals;
> + u32 bus_sel; /* Balance some larbs to enter mmu0 or mmu1 */
> };
>
> struct mtk_smi_larb_gen {
> @@ -72,8 +79,8 @@ struct mtk_smi {
> struct clk *clk_apb, *clk_smi;
> struct clk *clk_gals0, *clk_gals1;
> struct clk *clk_async; /*only needed by mt2701*/
> - void __iomem*smi_ao_base;
> -
> + void __iomem*smi_ao_base; /* only for gen1 */
> + void __iomem*base;/* only for gen2 */
union {} maybe?
> const struct mtk_smi_common_plat *plat;
> };
>
> @@ -410,6 +417,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
> device *dev)
> static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
> .gen = MTK_SMI_GEN2,
> .has_gals = true,
> + .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
> + F_MMU1_LARB(7),
> };
>
> static const struct of_device_id mtk_smi_common_of_ids[] = {
> @@ -482,6 +491,11 @@ static int mtk_smi_common_probe(struct platform_device
> *pdev)
> ret = clk_prepare_enable(common->clk_async);
> if (ret)
> return ret;
> + } else {
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + common->base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(common->base))
> + return PTR_ERR(common->base);
We must be backwards compatible with DT which does not have the base defined.
Regards,
Matthias
> }
> pm_runtime_enable(dev);
> platform_set_drvdata(pdev, common);
> @@ -497,6 +511,7 @@ static int mtk_smi_common_remove(struct platform_device
> *pdev)
> static int __maybe_unused mtk_smi_common_resume(struct device *dev)
> {
> struct mtk_smi *common = dev_get_drvdata(dev);
> + u32 bus_sel = common->plat->bus_sel;
> int ret;
>
> ret = mtk_smi_clk_enable(common);
> @@ -504,6 +519,9 @@ static int __maybe_unused mtk_smi_common_resume(struct
> device *dev)
> dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
> return ret;
> }
> +
> + if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
> + writel(bus_sel, common->base + SMI_BUS_SEL);
> return 0;
> }
>
>
Re: [PATCH v7 15/21] memory: mtk-smi: Invoke pm runtime_callback to enable clocks
On 10/06/2019 14:17, Yong Wu wrote:
> This patch only move the clk_prepare_enable and config_port into the
> runtime suspend/resume callback. It doesn't change the code content
> and sequence.
>
> This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
> (SMI_BUS_SEL need to be restored after smi-common resume every time.)
> Also it gives a chance to get rid of mtk_smi_larb_get/put which could
> be a next topic.
>
> CC: Matthias Brugger
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/memory/mtk-smi.c | 113
> ++-
> 1 file changed, 72 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index a430721..9790801 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -86,17 +86,13 @@ struct mtk_smi_larb { /* larb: local arbiter */
> u32 *mmu;
> };
>
> -static int mtk_smi_enable(const struct mtk_smi *smi)
> +static int mtk_smi_clk_enable(const struct mtk_smi *smi)
> {
> int ret;
>
> - ret = pm_runtime_get_sync(smi->dev);
> - if (ret < 0)
> - return ret;
> -
> ret = clk_prepare_enable(smi->clk_apb);
> if (ret)
> - goto err_put_pm;
> + return ret;
>
> ret = clk_prepare_enable(smi->clk_smi);
> if (ret)
> @@ -118,59 +114,28 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
> clk_disable_unprepare(smi->clk_smi);
> err_disable_apb:
> clk_disable_unprepare(smi->clk_apb);
> -err_put_pm:
> - pm_runtime_put_sync(smi->dev);
> return ret;
> }
>
> -static void mtk_smi_disable(const struct mtk_smi *smi)
> +static void mtk_smi_clk_disable(const struct mtk_smi *smi)
> {
> clk_disable_unprepare(smi->clk_gals1);
> clk_disable_unprepare(smi->clk_gals0);
> clk_disable_unprepare(smi->clk_smi);
> clk_disable_unprepare(smi->clk_apb);
> - pm_runtime_put_sync(smi->dev);
> }
>
> int mtk_smi_larb_get(struct device *larbdev)
> {
> - struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
> - const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
> - struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
> - int ret;
> + int ret = pm_runtime_get_sync(larbdev);
>
> - /* Enable the smi-common's power and clocks */
> - ret = mtk_smi_enable(common);
> - if (ret)
> - return ret;
> -
> - /* Enable the larb's power and clocks */
> - ret = mtk_smi_enable(>smi);
> - if (ret) {
> - mtk_smi_disable(common);
> - return ret;
> - }
> -
> - /* Configure the iommu info for this larb */
> - larb_gen->config_port(larbdev);
> -
> - return 0;
> + return (ret < 0) ? ret : 0;
> }
> EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
>
> void mtk_smi_larb_put(struct device *larbdev)
> {
> - struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
> - struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
> -
> - /*
> - * Don't de-configure the iommu info for this larb since there may be
> - * several modules in this larb.
> - * The iommu info will be reset after power off.
> - */
> -
> - mtk_smi_disable(>smi);
> - mtk_smi_disable(common);
> + pm_runtime_put_sync(larbdev);
> }
> EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
>
> @@ -385,12 +350,52 @@ static int mtk_smi_larb_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static int __maybe_unused mtk_smi_larb_resume(struct device *dev)
> +{
> + struct mtk_smi_larb *larb = dev_get_drvdata(dev);
> + const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
> + int ret;
> +
> + /* Power on smi-common. */
> + ret = pm_runtime_get_sync(larb->smi_common_dev);
> + if (ret < 0) {
> + dev_err(dev, "Failed to pm get for smi-common(%d).\n", ret);
> + return ret;
> + }
> +
> + ret = mtk_smi_clk_enable(>smi);
> + if (ret < 0) {
> + dev_err(dev, "Failed to enable clock(%d).\n", ret);
> + pm_runtime_put_sync(larb->smi_common_dev);
> + return ret;
> + }
> +
> + /* Configure the basic setting for this larb */
> + larb_gen->config_port(dev);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused mtk_smi_larb_suspend(struct device *dev)
> +{
> + struct mtk_smi_larb *larb = dev_get_drv
Re: [PATCH v7 14/21] iommu/mediatek: Add mmu1 support
On 10/06/2019 14:17, Yong Wu wrote:
> Normally the M4U HW connect EMI with smi. the diagram is like below:
> EMI
>|
> M4U
>|
> smi-common
>|
>-
>||| |...
> larb0 larb1 larb2 larb3
>
> Actually there are 2 mmu cells in the M4U HW, like this diagram:
>
> EMI
>-
> | |
>mmu0 mmu1 <- M4U
> | |
>-
>|
> smi-common
>|
>-
>||| |...
> larb0 larb1 larb2 larb3
>
> This patch add support for mmu1. In order to get better performance,
> we could adjust some larbs go to mmu1 while the others still go to
> mmu0. This is controlled by a SMI COMMON register SMI_BUS_SEL(0x220).
>
> mt2712, mt8173 and mt8183 M4U HW all have 2 mmu cells. the default
> value of that register is 0 which means all the larbs go to mmu0
> defaultly.
>
> This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
>
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 46 +-
> 1 file changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 3a14301..ec4ce74 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -72,26 +72,32 @@
> #define F_INT_CLR_BITBIT(12)
>
> #define REG_MMU_INT_MAIN_CONTROL 0x124
> -#define F_INT_TRANSLATION_FAULT BIT(0)
> -#define F_INT_MAIN_MULTI_HIT_FAULT BIT(1)
> -#define F_INT_INVALID_PA_FAULT BIT(2)
> -#define F_INT_ENTRY_REPLACEMENT_FAULTBIT(3)
> -#define F_INT_TLB_MISS_FAULT BIT(4)
> -#define F_INT_MISS_TRANSACTION_FIFO_FAULTBIT(5)
> -#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT BIT(6)
> + /* mmu0 | mmu1 */
> +#define F_INT_TRANSLATION_FAULT (BIT(0) | BIT(7))
> +#define F_INT_MAIN_MULTI_HIT_FAULT (BIT(1) | BIT(8))
> +#define F_INT_INVALID_PA_FAULT (BIT(2) | BIT(9))
> +#define F_INT_ENTRY_REPLACEMENT_FAULT(BIT(3) | BIT(10))
> +#define F_INT_TLB_MISS_FAULT (BIT(4) | BIT(11))
> +#define F_INT_MISS_TRANSACTION_FIFO_FAULT(BIT(5) | BIT(12))
> +#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT (BIT(6) | BIT(13))
>
> #define REG_MMU_CPE_DONE 0x12C
>
> #define REG_MMU_FAULT_ST10x134
> +#define F_REG_MMU0_FAULT_MASKGENMASK(6, 0)
> +#define F_REG_MMU1_FAULT_MASKGENMASK(13, 7)
>
> -#define REG_MMU_FAULT_VA 0x13c
> +#define REG_MMU0_FAULT_VA0x13c
> #define F_MMU_FAULT_VA_WRITE_BIT BIT(1)
> #define F_MMU_FAULT_VA_LAYER_BIT BIT(0)
>
> -#define REG_MMU_INVLD_PA 0x140
> -#define REG_MMU_INT_ID 0x150
> -#define F_MMU0_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
> -#define F_MMU0_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
> +#define REG_MMU0_INVLD_PA0x140
> +#define REG_MMU1_FAULT_VA0x144
> +#define REG_MMU1_INVLD_PA0x148
> +#define REG_MMU0_INT_ID 0x150
> +#define REG_MMU1_INT_ID 0x154
> +#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
>
> @@ -210,13 +216,19 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
>
> /* Read error info from registers */
> int_state = readl_relaxed(data->base + REG_MMU_FAULT_ST1);
> - fault_iova = readl_relaxed(data->base + REG_MMU_FAULT_VA);
> + if (int_state & F_REG_MMU0_FAULT_MASK) {
> + regval = readl_relaxed(data->base + REG_MMU0_INT_ID);
> + fault_iova = readl_relaxed(data->base + REG_MMU0_FAULT_VA);
> + fault_pa = readl_relaxed(data->base + REG_MMU0_INVLD_PA);
> + } else {
> + regval = readl_relaxed(data->base + REG_MMU1_INT_ID);
> + fault_iova = readl_relaxed(data->base + REG_MMU1_FAULT_VA);
> + fault_pa = readl_relaxed(
Re: [PATCH v7 13/21] iommu/mediatek: Add mt8183 IOMMU support
On 10/06/2019 14:17, Yong Wu wrote:
> The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> the ARM Short-descriptor like mt8173, and most of the HW registers
> are the same.
>
> Here list main differences between mt8183 and mt8173/mt2712:
> 1) mt8183 has only one M4U HW like mt8173 while mt2712 has two.
> 2) mt8183 don't have the "bclk" clock, it use the EMI clock instead.
> 3) mt8183 can support the dram over 4GB, but it doesn't call this "4GB
> mode".
> 4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent
> the bit[33:32] in the physical address of the pgtable base, But the
> standard ttbr0[1] means the S bit which is enabled defaultly, Hence,
> we add a mask.
> 5) mt8183 HW has a GALS modules, SMI should enable "has_gals" support.
> 6) mt8183 need reset_axi like mt8173.
> 7) the larb-id in smi-common is remapped. M4U should add its larbid_remap.
>
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 15 ---
> drivers/iommu/mtk_iommu.h | 1 +
> drivers/memory/mtk-smi.c | 20
> 3 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index a535dcd..3a14301 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -36,6 +36,7 @@
> #include "mtk_iommu.h"
>
> #define REG_MMU_PT_BASE_ADDR 0x000
> +#define MMU_PT_ADDR_MASK GENMASK(31, 7)
>
> #define REG_MMU_INVALIDATE 0x020
> #define F_ALL_INVLD 0x2
> @@ -341,7 +342,7 @@ static int mtk_iommu_attach_device(struct iommu_domain
> *domain,
> /* Update the pgtable base address register of the M4U HW */
> if (!data->m4u_dom) {
> data->m4u_dom = dom;
> - writel(dom->cfg.arm_v7s_cfg.ttbr[0],
> + writel(dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
> data->base + REG_MMU_PT_BASE_ADDR);
> }
>
> @@ -715,6 +716,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
> struct mtk_iommu_suspend_reg *reg = >reg;
> + struct mtk_iommu_domain *m4u_dom = data->m4u_dom;
> void __iomem *base = data->base;
> int ret;
>
> @@ -730,8 +732,8 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
> writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
> writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
> - if (data->m4u_dom)
> - writel(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
> + if (m4u_dom)
> + writel(m4u_dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
> base + REG_MMU_PT_BASE_ADDR);
> return 0;
> }
> @@ -756,9 +758,16 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> .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,
> + .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
> +};
> +
> static const struct of_device_id mtk_iommu_of_ids[] = {
> { .compatible = "mediatek,mt2712-m4u", .data = _data},
> { .compatible = "mediatek,mt8173-m4u", .data = _data},
> + { .compatible = "mediatek,mt8183-m4u", .data = _data},
> {}
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index e5c9dde..c0b5c65 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -38,6 +38,7 @@ enum mtk_iommu_plat {
> M4U_MT2701,
> M4U_MT2712,
> M4U_MT8173,
> + M4U_MT8183,
> };
>
> struct mtk_iommu_plat_data {
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index 91634d7..a430721 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -285,6 +285,13 @@ static void mtk_smi_larb_config_port_gen1(struct device
> *dev)
> .larb_direct_to_common_mask = BIT(8) | BIT(9), /* bdpsys */
> };
>
> +static const struct mtk_smi_larb_gen mtk_smi_larb_mt8183 = {
> + .has_gals = true,
> + .config_port= mtk_smi_larb_config_port_gen2_general,
> + .larb_direct_to_common_mask = BIT(2) | BIT(3) | BIT(7),
> + /* IPU0 | I
Re: [PATCH v7 12/21] memory: mtk-smi: Add gals support
On 10/06/2019 14:17, Yong Wu wrote:
> In some SoCs like mt8183, SMI add GALS(Global Async Local Sync) module
> which can help synchronize for the modules in different clock frequency.
> It can be seen as a "asynchronous fifo". This is a example diagram:
>
> M4U
> |
> --
> ||
> gals0-rx gals1-rx
> ||
> ||
> gals0-tx gals1-tx
> ||
>
> SMI Common
>
> |
> +-++-+- ...
> | || |
> | gals-rx gals-rx |
> | || |
> | || |
> | gals-tx gals-tx |
> | || |
> larb1 larb2 larb3 larb4
>
> GALS only help transfer the command/data while it doesn't have the
> configuring register, thus it has the special "smi" clock and doesn't
> have the "apb" clock. From the diagram above, we add "gals0" and
> "gals1" clocks for smi-common and add a "gals" clock for smi-larb.
>
> This patch adds gals clock supporting in the SMI. Note that some larbs
> may still don't have the "gals" clock like larb1 and larb4 above.
>
> This is also a preparing patch for mt8183 which has GALS.
>
> CC: Matthias Brugger
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/memory/mtk-smi.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index 8a2f968..91634d7 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -56,6 +56,7 @@ enum mtk_smi_gen {
>
> struct mtk_smi_common_plat {
> enum mtk_smi_gen gen;
> + bool has_gals;
> };
>
> struct mtk_smi_larb_gen {
> @@ -63,11 +64,13 @@ struct mtk_smi_larb_gen {
> int port_in_larb[MTK_LARB_NR_MAX + 1];
> void (*config_port)(struct device *);
> unsigned int larb_direct_to_common_mask;
> + bool has_gals;
> };
>
> struct mtk_smi {
> struct device *dev;
> struct clk *clk_apb, *clk_smi;
> + struct clk *clk_gals0, *clk_gals1;
> struct clk *clk_async; /*only needed by mt2701*/
> void __iomem*smi_ao_base;
>
> @@ -99,8 +102,20 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
> if (ret)
> goto err_disable_apb;
>
> + ret = clk_prepare_enable(smi->clk_gals0);
> + if (ret)
> + goto err_disable_smi;
> +
> + ret = clk_prepare_enable(smi->clk_gals1);
> + if (ret)
> + goto err_disable_gals0;
> +
> return 0;
>
> +err_disable_gals0:
> + clk_disable_unprepare(smi->clk_gals0);
> +err_disable_smi:
> + clk_disable_unprepare(smi->clk_smi);
> err_disable_apb:
> clk_disable_unprepare(smi->clk_apb);
> err_put_pm:
> @@ -110,6 +125,8 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
>
> static void mtk_smi_disable(const struct mtk_smi *smi)
> {
> + clk_disable_unprepare(smi->clk_gals1);
> + clk_disable_unprepare(smi->clk_gals0);
> clk_disable_unprepare(smi->clk_smi);
> clk_disable_unprepare(smi->clk_apb);
> pm_runtime_put_sync(smi->dev);
> @@ -310,6 +327,15 @@ static int mtk_smi_larb_probe(struct platform_device
> *pdev)
> larb->smi.clk_smi = devm_clk_get(dev, "smi");
> if (IS_ERR(larb->smi.clk_smi))
> return PTR_ERR(larb->smi.clk_smi);
> +
> + if (larb->larb_gen->has_gals) {
> + /* The larbs may still haven't gals even if the SoC support.*/
> + larb->smi.clk_gals0 = devm_clk_get(dev, "gals");
> + if (PTR_ERR(larb->smi.clk_gals0) == -ENOENT)
> + larb->smi.clk_gals0 = NULL;
> + else if (IS_ERR(larb->smi.clk_gals0))
> + return PTR_ERR(larb->smi.clk_gals0);
> + }
> larb->smi.dev = dev;
>
> if (larb->larb_gen->need_larbid) {
> @@ -402,6 +428,16 @@ static int mtk_smi_common_probe(struct platform_device
> *pdev)
> if (IS_ERR(common->clk_smi))
> return PTR_ERR(common->clk_smi);
>
> + if (common->plat->has_gals) {
> + common->clk_gals0 = devm_clk_get(dev, "gals0");
> + if (IS_ERR(common->clk_gals0))
> + return PTR_ERR(common->clk_gals0);
> +
> + common->clk_gals1 = devm_clk_get(dev, "gals1");
> + if (IS_ERR(common->clk_gals1))
> + return PTR_ERR(common->clk_gals1);
> + }
> +
> /*
>* for mtk smi gen 1, we need to get the ao(always on) base to config
>* m4u port, and we need to enable the aync clock for transform the smi
>
Re: [PATCH v7 11/21] iommu/mediatek: Move vld_pa_rng into plat_data
On 10/06/2019 14:17, Yong Wu wrote:
> Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address
> range) register while mt2712 have. Move it into the plat_data.
>
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 3 ++-
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 8ac7034..a535dcd 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -547,7 +547,7 @@ 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->m4u_plat != M4U_MT8173) {
> + if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
> /*
>* If 4GB mode is enabled, the validate PA range is from
>* 0x1__ to 0x1__. here record bit[32:30].
> @@ -744,6 +744,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> .m4u_plat = M4U_MT2712,
> .has_4gb_mode = true,
> .has_bclk = true,
> + .has_vld_pa_rng = true,
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 55d73c1..e5c9dde 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -47,6 +47,7 @@ struct mtk_iommu_plat_data {
> /* HW will use the EMI clock if there isn't the "bclk". */
> boolhas_bclk;
> boolreset_axi;
> + boolhas_vld_pa_rng;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 10/21] iommu/mediatek: Move reset_axi into plat_data
On 10/06/2019 14:17, Yong Wu wrote:
> In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while it is
> REG_MMU_CTRL in the other SoCs, and the bits meaning is completely
> different with the REG_MMU_STANDARD_AXI_MODE.
>
> This patch moves this property to plat_data, it's also a preparing
> patch for mt8183.
>
> Signed-off-by: Yong Wu
> Reviewed-by: Nicolas Boichat
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 4 ++--
> drivers/iommu/mtk_iommu.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index d38dfa2..8ac7034 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -557,8 +557,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> - /* It's MISC control register whose default value is ok except mt8173.*/
> - if (data->plat_data->m4u_plat == M4U_MT8173)
> + if (data->plat_data->reset_axi)
> writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
>
> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> @@ -752,6 +751,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> .m4u_plat = M4U_MT8173,
> .has_4gb_mode = true,
> .has_bclk = true,
> + .reset_axi= true,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 61fd5d6..55d73c1 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -46,7 +46,7 @@ struct mtk_iommu_plat_data {
>
> /* HW will use the EMI clock if there isn't the "bclk". */
> boolhas_bclk;
> -
> + boolreset_axi;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 09/21] iommu/mediatek: Refine protect memory definition
On 10/06/2019 14:17, Yong Wu wrote: > The protect memory setting is a little different in the different SoCs. > In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault > protect) shift bit is normally 4 while it shift 5 bits only in the > mt8173. This patch delete the complex MACRO and use a common if-else > instead. > > Signed-off-by: Yong Wu > Reviewed-by: Evan Green Reviewed-by: Matthias Brugger > --- > drivers/iommu/mtk_iommu.c | 13 ++--- > 1 file changed, 6 insertions(+), 7 deletions(-) > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > index ad838b9..d38dfa2 100644 > --- a/drivers/iommu/mtk_iommu.c > +++ b/drivers/iommu/mtk_iommu.c > @@ -52,12 +52,9 @@ > #define REG_MMU_DCM_DIS 0x050 > > #define REG_MMU_CTRL_REG 0x110 > +#define F_MMU_TF_PROT_TO_PROGRAM_ADDR(2 << 4) > #define F_MMU_PREFETCH_RT_REPLACE_MODBIT(4) > -#define F_MMU_TF_PROTECT_SEL_SHIFT(data) \ > - ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5) > -/* It's named by F_MMU_TF_PROT_SEL in mt2712. */ > -#define F_MMU_TF_PROTECT_SEL(prot, data) \ > - (((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data)) > +#define F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173 (2 << 5) > > #define REG_MMU_IVRP_PADDR 0x114 > > @@ -519,9 +516,11 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data > *data) > return ret; > } > > - regval = F_MMU_TF_PROTECT_SEL(2, data); > if (data->plat_data->m4u_plat == M4U_MT8173) > - regval |= F_MMU_PREFETCH_RT_REPLACE_MOD; > + regval = F_MMU_PREFETCH_RT_REPLACE_MOD | > + F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173; > + else > + regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR; > writel_relaxed(regval, data->base + REG_MMU_CTRL_REG); > > regval = F_L2_MULIT_HIT_EN | >
Re: [PATCH v7 08/21] iommu/mediatek: Add larb-id remapped support
On 10/06/2019 14:17, Yong Wu wrote:
> The larb-id may be remapped in the smi-common, this means the
> larb-id reported in the mtk_iommu_isr isn't the real larb-id,
>
> Take mt8183 as a example:
>M4U
> |
> -
> | SMI common |
> -0-7-5-6-1-2--3-4- <- Id remapped
> | | | | | | | |
> larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
> disp vdec img cam venc imgcam
> As above, larb0 connects with the id 0 in smi-common.
> larb1 connects with the id 7 in smi-common.
> ...
> If the larb-id reported in the isr is 7, actually it's larb1(vdec).
> In order to output the right larb-id in the isr, we add a larb-id
> remapping relationship in this patch.
>
> If there is no this larb-id remapping in some SoCs, use the linear
> mapping array instead.
>
> This also is a preparing patch for mt8183.
>
> Signed-off-by: Yong Wu
> Reviewed-by: Nicolas Boichat
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 4
> drivers/iommu/mtk_iommu.h | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 264dda4..ad838b9 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -220,6 +220,8 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
> fault_port = F_MMU0_INT_ID_PORT_ID(regval);
>
> + fault_larb = data->plat_data->larbid_remap[fault_larb];
> +
> if (report_iommu_fault(>domain, data->dev, fault_iova,
> write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
> dev_err_ratelimited(
> @@ -744,12 +746,14 @@ static int __maybe_unused mtk_iommu_resume(struct
> device *dev)
> .m4u_plat = M4U_MT2712,
> .has_4gb_mode = true,
> .has_bclk = true,
> + .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,
> + .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> 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 63e235e..61fd5d6 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -46,6 +46,8 @@ struct mtk_iommu_plat_data {
>
> /* HW will use the EMI clock if there isn't the "bclk". */
> boolhas_bclk;
> +
> + unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
> struct mtk_iommu_domain;
>
Re: [PATCH v7 07/21] iommu/mediatek: Add bclk can be supported optionally
On 10/06/2019 14:17, Yong Wu wrote:
> In some SoCs, M4U doesn't have its "bclk", it will use the EMI
> clock instead which has always been enabled when entering kernel.
>
> Currently mt2712 and mt8173 have this bclk while mt8183 doesn't.
>
> This also is a preparing patch for mt8183.
>
> Signed-off-by: Yong Wu
> Reviewed-by: Evan Green
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 10 +++---
> drivers/iommu/mtk_iommu.h | 3 +++
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index aff5004..264dda4 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -611,9 +611,11 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (data->irq < 0)
> return data->irq;
>
> - data->bclk = devm_clk_get(dev, "bclk");
> - if (IS_ERR(data->bclk))
> - return PTR_ERR(data->bclk);
> + if (data->plat_data->has_bclk) {
> + data->bclk = devm_clk_get(dev, "bclk");
> + if (IS_ERR(data->bclk))
> + return PTR_ERR(data->bclk);
> + }
>
> larb_nr = of_count_phandle_with_args(dev->of_node,
>"mediatek,larbs", NULL);
> @@ -741,11 +743,13 @@ static int __maybe_unused mtk_iommu_resume(struct
> device *dev)
> static const struct mtk_iommu_plat_data mt2712_data = {
> .m4u_plat = M4U_MT2712,
> .has_4gb_mode = true,
> + .has_bclk = true,
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> .has_4gb_mode = true,
> + .has_bclk = true,
> };
>
> 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 d7a001a..63e235e 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -43,6 +43,9 @@ enum mtk_iommu_plat {
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> boolhas_4gb_mode;
> +
> + /* HW will use the EMI clock if there isn't the "bclk". */
> + boolhas_bclk;
> };
>
> struct mtk_iommu_domain;
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/2] iommu/arm-smmu-v3: make sure the kdump kernel can work well when smmu is enabled
On 16/04/2019 11:14, Will Deacon wrote:
> On Mon, Apr 08, 2019 at 10:31:47AM +0800, Leizhen (ThunderTown) wrote:
>> On 2019/4/4 23:30, Will Deacon wrote:
>>> On Mon, Mar 18, 2019 at 09:12:41PM +0800, Zhen Lei wrote:
>>>> v1 --> v2:
>>>> 1. Drop part2. Now, we only use the SMMUv3 hardware feature
>>>> STE.config=0b000
>>>> (Report abort to device, no event recorded) to suppress the event messages
>>>> caused by the unexpected devices.
>>>> 2. rewrite the patch description.
>>>
>>> This issue came up a while back:
>>>
>>> https://lore.kernel.org/linux-pci/20180302103032.gb19...@arm.com/
>>>
>>> and I'd still prefer to solve it using the disable_bypass logic which we
>>> already have. Something along the lines of the diff below?
>>
>> Yes, my patches also use disable_bypass=1(set ste.config=0b000). If
>> SMMU_IDR0.ST_LEVEL=0(Linear Stream table supported), then all STE entries
>> are allocated and initialized(set ste.config=0b000). But if
>> SMMU_IDR0.ST_LEVEL=1
>> (2-level Stream Table), we only allocated and initialized the first level
>> tables,
>> but leave level 2 tables dynamic allocated. That means,
>> C_BAD_STREAMID(eventid=0x2)
>> will be reported, if an unexpeted device access memory without reinitialized
>> in
>> kdump kernel.
>
> So is your problem just that the C_BAD_STREAMID events are noisy? If so,
> perhaps we should be disabling fault reporting entirely in the kdump kernel.
>
> How about the update diff below? I'm keen to have this as simple as
> possible, so we don't end up introducing rarely tested, complex code on
> the crash path.
>
> Will
>
> --->8
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index d3880010c6cf..d8b73da6447d 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2454,13 +2454,9 @@ static int arm_smmu_device_reset(struct
> arm_smmu_device *smmu, bool bypass)
> /* Clear CR0 and sync (disables SMMU and queue processing) */
> reg = readl_relaxed(smmu->base + ARM_SMMU_CR0);
> if (reg & CR0_SMMUEN) {
> - if (is_kdump_kernel()) {
> - arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0);
> - arm_smmu_device_disable(smmu);
> - return -EBUSY;
> - }
> -
> dev_warn(smmu->dev, "SMMU currently enabled! Resetting...\n");
> + WARN_ON(is_kdump_kernel() && !disable_bypass);
> + arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0);
> }
>
> ret = arm_smmu_device_disable(smmu);
> @@ -2553,6 +2549,8 @@ static int arm_smmu_device_reset(struct arm_smmu_device
> *smmu, bool bypass)
> return ret;
> }
>
> + if (is_kdump_kernel())
> + enables &= ~(CR0_EVTQEN | CR0_PRIQEN);
>
> /* Enable the SMMU interface, or ensure bypass */
> if (!bypass || disable_bypass) {
>
Same here I tested the patch and it works for me.
Feel free to add:
Tested-by: Matthias Brugger
Regards,
Matthias
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/mediatek: fix leaked of_node references
On 17/04/2019 04:41, Wen Yang wrote:
> The call to of_parse_phandle returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
>
> 581 static int mtk_iommu_probe(struct platform_device *pdev)
> 582 {
> ...
> 626 for (i = 0; i < larb_nr; i++) {
> 627 struct device_node *larbnode;
> ...
> 631 larbnode = of_parse_phandle(...);
> 632 if (!larbnode)
> 633 return -EINVAL;
> 634
> 635 if (!of_device_is_available(larbnode))
> 636 continue; ---> leaked here
> 637
> ...
> 643 if (!plarbdev)
> 644 return -EPROBE_DEFER; ---> leaked here
> ...
> 647 component_match_add_release(dev, , release_of,
> 648 compare_of, larbnode);
>---> release_of will call of_node_put
> 649 }
> ...
> 650
>
> Detected by coccinelle with the following warnings:
> ./drivers/iommu/mtk_iommu.c:644:3-9: ERROR: missing of_node_put; acquired a
> node pointer with refcount incremented on line 631, but without a
> corresponding object release within this function.
>
> Signed-off-by: Wen Yang
> Cc: Joerg Roedel
> Cc: Matthias Brugger
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
Reviewed-by: Matthias Brugger
> ---
> drivers/iommu/mtk_iommu.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index de3e022..b66d11b 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -632,16 +632,20 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (!larbnode)
> return -EINVAL;
>
> - if (!of_device_is_available(larbnode))
> + if (!of_device_is_available(larbnode)) {
> + of_node_put(larbnode);
> continue;
> + }
>
> ret = of_property_read_u32(larbnode, "mediatek,larb-id", );
> if (ret)/* The id is consecutive if there is no this property */
> id = i;
>
> plarbdev = of_find_device_by_node(larbnode);
> - if (!plarbdev)
> + if (!plarbdev) {
> + of_node_put(larbnode);
> return -EPROBE_DEFER;
> + }
> data->smi_imu.larb_imu[id].dev = >dev;
>
> component_match_add_release(dev, , release_of,
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 02/13] driver core: Remove the link if there is no driver with AUTO flag
On 05/03/2019 20:03, Evan Green wrote:
> On Wed, Feb 27, 2019 at 6:33 AM Yong Wu wrote:
>>
>> On Mon, 2019-02-25 at 15:53 -0800, Evan Green wrote:
>>> On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
DL_FLAG_AUTOREMOVE_CONSUMER/SUPPLIER means "Remove the link
automatically on consumer/supplier driver unbind", that means we should
remove whole the device_link when there is no this driver no matter what
the ref_count of the link is.
CC: Greg Kroah-Hartman
Signed-off-by: Yong Wu
---
The ref_count of our device_link normally is over 1. When the consumer
device driver is removed, whole the device_link should be removed.
Thus, I add this patch.
---
>>>
>>> I will admit to reading about device links for the first time while
>>> reviewing this patch, but I don't really get this. Why use a kref at
>>> all if we're just going to ignore its value? For instance, I see that
>>> if you call device_link_add() with the same supplier and consumer, it
>>> uses the kref to return the same link. That machinery is broken with
>>> your change. Although I don't see any uses of it, you might also
>>> expect a supplier or consumer could do a kref_get() on the link it got
>>> back from device_link_add(), and have a reasonable expectation that
>>> the link wouldn't be freed out from under it. This would also be
>>> broken.
>>>
>>> Can you explain why your device_links normally have a reference count
1,
>>
>> I use device link between the smi-larb device and the iommu-consumer
>> device. Take a example, smi-larb1 have 4 VDEC ports. From 4/13 in this
>> patchset, we use device_link to link the VDEC device and the smi-larb1
>> device in the function(mtk_iommu_config). since there are 4 ports, it
>> will call device_link_add 4 times.
>>
>>>
>>> and why those additional references can't be cleaned up in an
>>> orderly fashion?
>>
>> If the iommu-consume device(like VDEC above) is removed, It should enter
>> device_links_driver_cleanup which only ref_put one time. I guess whole
>> the link should be removed at that time.
>
> It seems like Robin had some suggestions about using
> mtk_iommu_add_device() rather than the attach_dev() to set the links
> up, and then track them for removal in the corresponding
> remove_device() callback. Then you wouldn't need this change, right?
>
FYI, Evan the patch is queued for v5.1-rc1 as
0fe6f7874d46 ("driver core: Remove the link if there is no driver with AUTO
flag")
So if you think there is something wrong with it, then please provide a fix or
raise awareness :)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 10/18] iommu/mediatek: Add mt8183 IOMMU support
On 08/12/2018 09:39, Yong Wu wrote:
> The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> the ARM Short-descriptor like mt8173, and most of the HW registers
> are the same.
>
> Here list main differences between mt8183 and mt8173/mt2712:
> 1) mt8183 has only one M4U HW like mt8173 while mt2712 has two.
> 2) mt8183 don't have the "bclk" clock, it use the EMI clock instead.
> 3) mt8183 can support the dram over 4GB, but it doesn't call this "4GB
> mode".
> 4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent
> the bit[33:32] in the physical address of the pgtable base, But the
> standard ttbr0[1] means the S bit which is enabled defaultly, Hence,
> we add a mask.
> 5) mt8183 HW has a GALS modules, SMI should enable "has_gals" support.
> 6) the larb-id in smi-common is remapped. M4U should enable
> larbid_remapped support.
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 31 ++-
> drivers/iommu/mtk_iommu.h | 1 +
> drivers/memory/mtk-smi.c | 19 +++
> 3 files changed, 42 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 8ab3b69..d91a554 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -36,6 +36,7 @@
> #include "mtk_iommu.h"
>
> #define REG_MMU_PT_BASE_ADDR 0x000
> +#define MMU_PT_ADDR_MASK GENMASK(31, 7)
>
> #define REG_MMU_INVALIDATE 0x020
> #define F_ALL_INVLD 0x2
> @@ -54,7 +55,7 @@
> #define REG_MMU_CTRL_REG 0x110
> #define F_MMU_PREFETCH_RT_REPLACE_MODBIT(4)
> #define F_MMU_TF_PROTECT_SEL_SHIFT(data) \
> - ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5)
> + ((data)->plat_data->m4u_plat == M4U_MT8173 ? 5 : 4)
> /* It's named by F_MMU_TF_PROT_SEL in mt2712. */
> #define F_MMU_TF_PROTECT_SEL(prot, data) \
> (((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
> @@ -347,7 +348,7 @@ static int mtk_iommu_attach_device(struct iommu_domain
> *domain,
> /* Update the pgtable base address register of the M4U HW */
> if (!data->m4u_dom) {
> data->m4u_dom = dom;
> - writel(dom->cfg.arm_v7s_cfg.ttbr[0],
> + writel(dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
> data->base + REG_MMU_PT_BASE_ADDR);
> }
>
> @@ -510,6 +511,7 @@ static int mtk_iommu_of_xlate(struct device *dev, struct
> of_phandle_args *args)
>
> static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> {
> + enum mtk_iommu_plat m4u_plat = data->plat_data->m4u_plat;
> u32 regval;
> int ret;
>
> @@ -520,7 +522,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> }
>
> regval = F_MMU_TF_PROTECT_SEL(2, data);
> - if (data->plat_data->m4u_plat == M4U_MT8173)
> + if (m4u_plat == M4U_MT8173)
> regval |= F_MMU_PREFETCH_RT_REPLACE_MOD;
> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>
> @@ -541,14 +543,14 @@ static int mtk_iommu_hw_init(const struct
> mtk_iommu_data *data)
> F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
> writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
>
> - if (data->plat_data->m4u_plat == M4U_MT8173)
> + if (m4u_plat == M4U_MT8173)
> regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
> else
> regval = lower_32_bits(data->protect_base) |
>upper_32_bits(data->protect_base);
> writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
>
> - if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
> + if (data->enable_4GB && m4u_plat == M4U_MT2712) {
> /*
>* If 4GB mode is enabled, the validate PA range is from
>* 0x1__ to 0x1__. here record bit[32:30].
> @@ -558,8 +560,11 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> - /* It's MISC control register whose default value is ok except mt8173.*/
> - if (data->plat_data->m4u_plat == M4U_MT8173)
> + /*
> + * It's MISC control register whose default value is ok
> + * except mt8173 and mt8183.
> + */
> + if (m4u_plat == M4U_MT8173 || m4u_plat == M4U_MT8183)
> writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
>
> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> @@ -713,6 +718,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
> struct mtk_iommu_suspend_reg *reg = >reg;
> + struct mtk_iommu_domain *m4u_dom = data->m4u_dom;
> void __iomem *base = data->base;
> int ret;
>
> @@ -728,8 +734,8 @@ static int __maybe_unused
Re: [PATCH v4 04/18] memory: mtk-smi: Use a struct for the platform data for smi-common
On 08/12/2018 09:39, Yong Wu wrote:
> Use a struct as the platform special data instead of the enumeration.
>
> Also there is a minor change that moving the position of
> "enum mtk_smi_gen" definition, this is because we expect define
> "struct mtk_smi_common_plat" before it is referred.
>
> This is a preparing patch for mt8183.
>
> Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
> ---
> drivers/memory/mtk-smi.c | 35 ---
> 1 file changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index 3b9ad0e..a5ddd42 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -49,6 +49,15 @@
> #define SMI_LARB_NONSEC_CON(id) (0x380 + ((id) * 4))
> #define F_MMU_EN BIT(0)
>
> +enum mtk_smi_gen {
> + MTK_SMI_GEN1,
> + MTK_SMI_GEN2
> +};
> +
> +struct mtk_smi_common_plat {
> + enum mtk_smi_gen gen;
> +};
> +
> struct mtk_smi_larb_gen {
> bool need_larbid;
> int port_in_larb[MTK_LARB_NR_MAX + 1];
> @@ -61,6 +70,8 @@ struct mtk_smi {
> struct clk *clk_apb, *clk_smi;
> struct clk *clk_async; /*only needed by mt2701*/
> void __iomem*smi_ao_base;
> +
> + const struct mtk_smi_common_plat *plat;
> };
>
> struct mtk_smi_larb { /* larb: local arbiter */
> @@ -72,11 +83,6 @@ struct mtk_smi_larb { /* larb: local arbiter */
> u32 *mmu;
> };
>
> -enum mtk_smi_gen {
> - MTK_SMI_GEN1,
> - MTK_SMI_GEN2
> -};
> -
> static int mtk_smi_enable(const struct mtk_smi *smi)
> {
> int ret;
> @@ -351,18 +357,26 @@ static int mtk_smi_larb_remove(struct platform_device
> *pdev)
> }
> };
>
> +static const struct mtk_smi_common_plat mtk_smi_common_gen1 = {
> + .gen = MTK_SMI_GEN1,
> +};
> +
> +static const struct mtk_smi_common_plat mtk_smi_common_gen2 = {
> + .gen = MTK_SMI_GEN2,
> +};
> +
> static const struct of_device_id mtk_smi_common_of_ids[] = {
> {
> .compatible = "mediatek,mt8173-smi-common",
> - .data = (void *)MTK_SMI_GEN2
> + .data = _smi_common_gen2,
> },
> {
> .compatible = "mediatek,mt2701-smi-common",
> - .data = (void *)MTK_SMI_GEN1
> + .data = _smi_common_gen1,
> },
> {
> .compatible = "mediatek,mt2712-smi-common",
> - .data = (void *)MTK_SMI_GEN2
> + .data = _smi_common_gen2,
> },
> {}
> };
> @@ -372,13 +386,13 @@ static int mtk_smi_common_probe(struct platform_device
> *pdev)
> struct device *dev = >dev;
> struct mtk_smi *common;
> struct resource *res;
> - enum mtk_smi_gen smi_gen;
> int ret;
>
> common = devm_kzalloc(dev, sizeof(*common), GFP_KERNEL);
> if (!common)
> return -ENOMEM;
> common->dev = dev;
> + common->plat = of_device_get_match_data(dev);
>
> common->clk_apb = devm_clk_get(dev, "apb");
> if (IS_ERR(common->clk_apb))
> @@ -394,8 +408,7 @@ static int mtk_smi_common_probe(struct platform_device
> *pdev)
>* clock into emi clock domain, but for mtk smi gen2, there's no smi ao
>* base.
>*/
> - smi_gen = (enum mtk_smi_gen)of_device_get_match_data(dev);
> - if (smi_gen == MTK_SMI_GEN1) {
> + if (common->plat->gen == MTK_SMI_GEN1) {
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> common->smi_ao_base = devm_ioremap_resource(dev, res);
> if (IS_ERR(common->smi_ao_base))
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 03/18] memory: mtk-smi: Use a general config_port interface
On 08/12/2018 09:39, Yong Wu wrote:
> The config_port of mt2712 and mt8183 are the same. Use a general
> config_port interface instead.
>
> In addition, in mt2712, larb8 and larb9 are the bdpsys larbs which
> are not the normal larb, their register space are different from the
> normal one. thus, we can not call the general config_port. In mt8183,
> IPU0/1 and CCU connect with smi-common directly, they also are not
> the normal larb. Hence, we add a "larb_special_mask" for these special
> larbs.
>
> This is also a preparing patch for adding mt8183 SMI support.
>
> Signed-off-by: Yong Wu
> ---
> drivers/memory/mtk-smi.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index 8f2d152..3b9ad0e 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -53,6 +53,7 @@ struct mtk_smi_larb_gen {
> bool need_larbid;
> int port_in_larb[MTK_LARB_NR_MAX + 1];
> void (*config_port)(struct device *);
> + unsigned int larb_special_mask; /* The special larbs mask. */
I'm not really happy with the name larb_special_mask but I can't think of
anything else. The comment is not needed as it just rewords the name of the
variable.
Other then that (or even without changing anything):
Reviewed-by: Matthias Brugger
> };
>
> struct mtk_smi {
> @@ -176,17 +177,13 @@ void mtk_smi_larb_put(struct device *larbdev)
> return -ENODEV;
> }
>
> -static void mtk_smi_larb_config_port_mt2712(struct device *dev)
> +static void mtk_smi_larb_config_port_gen2_general(struct device *dev)
> {
> struct mtk_smi_larb *larb = dev_get_drvdata(dev);
> u32 reg;
> int i;
>
> - /*
> - * larb 8/9 is the bdpsys larb, the iommu_en is enabled defaultly.
> - * Don't need to set it again.
> - */
> - if (larb->larbid == 8 || larb->larbid == 9)
> + if (BIT(larb->larbid) & larb->larb_gen->larb_special_mask)
> return;
>
> for_each_set_bit(i, (unsigned long *)larb->mmu, 32) {
> @@ -261,7 +258,8 @@ static void mtk_smi_larb_config_port_gen1(struct device
> *dev)
>
> static const struct mtk_smi_larb_gen mtk_smi_larb_mt2712 = {
> .need_larbid = true,
> - .config_port = mtk_smi_larb_config_port_mt2712,
> + .config_port = mtk_smi_larb_config_port_gen2_general,
> + .larb_special_mask = BIT(8) | BIT(9), /* bdpsys */
> };
>
> static const struct of_device_id mtk_smi_larb_of_ids[] = {
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 02/18] iommu/mediatek: Use a struct as the platform data
On 08/12/2018 09:39, Yong Wu wrote:
> Use a struct as the platform special data instead of the enumeration.
> This is a prepare patch for adding mt8183 iommu support.
>
> Signed-off-by: Yong Wu
> ---
Reviewed-by: Matthias Brugger
> drivers/iommu/mtk_iommu.c | 24
> drivers/iommu/mtk_iommu.h | 6 +-
> 2 files changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 44bd5b9..9a2225b 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -54,7 +54,7 @@
> #define REG_MMU_CTRL_REG 0x110
> #define F_MMU_PREFETCH_RT_REPLACE_MODBIT(4)
> #define F_MMU_TF_PROTECT_SEL_SHIFT(data) \
> - ((data)->m4u_plat == M4U_MT2712 ? 4 : 5)
> + ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5)
> /* It's named by F_MMU_TF_PROT_SEL in mt2712. */
> #define F_MMU_TF_PROTECT_SEL(prot, data) \
> (((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
> @@ -517,7 +517,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> }
>
> regval = F_MMU_TF_PROTECT_SEL(2, data);
> - if (data->m4u_plat == M4U_MT8173)
> + if (data->plat_data->m4u_plat == M4U_MT8173)
> regval |= F_MMU_PREFETCH_RT_REPLACE_MOD;
> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>
> @@ -538,14 +538,14 @@ static int mtk_iommu_hw_init(const struct
> mtk_iommu_data *data)
> F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
> writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
>
> - if (data->m4u_plat == M4U_MT8173)
> + if (data->plat_data->m4u_plat == M4U_MT8173)
> regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
> else
> regval = lower_32_bits(data->protect_base) |
>upper_32_bits(data->protect_base);
> writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
>
> - if (data->enable_4GB && data->m4u_plat != M4U_MT8173) {
> + if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
> /*
>* If 4GB mode is enabled, the validate PA range is from
>* 0x1__ to 0x1__. here record bit[32:30].
> @@ -556,7 +556,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> /* It's MISC control register whose default value is ok except mt8173.*/
> - if (data->m4u_plat == M4U_MT8173)
> + if (data->plat_data->m4u_plat == M4U_MT8173)
> writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
>
> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> @@ -589,7 +589,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (!data)
> return -ENOMEM;
> data->dev = dev;
> - data->m4u_plat = (enum mtk_iommu_plat)of_device_get_match_data(dev);
> + data->plat_data = of_device_get_match_data(dev);
>
> /* Protect memory. HW will access here while translation fault.*/
> protect = devm_kzalloc(dev, MTK_PROTECT_PA_ALIGN * 2, GFP_KERNEL);
> @@ -733,9 +733,17 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_iommu_suspend, mtk_iommu_resume)
> };
>
> +static const struct mtk_iommu_plat_data mt2712_data = {
> + .m4u_plat = M4U_MT2712,
> +};
> +
> +static const struct mtk_iommu_plat_data mt8173_data = {
> + .m4u_plat = M4U_MT8173,
> +};
> +
> static const struct of_device_id mtk_iommu_of_ids[] = {
> - { .compatible = "mediatek,mt2712-m4u", .data = (void *)M4U_MT2712},
> - { .compatible = "mediatek,mt8173-m4u", .data = (void *)M4U_MT8173},
> + { .compatible = "mediatek,mt2712-m4u", .data = _data},
> + { .compatible = "mediatek,mt8173-m4u", .data = _data},
> {}
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 778498b..333a0ef 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -41,6 +41,10 @@ enum mtk_iommu_plat {
> M4U_MT8173,
> };
>
> +struct mtk_iommu_plat_data {
> + enum mtk_iommu_plat m4u_plat;
> +};
> +
> struct mtk_iommu_domain;
>
> struct mtk_iommu_data {
> @@ -57,7 +61,7 @@ struct mtk_iommu_data {
> booltlb_flush_active;
>
> struct iommu_device iommu;
> - enum mtk_iommu_plat m4u_plat;
> + const struct mtk_iommu_plat_data *plat_data;
>
> struct list_headlist;
> };
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 06/15] iommu/mediatek: Add mt8183 IOMMU support
On 17/11/2018 03:35, Yong Wu wrote:
> The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> the ARM Short-descriptor like mt8173, and most of the HW registers
> are the same.
>
> Here list main changes in mt8183:
> 1) mt8183 has only one M4U HW like mt8173.
That's a change?
> 2) mt8183 don't have its "bclk" clock, the M4U use the EMI clock
> which has already been enabled before kernel.
> 3) mt8183 can support the dram over 4GB, but it don't call this "4GB
> mode".
> 4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent
> the bit[33:32] in the physical address of the pgtable base, But the
> standard ttbr0[1] means the S bit which is enabled defaultly, Hence,
> we add a mask.
> 5) mt8183 HW has a GALS modules, the SMI should add "gals" clock
> support.
> 6) the larb-id in smi-common has been remapped. This means the
> larb-id reported in the mtk_iommu_isr is not the real larb-id, here
> is the remapping relationship of mt8183:
This whole list is an indicator that you will need several enhancements to the
existing code before you can add mt8183 support.
Please do so in independent patches (e.g. gals modules, remap logic)
Regarding making bclk optional, I think it would be better to set it to NULL for
mt8183 otherwise the driver will work with a broken device tree on systems that
actually need the bclk. Same holds for gals0 and gals1.
>M4U
> |
> -
> | SMI common |
> -0-7-5-6-1-2--3-4- <- Id remapped
> | | | | | | | |
> larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
> disp vdec img cam venc imgcam
> As above, larb0 connects with the id 0 in smi-common.
> larb1 connects with the id 7 in smi-common.
> ...
> Take a example, if the larb-id reported in the mtk_iommu_isr is 7,
> actually it is larb1(vdec).
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 38 --
> drivers/iommu/mtk_iommu.h | 5 +
> drivers/memory/mtk-smi.c | 47
> +++
> 3 files changed, 80 insertions(+), 10 deletions(-)
>
[...]
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index a243047..e5fd8ee 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -39,11 +39,16 @@ enum mtk_iommu_plat {
> M4U_MT2701,
> M4U_MT2712,
> M4U_MT8173,
> + M4U_MT8183,
> };
>
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> bool has_4gb_mode;
> +
> + /* The larb-id may be remapped in the smi-common. */
> + bool larbid_remap_enable;
> + unsigned int larbid_remapped[MTK_LARB_NR_MAX];
Please add new features to the driver as single patches. Don't add this kind of
things in the patch where you enable a new SoC.
> };
>
> struct mtk_iommu_domain;
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index e37e54b..979153b 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -59,6 +59,7 @@ struct mtk_smi_larb_gen {
> struct mtk_smi {
> struct device *dev;
> struct clk *clk_apb, *clk_smi;
> + struct clk *clk_gals0, *clk_gals1;
> struct clk *clk_async; /*only needed by mt2701*/
> void __iomem*smi_ao_base;
> };
> @@ -93,8 +94,20 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
> if (ret)
> goto err_disable_apb;
>
> + ret = clk_prepare_enable(smi->clk_gals0);
> + if (ret)
> + goto err_disable_smi;
> +
> + ret = clk_prepare_enable(smi->clk_gals1);
> + if (ret)
> + goto err_disable_gals0;
> +>return 0;
>
> +err_disable_gals0:
> + clk_disable_unprepare(smi->clk_gals0);
> +err_disable_smi:
> + clk_disable_unprepare(smi->clk_smi);
> err_disable_apb:
> clk_disable_unprepare(smi->clk_apb);
> err_put_pm:
> @@ -104,6 +117,8 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
>
> static void mtk_smi_disable(const struct mtk_smi *smi)
> {
> + clk_disable_unprepare(smi->clk_gals1);
> + clk_disable_unprepare(smi->clk_gals0);
> clk_disable_unprepare(smi->clk_smi);
> clk_disable_unprepare(smi->clk_apb);
> pm_runtime_put_sync(smi->dev);
> @@ -262,6 +277,12 @@ static void mtk_smi_larb_config_port_gen1(struct device
> *dev)
> .larb_special_mask = BIT(8) | BIT(9), /* bdpsys */
> };
>
> +static const struct mtk_smi_larb_gen mtk_smi_larb_mt8183 = {
> + .need_larbid = true,
> + .config_port = mtk_smi_larb_config_port_gen2_general,
> + .larb_special_mask = BIT(2) | BIT(3) | BIT(7), /* IPU0 | IPU1 | CCU */
> +};
> +
> static const struct of_device_id mtk_smi_larb_of_ids[] = {
> {
> .compatible =
Re: [PATCH v3 13/15] memory: mtk-smi: Get rid of need_larbid
On 17/11/2018 03:35, Yong Wu wrote:
> The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
> It's no need to parse it again in SMI driver. Only clean some codes.
> This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
> and mt8183.
I'm trying to understand why we need the mediatek,larb-id at all. From what I
understand as long as the mediatek larbs described in the iommu are ordered
(larb0, larb1, larb2, etc) we actually get the same value as defined by
mediatek,larb-id. At least this holds for all present implementations.
On the other hand I don't see where the mtk_iommu_v1 driver actually parses the
larb-id, can you please help to understand:
1) why we need the larb-id at all
2) how this will work if we do not parse the larb-id for v1 iommu at all
Thanks a lot,
Matthias
>
> Signed-off-by: Yong Wu
> ---
> drivers/memory/mtk-smi.c | 27 ++-
> 1 file changed, 2 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index e4daabb..e0265fe 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -67,7 +67,6 @@ struct mtk_smi_common_plat {
> };
>
> struct mtk_smi_larb_gen {
> - bool need_larbid;
> int port_in_larb[MTK_LARB_NR_MAX + 1];
> void (*config_port)(struct device *);
> unsigned int larb_special_mask; /* The special larbs mask. */
> @@ -152,18 +151,9 @@ void mtk_smi_larb_put(struct device *larbdev)
> struct mtk_smi_iommu *smi_iommu = data;
> unsigned int i;
>
> - if (larb->larb_gen->need_larbid) {
> - larb->mmu = _iommu->larb_imu[larb->larbid].mmu;
> - return 0;
> - }
> -
> - /*
> - * If there is no larbid property, Loop to find the corresponding
> - * iommu information.
> - */
> - for (i = 0; i < smi_iommu->larb_nr; i++) {
> + for (i = 0; i < MTK_LARB_NR_MAX; i++) {
> if (dev == smi_iommu->larb_imu[i].dev) {
> - /* The 'mmu' may be updated in iommu-attach/detach. */
> + larb->larbid = i;
> larb->mmu = _iommu->larb_imu[i].mmu;
> return 0;
> }
> @@ -242,7 +232,6 @@ static void mtk_smi_larb_config_port_gen1(struct device
> *dev)
> };
>
> static const struct mtk_smi_larb_gen mtk_smi_larb_mt2701 = {
> - .need_larbid = true,
> .port_in_larb = {
> LARB0_PORT_OFFSET, LARB1_PORT_OFFSET,
> LARB2_PORT_OFFSET, LARB3_PORT_OFFSET
> @@ -251,13 +240,11 @@ static void mtk_smi_larb_config_port_gen1(struct device
> *dev)
> };
>
> static const struct mtk_smi_larb_gen mtk_smi_larb_mt2712 = {
> - .need_larbid = true,
> .config_port = mtk_smi_larb_config_port_gen2_general,
> .larb_special_mask = BIT(8) | BIT(9), /* bdpsys */
> };
>
> static const struct mtk_smi_larb_gen mtk_smi_larb_mt8183 = {
> - .need_larbid = true,
> .config_port = mtk_smi_larb_config_port_gen2_general,
> .larb_special_mask = BIT(2) | BIT(3) | BIT(7), /* IPU0 | IPU1 | CCU */
> };
> @@ -289,7 +276,6 @@ static int mtk_smi_larb_probe(struct platform_device
> *pdev)
> struct device *dev = >dev;
> struct device_node *smi_node;
> struct platform_device *smi_pdev;
> - int err;
>
> larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
> if (!larb)
> @@ -316,15 +302,6 @@ static int mtk_smi_larb_probe(struct platform_device
> *pdev)
> return PTR_ERR(larb->smi.clk_gals0);
> larb->smi.dev = dev;
>
> - if (larb->larb_gen->need_larbid) {
> - err = of_property_read_u32(dev->of_node, "mediatek,larb-id",
> ->larbid);
> - if (err) {
> - dev_err(dev, "missing larbid property\n");
> - return err;
> - }
> - }
> -
> smi_node = of_parse_phandle(dev->of_node, "mediatek,smi", 0);
> if (!smi_node)
> return -EINVAL;
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/4] Add MT7623 dts bindings documentation
On 03/10/2018 11:09, Matthias Brugger wrote: > Mediateks MT7623 SoC shares most of its component with MT2701. > This series adds devicetree documentation for all the devices. > > It applies cleanly against linux next, so I don't expect any merge > conflicts if this is taken by Arnd through the arm-soc tree for v4.20 > > For completeness, I merged the whole series to v4.19-next/dts32 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 4/4] dt-bindings: mediatek: Add bindig for MT7623 IOMMU and SMI
This patch add the binding documentation for the iommu and smi devices on the MT7623 SoC. Signed-off-by: Matthias Brugger --- .../bindings/memory-controllers/mediatek,smi-common.txt| 1 + .../bindings/memory-controllers/mediatek,smi-larb.txt | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt index 615abdd0eb0d..e937ddd871a6 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt @@ -17,6 +17,7 @@ Required properties: - compatible : must be one of : "mediatek,mt2701-smi-common" "mediatek,mt2712-smi-common" + "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common" "mediatek,mt8173-smi-common" - reg : the register and size of the SMI block. - power-domains : a phandle to the power domain of this local arbiter. diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt index 083155cdc2a0..94eddcae77ab 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt @@ -6,6 +6,7 @@ Required properties: - compatible : must be one of : "mediatek,mt2701-smi-larb" "mediatek,mt2712-smi-larb" + "mediatek,mt7623-smi-larb", "mediatek,mt2701-smi-larb" "mediatek,mt8173-smi-larb" - reg : the register and size of this local arbiter. - mediatek,smi : a phandle to the smi_common node. @@ -16,7 +17,7 @@ Required properties: the register. - "smi" : It's the clock for transfer data and command. -Required property for mt2701 and mt2712: +Required property for mt2701, mt2712 and mt7623: - mediatek,larb-id :the hardware id of this larb. Example: -- 2.19.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/4] dt-bindings: iommu: mediatek: Add binding for MT7623
This patch adds binding documentation for MT7623 SoC. Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/iommu/mediatek,iommu.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt index df5db732138d..6922db598def 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt @@ -41,6 +41,8 @@ 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,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses +generation one m4u HW. "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW. - reg : m4u register base and size. - interrupts : the interrupt of m4u. @@ -51,7 +53,7 @@ Required properties: according to the local arbiter index, like larb0, larb1, larb2... - iommu-cells : must be 1. This is the mtk_m4u_id according to the HW. Specifies the mtk_m4u_id as defined in - dt-binding/memory/mt2701-larb-port.h for mt2701, + dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623 dt-binding/memory/mt2712-larb-port.h for mt2712, and dt-binding/memory/mt8173-larb-port.h for mt8173. -- 2.19.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
