[PATCH] iommu/ipmmu-vmsa: Fix compatible for rcar-gen4

[Yoshihiro Shimoda]

Fix compatible string for R-Car Gen4.

Fixes: ae684caf465b ("iommu/ipmmu-vmsa: Add support for R-Car Gen4")
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 8fdb84b3642b..1d42084d0276 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -987,7 +987,7 @@ static const struct of_device_id ipmmu_of_ids[] = {
.compatible = "renesas,ipmmu-r8a779a0",
.data = _features_rcar_gen4,
}, {
-   .compatible = "renesas,rcar-gen4-ipmmu",
+   .compatible = "renesas,rcar-gen4-ipmmu-vmsa",
.data = _features_rcar_gen4,
}, {
/* Terminator */
-- 
2.25.1

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

RE: [PATCH v2] dt-bindings: iommu: renesas,ipmmu-vmsa: R-Car V3U is R-Car Gen4

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Friday, June 10, 2022 7:10 PM
> 
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family.  Hence move its compatible value to the R-Car Gen4 section.
> 
> Signed-off-by: Geert Uytterhoeven 
> Acked-by: Krzysztof Kozlowski 
> Acked-by: Joerg Roedel 
> Reviewed-by: Wolfram Sang 

Thank you for the patch!

Reviewed-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

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

[PATCH v3 2/2] iommu/ipmmu-vmsa: Add support for R-Car Gen4

[Yoshihiro Shimoda]

Add support for R-Car Gen4 like r8a779f0 (R-Car S4-8). The IPMMU
hardware design of r8a779f0 is the same as r8a779a0. So, rename
"r8a779a0" to "rcar_gen4".

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
---
 drivers/iommu/ipmmu-vmsa.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index ca752bdc710f..0f7e975546e9 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -719,6 +719,7 @@ static int ipmmu_init_platform_device(struct device *dev,
 
 static const struct soc_device_attribute soc_needs_opt_in[] = {
{ .family = "R-Car Gen3", },
+   { .family = "R-Car Gen4", },
{ .family = "RZ/G2", },
{ /* sentinel */ }
 };
@@ -743,7 +744,7 @@ static bool ipmmu_device_is_allowed(struct device *dev)
unsigned int i;
 
/*
-* R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
+* R-Car Gen3/4 and RZ/G2 use the allow list to opt-in devices.
 * For Other SoCs, this returns true anyway.
 */
if (!soc_device_match(soc_needs_opt_in))
@@ -926,7 +927,7 @@ static const struct ipmmu_features ipmmu_features_rcar_gen3 
= {
.utlb_offset_base = 0,
 };
 
-static const struct ipmmu_features ipmmu_features_r8a779a0 = {
+static const struct ipmmu_features ipmmu_features_rcar_gen4 = {
.use_ns_alias_offset = false,
.has_cache_leaf_nodes = true,
.number_of_contexts = 16,
@@ -982,7 +983,10 @@ static const struct of_device_id ipmmu_of_ids[] = {
.data = _features_rcar_gen3,
}, {
.compatible = "renesas,ipmmu-r8a779a0",
-   .data = _features_r8a779a0,
+   .data = _features_rcar_gen4,
+   }, {
+   .compatible = "renesas,rcar-gen4-ipmmu",
+   .data = _features_rcar_gen4,
}, {
/* Terminator */
},
-- 
2.25.1

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

[PATCH v3 0/2] iommu/ipmmu-vmsa: Add support for R-Car Gen4

[Yoshihiro Shimoda]

This patch series is based on renesas-drivers-2022-01-11-v5.16 [1].
Note that we have to prepare the following registers' setting
in a bootloader (U-Boot) because the registers are protected.
Otherwise, data mismatch happened if dmatest with the ipmmu is running.

 => mw eed01500 0xc000; mw eed41500 0xc000

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tag/?h=renesas-drivers-2022-01-11-v5.16

Changes from v2:
 - Add Reviewed-by tag in patch 1 and 2 (Geert-san, thanks!)
 - Revise commit description in patch 1.
 
https://lore.kernel.org/all/20220204125653.1194249-1-yoshihiro.shimoda...@renesas.com/

Changes from v1:
 - Add Reviewed-by tag in patch 1. (Geert-san, thanks!)
 - Revise a comment in patch 2.
 
https://lore.kernel.org/all/20220125125602.4144793-1-yoshihiro.shimoda...@renesas.com/

Y

Yoshihiro Shimoda (2):
  dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779f0 support
  iommu/ipmmu-vmsa: Add support for R-Car Gen4

 .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml  |  4 
 drivers/iommu/ipmmu-vmsa.c | 10 +++---
 2 files changed, 11 insertions(+), 3 deletions(-)

-- 
2.25.1

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

[PATCH v3 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a779f0 support

[Yoshihiro Shimoda]

Document the compatible values for the IPMMU-VMSA blocks in
the Renesas R-Car S4-8 (R8A779F0) SoC and R-Car Gen4.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
---
 .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index ce0c715205c6..5159a87f3fa7 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -44,6 +44,10 @@ properties:
   - renesas,ipmmu-r8a77990 # R-Car E3
   - renesas,ipmmu-r8a77995 # R-Car D3
   - renesas,ipmmu-r8a779a0 # R-Car V3U
+  - items:
+  - enum:
+  - renesas,ipmmu-r8a779f0 # R-Car S4-8
+  - const: renesas,rcar-gen4-ipmmu-vmsa  # R-Car Gen4
 
   reg:
 maxItems: 1
-- 
2.25.1

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

RE: [PATCH v2 1/2] dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779f0 support

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Monday, February 7, 2022 11:26 PM
> 
> On Fri, Feb 4, 2022 at 2:54 PM Yoshihiro Shimoda
>  wrote:
> > Document the compatible values for the IPMMU-VMSA blocks in
> > the Renesas R-Car S4-8 (R8A779F0) SoC and R-Car Gen4.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > 3fbefb9570325500dbf3faff80ded6d0d46f48b2

Oops! I completely mistook adding a strange hash here...
I intended to add Geert-san's Reviewed-by here...

> Reviewed-by: Geert Uytterhoeven 

Thank you for your review again! I'll resend v3 patch.

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v2 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a779f0 support

[Yoshihiro Shimoda]

Document the compatible values for the IPMMU-VMSA blocks in
the Renesas R-Car S4-8 (R8A779F0) SoC and R-Car Gen4.

Signed-off-by: Yoshihiro Shimoda 
3fbefb9570325500dbf3faff80ded6d0d46f48b2
---
 .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index ce0c715205c6..5159a87f3fa7 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -44,6 +44,10 @@ properties:
   - renesas,ipmmu-r8a77990 # R-Car E3
   - renesas,ipmmu-r8a77995 # R-Car D3
   - renesas,ipmmu-r8a779a0 # R-Car V3U
+  - items:
+  - enum:
+  - renesas,ipmmu-r8a779f0 # R-Car S4-8
+  - const: renesas,rcar-gen4-ipmmu-vmsa  # R-Car Gen4
 
   reg:
 maxItems: 1
-- 
2.25.1

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

[PATCH v2 2/2] iommu/ipmmu-vmsa: Add support for R-Car Gen4

[Yoshihiro Shimoda]

Add support for R-Car Gen4 like r8a779f0 (R-Car S4-8). The IPMMU
hardware design of r8a779f0 is the same as r8a779a0. So, rename
"r8a779a0" to "rcar_gen4".

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index ca752bdc710f..0f7e975546e9 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -719,6 +719,7 @@ static int ipmmu_init_platform_device(struct device *dev,
 
 static const struct soc_device_attribute soc_needs_opt_in[] = {
{ .family = "R-Car Gen3", },
+   { .family = "R-Car Gen4", },
{ .family = "RZ/G2", },
{ /* sentinel */ }
 };
@@ -743,7 +744,7 @@ static bool ipmmu_device_is_allowed(struct device *dev)
unsigned int i;
 
/*
-* R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
+* R-Car Gen3/4 and RZ/G2 use the allow list to opt-in devices.
 * For Other SoCs, this returns true anyway.
 */
if (!soc_device_match(soc_needs_opt_in))
@@ -926,7 +927,7 @@ static const struct ipmmu_features ipmmu_features_rcar_gen3 
= {
.utlb_offset_base = 0,
 };
 
-static const struct ipmmu_features ipmmu_features_r8a779a0 = {
+static const struct ipmmu_features ipmmu_features_rcar_gen4 = {
.use_ns_alias_offset = false,
.has_cache_leaf_nodes = true,
.number_of_contexts = 16,
@@ -982,7 +983,10 @@ static const struct of_device_id ipmmu_of_ids[] = {
.data = _features_rcar_gen3,
}, {
.compatible = "renesas,ipmmu-r8a779a0",
-   .data = _features_r8a779a0,
+   .data = _features_rcar_gen4,
+   }, {
+   .compatible = "renesas,rcar-gen4-ipmmu",
+   .data = _features_rcar_gen4,
}, {
/* Terminator */
},
-- 
2.25.1

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

[PATCH v2 0/2] iommu/ipmmu-vmsa: Add support for R-Car Gen4

[Yoshihiro Shimoda]

This patch series is based on renesas-drivers-2022-01-11-v5.16 [1].
Note that we have to prepare the following registers' setting
in a bootloader (U-Boot) because the registers are protected.
Otherwise, data mismatch happened if dmatest with the ipmmu is running.

 => mw eed01500 0xc000; mw eed41500 0xc000

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tag/?h=renesas-drivers-2022-01-11-v5.16

Changes from v1:
 - Add Reviewed-by tag in patch 1. (Geert-san, thanks!)
 - Revise a comment in patch 2.
 
https://lore.kernel.org/all/20220125125602.4144793-1-yoshihiro.shimoda...@renesas.com/

Yoshihiro Shimoda (2):
  dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779f0 support
  iommu/ipmmu-vmsa: Add support for R-Car Gen4

 .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml  |  4 
 drivers/iommu/ipmmu-vmsa.c | 10 +++---
 2 files changed, 11 insertions(+), 3 deletions(-)

-- 
2.25.1

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

RE: [PATCH 2/2] iommu/ipmmu-vmsa: Add support for R-Car Gen4

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Wednesday, February 2, 2022 8:07 PM
> 
> Hi Shimoda-san,
> 
> On Wed, Feb 2, 2022 at 11:48 AM Yoshihiro Shimoda
>  wrote:
> > > From: Geert Uytterhoeven, Sent: Wednesday, February 2, 2022 6:24 PM
> > > On Tue, Jan 25, 2022 at 6:36 PM Yoshihiro Shimoda
> > >  wrote:
> > > > Add support for R-Car Gen4 like r8a779f0 (R-Car S4-8). The IPMMU
> > > > hardware design of r8a779f0 is the same as r8a779a0. So, rename
> > > > "r8a779a0" to "rcar_gen4".
> > > >
> > > > Signed-off-by: Yoshihiro Shimoda 
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > > +++ b/drivers/iommu/ipmmu-vmsa.c
> > >
> > > > @@ -743,7 +744,7 @@ static bool ipmmu_device_is_allowed(struct device 
> > > > *dev)
> > > > unsigned int i;
> > > >
> > > > /*
> > > > -* R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> > > > +* R-Car Gen3, Gen4 and RZ/G2 use the allow list to opt-in 
> > > > devices.
> > > >  * For Other SoCs, this returns true anyway.
> > > >  */
> > > > if (!soc_device_match(soc_needs_opt_in))
> > >
> > > There are a few more references to "Gen3" that can be extended.
> >
> > I'm afraid, but I could not understand this mean.
> 
> I'm sorry. I mean comments that currently say "Gen3", while they are
> applicable to R-Car Gen4, too. I think it would be good to update them
> to "Gen3/4".

Thank you. I understood it. So, I'll fix it in v2.

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 2/2] iommu/ipmmu-vmsa: Add support for R-Car Gen4

[Yoshihiro Shimoda]

Hi Geert-san,

Thank you for your review!

> From: Geert Uytterhoeven, Sent: Wednesday, February 2, 2022 6:24 PM
> 
> Hi Shimoda-san,
> 
> On Tue, Jan 25, 2022 at 6:36 PM Yoshihiro Shimoda
>  wrote:
> > Add support for R-Car Gen4 like r8a779f0 (R-Car S4-8). The IPMMU
> > hardware design of r8a779f0 is the same as r8a779a0. So, rename
> > "r8a779a0" to "rcar_gen4".
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Thanks for your patch!
> 
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> 
> > @@ -743,7 +744,7 @@ static bool ipmmu_device_is_allowed(struct device *dev)
> > unsigned int i;
> >
> > /*
> > -* R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> > +* R-Car Gen3, Gen4 and RZ/G2 use the allow list to opt-in devices.
> >  * For Other SoCs, this returns true anyway.
> >  */
> > if (!soc_device_match(soc_needs_opt_in))
> 
> There are a few more references to "Gen3" that can be extended.

I'm afraid, but I could not understand this mean.

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a779f0 support

[Yoshihiro Shimoda]

Hi Geert-san,

Thank you for your review!

> From: Geert Uytterhoeven, Sent: Thursday, January 27, 2022 8:06 PM
> 
> Hi Shimoda-san,
> 
> CC Laurent, Magnus.
> 
> On Tue, Jan 25, 2022 at 6:33 PM Yoshihiro Shimoda
>  wrote:
> > Document the compatible values for the IPMMU-VMSA blocks in
> > the Renesas R-Car S4-8 (R8A779F0) SoC and R-Car Gen4.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Thanks for your patch!
> 
> > --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > @@ -44,6 +44,10 @@ properties:
> >- renesas,ipmmu-r8a77990 # R-Car E3
> >- renesas,ipmmu-r8a77995 # R-Car D3
> >- renesas,ipmmu-r8a779a0 # R-Car V3U
> > +  - items:
> > +  - enum:
> > +  - renesas,ipmmu-r8a779f0 # R-Car S4-8
> > +  - const: renesas,rcar-gen4-ipmmu-vmsa  # R-Car Gen4
> >
> 
> I'm wondering if we need the family-specific fallback.
> For R-Car Gen3, we don't have it, and match on (all) the SoC-specific
> compatible values instead.
> Do you remember why we decided to do it that way?
> 
> At least R-Car V3M/V3H/D3 have slight differences in the register bits,
> but I don't think that was the reason.

I don't remember why... Maybe, we had never discussed this topic?
I searched this topic a little on the ML archive, but I could not find it...

Since upcoming R-Car Gen4 SoC's IPMMU is the same specification with r8a779f0,
I believe renesas,rcar-gen4-ipmmu-vmsa is helpful to support it.

Best regards,
Yoshihiro Shimoda

> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/2] iommu/ipmmu-vmsa: Add support for R-Car Gen4

[Yoshihiro Shimoda]

Add support for R-Car Gen4 like r8a779f0 (R-Car S4-8). The IPMMU
hardware design of r8a779f0 is the same as r8a779a0. So, rename
"r8a779a0" to "rcar_gen4".

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index ca752bdc710f..6c4314c2e9bf 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -719,6 +719,7 @@ static int ipmmu_init_platform_device(struct device *dev,
 
 static const struct soc_device_attribute soc_needs_opt_in[] = {
{ .family = "R-Car Gen3", },
+   { .family = "R-Car Gen4", },
{ .family = "RZ/G2", },
{ /* sentinel */ }
 };
@@ -743,7 +744,7 @@ static bool ipmmu_device_is_allowed(struct device *dev)
unsigned int i;
 
/*
-* R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
+* R-Car Gen3, Gen4 and RZ/G2 use the allow list to opt-in devices.
 * For Other SoCs, this returns true anyway.
 */
if (!soc_device_match(soc_needs_opt_in))
@@ -926,7 +927,7 @@ static const struct ipmmu_features ipmmu_features_rcar_gen3 
= {
.utlb_offset_base = 0,
 };
 
-static const struct ipmmu_features ipmmu_features_r8a779a0 = {
+static const struct ipmmu_features ipmmu_features_rcar_gen4 = {
.use_ns_alias_offset = false,
.has_cache_leaf_nodes = true,
.number_of_contexts = 16,
@@ -982,7 +983,10 @@ static const struct of_device_id ipmmu_of_ids[] = {
.data = _features_rcar_gen3,
}, {
.compatible = "renesas,ipmmu-r8a779a0",
-   .data = _features_r8a779a0,
+   .data = _features_rcar_gen4,
+   }, {
+   .compatible = "renesas,rcar-gen4-ipmmu",
+   .data = _features_rcar_gen4,
}, {
/* Terminator */
},
-- 
2.25.1

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

[PATCH 0/2] iommu/ipmmu-vmsa: Add support for R-Car Gen4

[Yoshihiro Shimoda]

This patch series is based on renesas-drivers-2022-01-11-v5.16 [1].
Note that we have to prepare the following registers' setting
in a bootloader (U-Boot) because the registers are protected.
Otherwise, data mismatch happened if dmatest with the ipmmu is running.

 => mw eed01500 0xc000; mw eed41500 0xc000

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tag/?h=renesas-drivers-2022-01-11-v5.16


Yoshihiro Shimoda (2):
  dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779f0 support
  iommu/ipmmu-vmsa: Add support for R-Car Gen4

 .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml  |  4 
 drivers/iommu/ipmmu-vmsa.c | 10 +++---
 2 files changed, 11 insertions(+), 3 deletions(-)

-- 
2.25.1

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

[PATCH 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a779f0 support

[Yoshihiro Shimoda]

Document the compatible values for the IPMMU-VMSA blocks in
the Renesas R-Car S4-8 (R8A779F0) SoC and R-Car Gen4.

Signed-off-by: Yoshihiro Shimoda 
---
 .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index ce0c715205c6..5159a87f3fa7 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -44,6 +44,10 @@ properties:
   - renesas,ipmmu-r8a77990 # R-Car E3
   - renesas,ipmmu-r8a77995 # R-Car D3
   - renesas,ipmmu-r8a779a0 # R-Car V3U
+  - items:
+  - enum:
+  - renesas,ipmmu-r8a779f0 # R-Car S4-8
+  - const: renesas,rcar-gen4-ipmmu-vmsa  # R-Car Gen4
 
   reg:
 maxItems: 1
-- 
2.25.1

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

RE: [PATCH v2 0/2] iommu/ipmmu-vmsa: Add support for r8a779a0

[Yoshihiro Shimoda]

Hi Joerg, Will,

> From: Yoshihiro Shimoda, Sent: Tuesday, September 7, 2021 5:30 PM
> 
> This patch series adds support for r8a779a0 (R-Car V3U).

Would you review this patch series?

Best regards,
Yoshihiro Shimoda

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

[PATCH v2 2/2] iommu/ipmmu-vmsa: Add support for r8a779a0

[Yoshihiro Shimoda]

Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
of this SoC differs than others. So, add a new ipmmu_features for it.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
---
 drivers/iommu/ipmmu-vmsa.c | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index d38ff29a76e8..d8fe5ba0cb23 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -33,10 +33,10 @@
 #define arm_iommu_detach_device(...)   do {} while (0)
 #endif
 
-#define IPMMU_CTX_MAX  8U
+#define IPMMU_CTX_MAX  16U
 #define IPMMU_CTX_INVALID  -1
 
-#define IPMMU_UTLB_MAX 48U
+#define IPMMU_UTLB_MAX 64U
 
 struct ipmmu_features {
bool use_ns_alias_offset;
@@ -189,8 +189,12 @@ static void ipmmu_write(struct ipmmu_vmsa_device *mmu, 
unsigned int offset,
 static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
  unsigned int context_id, unsigned int reg)
 {
-   return mmu->features->ctx_offset_base +
-  context_id * mmu->features->ctx_offset_stride + reg;
+   unsigned int base = mmu->features->ctx_offset_base;
+
+   if (context_id > 7)
+   base += 0x800 - 8 * 0x40;
+
+   return base + context_id * mmu->features->ctx_offset_stride + reg;
 }
 
 static u32 ipmmu_ctx_read(struct ipmmu_vmsa_device *mmu,
@@ -922,6 +926,20 @@ static const struct ipmmu_features 
ipmmu_features_rcar_gen3 = {
.utlb_offset_base = 0,
 };
 
+static const struct ipmmu_features ipmmu_features_r8a779a0 = {
+   .use_ns_alias_offset = false,
+   .has_cache_leaf_nodes = true,
+   .number_of_contexts = 16,
+   .num_utlbs = 64,
+   .setup_imbuscr = false,
+   .twobit_imttbcr_sl0 = true,
+   .reserved_context = true,
+   .cache_snoop = false,
+   .ctx_offset_base = 0x1,
+   .ctx_offset_stride = 0x1040,
+   .utlb_offset_base = 0x3000,
+};
+
 static const struct of_device_id ipmmu_of_ids[] = {
{
.compatible = "renesas,ipmmu-vmsa",
@@ -959,6 +977,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
}, {
.compatible = "renesas,ipmmu-r8a77995",
.data = _features_rcar_gen3,
+   }, {
+   .compatible = "renesas,ipmmu-r8a779a0",
+   .data = _features_r8a779a0,
}, {
/* Terminator */
},
-- 
2.25.1

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

[PATCH v2 0/2] iommu/ipmmu-vmsa: Add support for r8a779a0

[Yoshihiro Shimoda]

This patch series adds support for r8a779a0 (R-Car V3U).

Changes from v1:
 - Add {Ack,Review}ed-by in the patch 1.
 - Add support 16 contexts in the patch 2.
 - Add Reviewed-by in the patch 2.
 
https://lore.kernel.org/all/20210901102705.556093-1-yoshihiro.shimoda...@renesas.com/

Yoshihiro Shimoda (2):
  dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779a0 support
  iommu/ipmmu-vmsa: Add support for r8a779a0

 .../bindings/iommu/renesas,ipmmu-vmsa.yaml|  1 +
 drivers/iommu/ipmmu-vmsa.c| 29 ---
 2 files changed, 26 insertions(+), 4 deletions(-)

-- 
2.25.1

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

[PATCH v2 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a779a0 support

[Yoshihiro Shimoda]

Add support for r8a779a0 (R-Car V3U).

Signed-off-by: Yoshihiro Shimoda 
Acked-by: Rob Herring 
Reviewed-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index 02c69a95c332..ce0c715205c6 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -43,6 +43,7 @@ properties:
   - renesas,ipmmu-r8a77980 # R-Car V3H
   - renesas,ipmmu-r8a77990 # R-Car E3
   - renesas,ipmmu-r8a77995 # R-Car D3
+  - renesas,ipmmu-r8a779a0 # R-Car V3U
 
   reg:
 maxItems: 1
-- 
2.25.1

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

RE: [PATCH 2/2] iommu/ipmmu-vmsa: Add support for r8a779a0

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Tuesday, September 7, 2021 3:34 PM
> 
> Hi Shimoda-san,
> 
> On Tue, Sep 7, 2021 at 2:02 AM Yoshihiro Shimoda
>  wrote:
> > > From: Geert Uytterhoeven, Sent: Tuesday, September 7, 2021 12:34 AM
> > > On Wed, Sep 1, 2021 at 12:27 PM Yoshihiro Shimoda
> > >  wrote:
> > > > Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
> > > > of this SoC differs than others. So, add a new ipmmu_features for it.
> > > >
> > > > Signed-off-by: Yoshihiro Shimoda 
> > >
> > > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > > +++ b/drivers/iommu/ipmmu-vmsa.c
> > >
> > > > @@ -922,6 +922,20 @@ static const struct ipmmu_features 
> > > > ipmmu_features_rcar_gen3 = {
> > > > .utlb_offset_base = 0,
> > > >  };
> > > >
> > > > +static const struct ipmmu_features ipmmu_features_r8a779a0 = {
> > > > +   .use_ns_alias_offset = false,
> > > > +   .has_cache_leaf_nodes = true,
> > > > +   .number_of_contexts = 8,
> > >
> > > Shouldn't this be 16?
> > > Or do you plan to add support for more than 8 contexts later, as that
> > > would require increasing IPMMU_CTX_MAX, and updating ipmmu_ctx_reg()
> > > to handle the second bank of 8 contexts?
> >
> > I would like to add support for more than 8 contexts later because
> > I realized that ctx_offset_{base,stride} are not suitable for the second 
> > bank
> > of 8 contexts...
> 
> Wouldn't something like below be sufficient?

Thank you for your suggestion!

>  static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
>   unsigned int context_id, unsigned int reg)
>  {
> -   return mmu->features->ctx_offset_base +
> -  context_id * mmu->features->ctx_offset_stride + reg;
> +   unsigned int base = mmu->features->ctx_offset_base;
> +
> +   if (context_id > 7)
> +   base += 0x800 - 8 * 0x1040;

This should be "base += 0x800 - 8 * 0x40;" because the 8th context address is
0x18800, not 0x10800.

I'll send v2 patch to support 16 contexts.
(I'll change IPMMU_CTX_MAX to 16 too.)

Best regards,
Yoshihiro Shimoda

> +
> +   return base + context_id * mmu->features->ctx_offset_stride + reg;
>  }
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 2/2] iommu/ipmmu-vmsa: Add support for r8a779a0

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Tuesday, September 7, 2021 12:34 AM
> 
> Hi Shimoda-san,
> 
> On Wed, Sep 1, 2021 at 12:27 PM Yoshihiro Shimoda
>  wrote:
> > Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
> > of this SoC differs than others. So, add a new ipmmu_features for it.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> 
> > @@ -922,6 +922,20 @@ static const struct ipmmu_features 
> > ipmmu_features_rcar_gen3 = {
> > .utlb_offset_base = 0,
> >  };
> >
> > +static const struct ipmmu_features ipmmu_features_r8a779a0 = {
> > +   .use_ns_alias_offset = false,
> > +   .has_cache_leaf_nodes = true,
> > +   .number_of_contexts = 8,
> 
> Shouldn't this be 16?
> Or do you plan to add support for more than 8 contexts later, as that
> would require increasing IPMMU_CTX_MAX, and updating ipmmu_ctx_reg()
> to handle the second bank of 8 contexts?

I would like to add support for more than 8 contexts later because
I realized that ctx_offset_{base,stride} are not suitable for the second bank
of 8 contexts...

> Regardless, I assume this will still work when when limiting to 8
> contexts, so
> Reviewed-by: Geert Uytterhoeven 

Thank you for your review!

Best regards,
Yoshihiro Shimoda

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

[PATCH 2/2] iommu/ipmmu-vmsa: Add support for r8a779a0

[Yoshihiro Shimoda]

Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
of this SoC differs than others. So, add a new ipmmu_features for it.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index d38ff29a76e8..c46951367f93 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -36,7 +36,7 @@
 #define IPMMU_CTX_MAX  8U
 #define IPMMU_CTX_INVALID  -1
 
-#define IPMMU_UTLB_MAX 48U
+#define IPMMU_UTLB_MAX 64U
 
 struct ipmmu_features {
bool use_ns_alias_offset;
@@ -922,6 +922,20 @@ static const struct ipmmu_features 
ipmmu_features_rcar_gen3 = {
.utlb_offset_base = 0,
 };
 
+static const struct ipmmu_features ipmmu_features_r8a779a0 = {
+   .use_ns_alias_offset = false,
+   .has_cache_leaf_nodes = true,
+   .number_of_contexts = 8,
+   .num_utlbs = 64,
+   .setup_imbuscr = false,
+   .twobit_imttbcr_sl0 = true,
+   .reserved_context = true,
+   .cache_snoop = false,
+   .ctx_offset_base = 0x1,
+   .ctx_offset_stride = 0x1040,
+   .utlb_offset_base = 0x3000,
+};
+
 static const struct of_device_id ipmmu_of_ids[] = {
{
.compatible = "renesas,ipmmu-vmsa",
@@ -959,6 +973,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
}, {
.compatible = "renesas,ipmmu-r8a77995",
.data = _features_rcar_gen3,
+   }, {
+   .compatible = "renesas,ipmmu-r8a779a0",
+   .data = _features_r8a779a0,
}, {
/* Terminator */
},
-- 
2.25.1

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

[PATCH 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a779a0 support

[Yoshihiro Shimoda]

Add support for r8a779a0 (R-Car V3U).

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index 02c69a95c332..ce0c715205c6 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -43,6 +43,7 @@ properties:
   - renesas,ipmmu-r8a77980 # R-Car V3H
   - renesas,ipmmu-r8a77990 # R-Car E3
   - renesas,ipmmu-r8a77995 # R-Car D3
+  - renesas,ipmmu-r8a779a0 # R-Car V3U
 
   reg:
 maxItems: 1
-- 
2.25.1

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

[PATCH 0/2] iommu/ipmmu-vmsa: Add support for r8a779a0

[Yoshihiro Shimoda]

This patch series adds support for r8a779a0 (R-Car V3U).

Yoshihiro Shimoda (2):
  dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779a0 support
  iommu/ipmmu-vmsa: Add support for r8a779a0

 .../bindings/iommu/renesas,ipmmu-vmsa.yaml|  1 +
 drivers/iommu/ipmmu-vmsa.c| 19 ++-
 2 files changed, 19 insertions(+), 1 deletion(-)

-- 
2.25.1

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

RE: [PATCH v3 06/25] iommu/ipmmu-vmsa: Drop IOVA cookie management

[Yoshihiro Shimoda]

Hi Robin,

> From: Robin Murphy, Sent: Thursday, August 5, 2021 2:16 AM
> 
> The core code bakes its own cookies now.
> 
> CC: Yoshihiro Shimoda 
> CC: Geert Uytterhoeven 
> Signed-off-by: Robin Murphy 

Thank you for the patch!
I tested on my environment (r8a77951-salvator-xs),
and I didn't observe any regression. So,

Reviewed-by: Yoshihiro Shimoda 
Tested-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

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

RE: [PATCH v3 01/25] iommu: Pull IOVA cookie management into the core

[Yoshihiro Shimoda]

Hi Robin,

> From: Robin Murphy, Sent: Thursday, August 5, 2021 2:15 AM
> 
> Now that everyone has converged on iommu-dma for IOMMU_DOMAIN_DMA
> support, we can abandon the notion of drivers being responsible for the
> cookie type, and consolidate all the management into the core code.
> 
> CC: Marek Szyprowski 
> CC: Yoshihiro Shimoda 
> CC: Geert Uytterhoeven 
> CC: Yong Wu 
> CC: Heiko Stuebner 
> CC: Chunyan Zhang 
> CC: Maxime Ripard 
> Reviewed-by: Jean-Philippe Brucker 
> Reviewed-by: Lu Baolu 
> Signed-off-by: Robin Murphy 

Thank you for the patch!
I tested on my environment (r8a77951-salvator-xs),
and I didn't observe any regression. So,

Tested-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

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

RE: next/master bisection: baseline.login on r8a77960-ulcb

[Yoshihiro Shimoda]

Hi all,

> From: Heiko Thiery, Sent: Thursday, February 25, 2021 10:01 PM
> Am Do., 25. Feb. 2021 um 12:50 Uhr schrieb Thierry Reding:
> > On Thu, Feb 25, 2021 at 11:14:57AM +, Robin Murphy wrote:
> > > On 2021-02-25 11:09, Thierry Reding wrote:
> > > > On Wed, Feb 24, 2021 at 10:39:42PM +0100, Heiko Thiery wrote:
> > > > > Hi Christoph and all,
> > > > >
> > > > > On 23.02.21 10:56, Guillaume Tucker wrote:
> > > > > > Hi Christoph,
> > > > > >
> > > > > > Please see the bisection report below about a boot failure on
> > > > > > r8a77960-ulcb on next-20210222.
> > > > > >
> > > > > > Reports aren't automatically sent to the public while we're
> > > > > > trialing new bisection features on kernelci.org but this one
> > > > > > looks valid.
> > > > > >
> > > > > > The log shows a kernel panic, more details can be found here:

> >
> > Yep, changing max_slots from unsigned int to unsigned long fixes this as
> > well. Thanks for the pointer!
> 
> I also can confirm that changing that to unsigned long fixes the issue.

Thank you for the information! I also confirmed that changing the type of
max_slots fixed the issue on my environment (r8a77951-salvator-xs.dts with 
defconfig).

Best regards,
Yoshihiro Shimoda

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

RE: [PATCH 2/3] dt-bindings: iommu: renesas,ipmmu-vmsa: Make 'power-domains' conditionally required

[Yoshihiro Shimoda]

Hi Rob,

> From: Rob Herring, Sent: Wednesday, February 3, 2021 5:56 AM
> 
> Fixing the compatible string typos results in an error in the example:
> 
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.example.dt.yaml:
>   iommu@fe951000: 'power-domains' is a required property
> 
> Based on the dts files, a 'power-domains' property only exists on Gen 3
> which can be conditioned on !renesas,ipmmu-vmsa.
> 
> Cc: Joerg Roedel 
> Cc: Will Deacon 
> Cc: Yoshihiro Shimoda 
> Cc: iommu@lists.linux-foundation.org
> Signed-off-by: Rob Herring 

Thank you for the patch!

Reviewed-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

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

RE: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples

[Yoshihiro Shimoda]

Hi Rob,

> From: Rob Herring, Sent: Wednesday, February 3, 2021 5:56 AM
> 
> Running 'dt-validate -m' will flag any compatible strings missing a schema.
> Fix all the errors found in DT binding examples. Most of these are just
> typos.
> 
> Cc: Stephen Boyd 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Linus Walleij 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Cc: Daniel Palmer 
> Cc: Bartosz Golaszewski 
> Cc: Avi Fishman 
> Cc: Tomer Maimon 
> Cc: Tali Perry 
> Cc: Joerg Roedel 
> Cc: Will Deacon 
> Cc: Andrew Jeffery 
> Cc: Joel Stanley 
> Cc: Wim Van Sebroeck 
> Cc: Guenter Roeck 
> Cc: Yoshihiro Shimoda 
> Cc: Vincent Cheng 
> Cc: linux-...@vger.kernel.org
> Cc: linux-cry...@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-watch...@vger.kernel.org
> Signed-off-by: Rob Herring 

> diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> index cde1afa8dfd6..349633108bbd 100644
> --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> @@ -93,7 +93,7 @@ examples:
>  #include 
> 
>  ipmmu_mx: iommu@fe951000 {
> -compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
> +    compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";

Oops. Thank you for fixing this.

Reviewed-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

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

[PATCH 1/2] iommu/ipmmu-vmsa: refactor ipmmu_of_xlate()

[Yoshihiro Shimoda]

Refactor ipmmu_of_xlate() to improve readability/scalability.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 49 +-
 1 file changed, 18 insertions(+), 31 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 0f18abd..0bdf354 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -735,54 +735,41 @@ static int ipmmu_init_platform_device(struct device *dev,
return 0;
 }
 
-static const struct soc_device_attribute soc_rcar_gen3[] = {
-   { .soc_id = "r8a774a1", },
-   { .soc_id = "r8a774b1", },
-   { .soc_id = "r8a774c0", },
-   { .soc_id = "r8a774e1", },
-   { .soc_id = "r8a7795", },
-   { .soc_id = "r8a77961", },
-   { .soc_id = "r8a7796", },
-   { .soc_id = "r8a77965", },
-   { .soc_id = "r8a77970", },
-   { .soc_id = "r8a77990", },
-   { .soc_id = "r8a77995", },
+static const struct soc_device_attribute soc_needs_opt_in[] = {
+   { .family = "R-Car Gen3", },
+   { .family = "RZ/G2", },
{ /* sentinel */ }
 };
 
-static const struct soc_device_attribute soc_rcar_gen3_whitelist[] = {
-   { .soc_id = "r8a774b1", },
-   { .soc_id = "r8a774c0", },
-   { .soc_id = "r8a774e1", },
-   { .soc_id = "r8a7795", .revision = "ES3.*" },
-   { .soc_id = "r8a77961", },
-   { .soc_id = "r8a77965", },
-   { .soc_id = "r8a77990", },
-   { .soc_id = "r8a77995", },
+static const struct soc_device_attribute soc_denylist[] = {
+   { .soc_id = "r8a774a1", },
+   { .soc_id = "r8a7795", .revision = "ES1.*" },
+   { .soc_id = "r8a7795", .revision = "ES2.*" },
+   { .soc_id = "r8a7796", },
{ /* sentinel */ }
 };
 
-static const char * const rcar_gen3_slave_whitelist[] = {
+static const char * const devices_allowlist[] = {
 };
 
-static bool ipmmu_slave_whitelist(struct device *dev)
+static bool ipmmu_device_is_allowed(struct device *dev)
 {
unsigned int i;
 
/*
-* For R-Car Gen3 use a white list to opt-in slave devices.
+* R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
 * For Other SoCs, this returns true anyway.
 */
-   if (!soc_device_match(soc_rcar_gen3))
+   if (!soc_device_match(soc_needs_opt_in))
return true;
 
-   /* Check whether this R-Car Gen3 can use the IPMMU correctly or not */
-   if (!soc_device_match(soc_rcar_gen3_whitelist))
+   /* Check whether this SoC can use the IPMMU correctly or not */
+   if (soc_device_match(soc_denylist))
return false;
 
-   /* Check whether this slave device can work with the IPMMU */
-   for (i = 0; i < ARRAY_SIZE(rcar_gen3_slave_whitelist); i++) {
-   if (!strcmp(dev_name(dev), rcar_gen3_slave_whitelist[i]))
+   /* Check whether this device can work with the IPMMU */
+   for (i = 0; i < ARRAY_SIZE(devices_allowlist); i++) {
+   if (!strcmp(dev_name(dev), devices_allowlist[i]))
return true;
}
 
@@ -793,7 +780,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
 static int ipmmu_of_xlate(struct device *dev,
  struct of_phandle_args *spec)
 {
-   if (!ipmmu_slave_whitelist(dev))
+   if (!ipmmu_device_is_allowed(dev))
return -ENODEV;
 
iommu_fwspec_add_ids(dev, spec->args, 1);
-- 
2.7.4

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

[PATCH 2/2] iommu/ipmmu-vmsa: Allow SDHI devices

[Yoshihiro Shimoda]

Add SDHI devices into devices_allowlist.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 0bdf354..5715fbe 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -750,6 +750,10 @@ static const struct soc_device_attribute soc_denylist[] = {
 };
 
 static const char * const devices_allowlist[] = {
+   "ee10.mmc",
+   "ee12.mmc",
+   "ee14.mmc",
+   "ee16.mmc"
 };
 
 static bool ipmmu_device_is_allowed(struct device *dev)
-- 
2.7.4

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

[PATCH 0/2] iommu/ipmmu-vmsa: refactoring and allow SDHI devices

[Yoshihiro Shimoda]

I intend to add new SoC support in near the future, but before that,
I would like to refactor the ipmmu_of_xlate() to improve
readability/scalability. Also, adds SDHI devices into the allow list.

Yoshihiro Shimoda (2):
  iommu/ipmmu-vmsa: refactor ipmmu_of_xlate()
  iommu/ipmmu-vmsa: Allow SDHI devices

 drivers/iommu/ipmmu-vmsa.c | 53 +++---
 1 file changed, 22 insertions(+), 31 deletions(-)

-- 
2.7.4

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

RE: [PATCH 1/2] dt-bindings: iommu: renesas,ipmmu-vmsa: Add r8a7742 support

[Yoshihiro Shimoda]

Hi Lad-san,

> From: Lad Prabhakar, Sent: Tuesday, August 25, 2020 11:18 PM
> 
> Document RZ/G1H (R8A7742) SoC bindings.
> 
> No driver change is needed due to the fallback compatible value
> "renesas,ipmmu-vmsa".
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Chris Paterson 
> ---

Thank you for the patch!

Reviewed-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

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

RE: [PATCH 2/9] iommu/ipmmu-vmsa: Hook up R8A774E1 DT matching code

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Tuesday, July 14, 2020 9:40 PM
> 
> Hi Shimoda-san,
> 
> On Tue, Jul 14, 2020 at 1:42 PM Yoshihiro Shimoda
>  wrote:
> > > From: Geert Uytterhoeven, Sent: Tuesday, July 14, 2020 5:42 PM
> > > On Tue, Jul 14, 2020 at 10:30 AM Lad, Prabhakar
> > >  wrote:
> > > > On Tue, Jul 14, 2020 at 9:09 AM Geert Uytterhoeven 
> > > >  wrote:
> > > > > On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
> > > > Also the recent patch to add
> > > > "r8a77961" just adds to soc_rcar_gen3_whitelist.
> > >
> > > Oops, commit 17fe16181639801b ("iommu/renesas: Add support for r8a77961")
> > > did it wrong, too.
> >
> > Thank you for the point it out. We should add r8a77961 to the 
> > soc_rcar_gen3[].
> > However, I don't know why I could not realize this issue...
> > So, I investigated this a little and then, IIUC, glob_match() which
> > soc_device_match() uses seems to return true, if *pat = "r8a7796" and *str 
> > = "r8a77961".
> 
> Are you sure about this?

I'm very sorry. I completely misunderstood the glob_match() behavior.
And, now I understood why the current code can use IPMMU on r8a77961...
# Since the first soc_device_match() will return false, ipmmu_slave_whitelist()
# will return true and then the ipmmu_of_xlate() will be succeeded.

> I enabled CONFIG_GLOB_SELFTEST, and globtest succeeded.
> It does test glob_match("a", "aa"), which is a similar test.
> 
> To be 100% sure, I added:
> 
> --- a/lib/globtest.c
> +++ b/lib/globtest.c
> @@ -59,6 +59,7 @@ static char const glob_tests[] __initconst =
> "1" "a\0" "a\0"
> "0" "a\0" "b\0"
> "0" "a\0" "aa\0"
> +   "0" "r8a7796\0" "r8a77961\0"
> "0" "a\0" "\0"
> "1" "\0" "\0"
> "0" "\0" "a\0"
> 
> and it still succeeded.

I'm very sorry to waste your time about this...

Best regards,
Yoshihiro Shimoda

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

RE: [PATCH 2/9] iommu/ipmmu-vmsa: Hook up R8A774E1 DT matching code

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Tuesday, July 14, 2020 5:42 PM
> 
> Hi Prabhakar,
> 
> On Tue, Jul 14, 2020 at 10:30 AM Lad, Prabhakar
>  wrote:
> > On Tue, Jul 14, 2020 at 9:09 AM Geert Uytterhoeven  
> > wrote:
> > > On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
> > >  wrote:
> > > > From: Marian-Cristian Rotariu 
> > > > 
> > > >
> > > > Add support for RZ/G2H (R8A774E1) SoC IPMMUs.
> > > >
> > > > Signed-off-by: Marian-Cristian Rotariu 
> > > > 
> > > > Signed-off-by: Lad Prabhakar 
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > > +++ b/drivers/iommu/ipmmu-vmsa.c
> > > > @@ -751,6 +751,7 @@ static const struct soc_device_attribute 
> > > > soc_rcar_gen3[] = {
> > > >  static const struct soc_device_attribute soc_rcar_gen3_whitelist[] = {
> > > > { .soc_id = "r8a774b1", },
> > > > { .soc_id = "r8a774c0", },
> > > > +   { .soc_id = "r8a774e1", },
> > >
> > > Adding an entry to soc_rcar_gen3_whitelist[] doesn't do anything, unless
> > > you also add the same entry to soc_rcar_gen3[].
> > >
> > I think the comment "For R-Car Gen3 use a white list to opt-in slave
> > devices." is misleading.  Booting through the kernel I do see iommu
> > groups (attached is the logs).
> 
> Indeed. Without an entry in soc_rcar_gen3[], the IPMMU is enabled
> unconditionally, and soc_rcar_gen3_whitelist[] is ignored.
> That's why you want an entry in both, unless you have an R-Car Gen3
> SoC where the IPMMU works correctly with all slave devices present.
> Perhaps soc_rcar_gen3[] should be renamed to soc_rcar_gen3_greylist[]
> (or soc_rcar_gen3_maybelist[]) to make this clear?

I think so (we should rename it).

> > Also the recent patch to add
> > "r8a77961" just adds to soc_rcar_gen3_whitelist.
> 
> Oops, commit 17fe16181639801b ("iommu/renesas: Add support for r8a77961")
> did it wrong, too.

Thank you for the point it out. We should add r8a77961 to the soc_rcar_gen3[].
However, I don't know why I could not realize this issue...
So, I investigated this a little and then, IIUC, glob_match() which
soc_device_match() uses seems to return true, if *pat = "r8a7796" and *str = 
"r8a77961".

Best regards,
Yoshihiro Shimoda

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

[PATCH 0/2] iommu/renesas: Add support for r8a77961

[Yoshihiro Shimoda]

This patch series is based on next-20200611.

Yoshihiro Shimoda (2):
  dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a77961 support
  iommu/renesas: Add support for r8a77961

 Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 +
 drivers/iommu/ipmmu-vmsa.c  | 6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.7.4

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

[PATCH 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a77961 support

[Yoshihiro Shimoda]

Add support for r8a77961 (R-Car M3-W+).

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index 39675cf..e9d28a4 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -35,6 +35,7 @@ properties:
   - renesas,ipmmu-r8a774c0 # RZ/G2E
   - renesas,ipmmu-r8a7795  # R-Car H3
   - renesas,ipmmu-r8a7796  # R-Car M3-W
+  - renesas,ipmmu-r8a77961 # R-Car M3-W+
   - renesas,ipmmu-r8a77965 # R-Car M3-N
   - renesas,ipmmu-r8a77970 # R-Car V3M
   - renesas,ipmmu-r8a77980 # R-Car V3H
-- 
2.7.4

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

[PATCH 2/2] iommu/renesas: Add support for r8a77961

[Yoshihiro Shimoda]

Add support for r8a77961 (R-Car M3-W+).

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 4c2972f..b57b1f2 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -3,7 +3,7 @@
  * IOMMU API for Renesas VMSA-compatible IPMMU
  * Author: Laurent Pinchart 
  *
- * Copyright (C) 2014 Renesas Electronics Corporation
+ * Copyright (C) 2014-2020 Renesas Electronics Corporation
  */
 
 #include 
@@ -753,6 +753,7 @@ static const struct soc_device_attribute 
soc_rcar_gen3_whitelist[] = {
{ .soc_id = "r8a774b1", },
{ .soc_id = "r8a774c0", },
{ .soc_id = "r8a7795", .revision = "ES3.*" },
+   { .soc_id = "r8a77961", },
{ .soc_id = "r8a77965", },
{ .soc_id = "r8a77990", },
{ .soc_id = "r8a77995", },
@@ -970,6 +971,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
.compatible = "renesas,ipmmu-r8a7796",
.data = _features_rcar_gen3,
}, {
+   .compatible = "renesas,ipmmu-r8a77961",
+   .data = _features_rcar_gen3,
+   }, {
.compatible = "renesas,ipmmu-r8a77965",
.data = _features_rcar_gen3,
}, {
-- 
2.7.4

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

[PATCH v5] dt-bindings: iommu: renesas, ipmmu-vmsa: convert to json-schema

[Yoshihiro Shimoda]

Convert Renesas VMSA-Compatible IOMMU bindings documentation
to json-schema.

Note that original documentation doesn't mention renesas,ipmmu-vmsa
for R-Mobile APE6. But, R-Mobile APE6 is similar to the R-Car
Gen2. So, renesas,ipmmu-r8a73a4 belongs the renesas,ipmmu-vmsa
section.

Signed-off-by: Yoshihiro Shimoda 
---
 Changes from v4:
 - Fix description about cell counts on #iommu-cells and renesas,ipmmu-main.
 - Fix node name on the example. 
 https://patchwork.kernel.org/patch/11494231/

 Changes from v3:
 - Fix renesas,ipmmu-r8a7795's section
 https://patchwork.kernel.org/patch/11494079/

 Changes from v2:
 - Add a description for R-Mobile APE6 on the commit log.
 - Change renesas,ipmmu-r8a73a4 section on the compatible.
 - Add items on the interrupts.
 - Add power-domains to required.
 - Add oneOf for interrupts and renesas,ipmmu-main
 https://patchwork.kernel.org/patch/11490581/

 Changes from v1:
 - Fix typo in the subject.
 - Add a description on #iommu-cells.
 https://patchwork.kernel.org/patch/11485415/

 .../bindings/iommu/renesas,ipmmu-vmsa.txt  | 73 
 .../bindings/iommu/renesas,ipmmu-vmsa.yaml | 98 ++
 2 files changed, 98 insertions(+), 73 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
 create mode 100644 
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
deleted file mode 100644
index 020d6f2..
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Renesas VMSA-Compatible IOMMU
-
-The IPMMU is an IOMMU implementation compatible with the ARM VMSA page tables.
-It provides address translation for bus masters outside of the CPU, each
-connected to the IPMMU through a port called micro-TLB.
-
-
-Required Properties:
-
-  - compatible: Must contain SoC-specific and generic entry below in case
-the device is compatible with the R-Car Gen2 VMSA-compatible IPMMU.
-
-- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
-- "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU.
-- "renesas,ipmmu-r8a7744" for the R8A7744 (RZ/G1N) IPMMU.
-- "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU.
-- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU.
-- "renesas,ipmmu-r8a774b1" for the R8A774B1 (RZ/G2N) IPMMU.
-- "renesas,ipmmu-r8a774c0" for the R8A774C0 (RZ/G2E) IPMMU.
-- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
-- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
-- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
-- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
-- "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU.
-- "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU.
-- "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU.
-- "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU.
-- "renesas,ipmmu-r8a77980" for the R8A77980 (R-Car V3H) IPMMU.
-- "renesas,ipmmu-r8a77990" for the R8A77990 (R-Car E3) IPMMU.
-- "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU.
-- "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible
-  IPMMU.
-
-  - reg: Base address and size of the IPMMU registers.
-  - interrupts: Specifiers for the MMU fault interrupts. For instances that
-support secure mode two interrupts must be specified, for non-secure and
-secure mode, in that order. For instances that don't support secure mode a
-single interrupt must be specified. Not required for cache IPMMUs.
-
-  - #iommu-cells: Must be 1.
-
-Optional properties:
-
-  - renesas,ipmmu-main: reference to the main IPMMU instance in two cells.
-The first cell is a phandle to the main IPMMU and the second cell is
-the interrupt bit number associated with the particular cache IPMMU device.
-The interrupt bit number needs to match the main IPMMU IMSSTR register.
-Only used by cache IPMMU instances.
-
-
-Each bus master connected to an IPMMU must reference the IPMMU in its device
-node with the following property:
-
-  - iommus: A reference to the IPMMU in two cells. The first cell is a phandle
-to the IPMMU and the second cell the number of the micro-TLB that the
-device is connected to.
-
-
-Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
-
-   ipmmu_mx: mmu@fe951000 {
-   compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
-   reg = <0 0xfe951000 0 0x1000>;
-   interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-   

RE: [PATCH] dt-bndings: iommu: renesas,ipmmu-vmsa: convert to json-schema

[Yoshihiro Shimoda]

Hi Rob,

Thank you for the review!

> From: Rob Herring, Sent: Tuesday, April 21, 2020 4:27 AM
> 
> On Mon, Apr 13, 2020 at 07:25:33PM +0900, Yoshihiro Shimoda wrote:
> > Convert Renesas VMSA-Compatible IOMMU bindings documentation
> > to json-schema.
> >
> > Signed-off-by: Yoshihiro Shimoda 

> > diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > new file mode 100644
> > index ..3820b10
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > @@ -0,0 +1,90 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iommu/renesas,ipmmu-vmsa.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Renesas VMSA-Compatible IOMMU
> > +
> > +maintainers:
> > +  - Yoshihiro Shimoda 
> > +
> > +description:
> > +  The IPMMU is an IOMMU implementation compatible with the ARM VMSA page 
> > tables.
> > +  It provides address translation for bus masters outside of the CPU, each
> > +  connected to the IPMMU through a port called micro-TLB.
> > +
> > +properties:
> > +  compatible:
> > +oneOf:
> > +  - items:
> > +  - enum:
> > +  - renesas,ipmmu-r8a7743  # RZ/G1M
> > +  - renesas,ipmmu-r8a7744  # RZ/G1N
> > +  - renesas,ipmmu-r8a7745  # RZ/G1E
> > +  - renesas,ipmmu-r8a7790  # R-Car H2
> > +  - renesas,ipmmu-r8a7791  # R-Car M2-W
> > +  - renesas,ipmmu-r8a7793  # R-Car M2-N
> > +  - renesas,ipmmu-r8a7794  # R-Car E2
> > +  - renesas,ipmmu-r8a7795  # R-Car H3
> > +  - const: renesas,ipmmu-vmsa  # R-Car Gen2 or RZ/G1
> > +  - items:
> > +  - enum:
> > +  - renesas,ipmmu-r8a73a4  # R-Mobile APE6
> > +  - renesas,ipmmu-r8a774a1 # RZ/G2M
> > +  - renesas,ipmmu-r8a774b1 # RZ/G2N
> > +  - renesas,ipmmu-r8a774c0 # RZ/G2E
> > +  - renesas,ipmmu-r8a7796  # R-Car M3-W
> > +  - renesas,ipmmu-r8a77965 # R-Car M3-N
> > +  - renesas,ipmmu-r8a77970 # R-Car V3M
> > +  - renesas,ipmmu-r8a77980 # R-Car V3H
> > +  - renesas,ipmmu-r8a77990 # R-Car E3
> > +  - renesas,ipmmu-r8a77995 # R-Car D3
> > +
> > +  reg:
> > +maxItems: 1
> > +
> > +  interrupts:
> > +minItems: 1
> > +maxItems: 2
> > +description:
> > +  Specifiers for the MMU fault interrupts. For instances that support
> > +  secure mode two interrupts must be specified, for non-secure and 
> > secure
> > +  mode, in that order. For instances that don't support secure mode a
> > +  single interrupt must be specified. Not required for cache IPMMUs.
> > +
> > +  '#iommu-cells':
> > +const: 1
> > +
> > +  power-domains:
> > +maxItems: 1
> > +
> > +  renesas,ipmmu-main:
> > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > +description:
> > +  Reference to the main IPMMU instance in two cells. The first cell is
> > +  a phandle to the main IPMMU and the second cell is the interrupt bit
> 
> The cell counting is wrong here. We don't count the phandle as a cell.
> It's a 'phandle plus 1 cell'.

I got it. I'll fix it.

> Same goes for 'iommus'.

I understood it. I'll also fix '#iommu-cells' description.

> > +  number associated with the particular cache IPMMU device. The 
> > interrupt
> > +  bit number needs to match the main IPMMU IMSSTR register. Only used 
> > by
> > +  cache IPMMU instances.
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - '#iommu-cells'
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +#include 
> > +#include 
> > +#include 
> > +
> > +ipmmu_mx: mmu@fe951000 {
> 
> iommu@...

I got it.

BTW, all Renesas related dts files are described as "mmu" now.
So, I'll also fix dts files later. Thank you for the pointed it out!

Best regards,
Yoshihiro Shimoda

> > +compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
> > +reg = <0xfe951000 0x1000>;
> > +interrupts = ,
> > + ;
> > +#iommu-cells = <1>;
> > +};
> > --
> > 2.7.4
> >
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v4] dt-bindings: iommu: renesas, ipmmu-vmsa: convert to json-schema

[Yoshihiro Shimoda]

Convert Renesas VMSA-Compatible IOMMU bindings documentation
to json-schema.

Note that original documentation doesn't mention renesas,ipmmu-vmsa
for R-Mobile APE6. But, R-Mobile APE6 is similar to the R-Car
Gen2. So, renesas,ipmmu-r8a73a4 belongs the renesas,ipmmu-vmsa
section.

Signed-off-by: Yoshihiro Shimoda 
---
 Changes from v3:
 - Fix renesas,ipmmu-r8a7795's section
 https://patchwork.kernel.org/patch/11494079/

 Changes from v2:
 - Add a description for R-Mobile APE6 on the commit log.
 - Change renesas,ipmmu-r8a73a4 section on the compatible.
 - Add items on the interrupts.
 - Add power-domains to required.
 - Add oneOf for interrupts and renesas,ipmmu-main
 https://patchwork.kernel.org/patch/11490581/

 Changes from v1:
 - Fix typo in the subject.
 - Add a description on #iommu-cells.
 https://patchwork.kernel.org/patch/11485415/

 .../bindings/iommu/renesas,ipmmu-vmsa.txt  |  73 ---
 .../bindings/iommu/renesas,ipmmu-vmsa.yaml | 101 +
 2 files changed, 101 insertions(+), 73 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
 create mode 100644 
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
deleted file mode 100644
index 020d6f2..
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Renesas VMSA-Compatible IOMMU
-
-The IPMMU is an IOMMU implementation compatible with the ARM VMSA page tables.
-It provides address translation for bus masters outside of the CPU, each
-connected to the IPMMU through a port called micro-TLB.
-
-
-Required Properties:
-
-  - compatible: Must contain SoC-specific and generic entry below in case
-the device is compatible with the R-Car Gen2 VMSA-compatible IPMMU.
-
-- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
-- "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU.
-- "renesas,ipmmu-r8a7744" for the R8A7744 (RZ/G1N) IPMMU.
-- "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU.
-- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU.
-- "renesas,ipmmu-r8a774b1" for the R8A774B1 (RZ/G2N) IPMMU.
-- "renesas,ipmmu-r8a774c0" for the R8A774C0 (RZ/G2E) IPMMU.
-- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
-- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
-- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
-- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
-- "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU.
-- "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU.
-- "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU.
-- "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU.
-- "renesas,ipmmu-r8a77980" for the R8A77980 (R-Car V3H) IPMMU.
-- "renesas,ipmmu-r8a77990" for the R8A77990 (R-Car E3) IPMMU.
-- "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU.
-- "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible
-  IPMMU.
-
-  - reg: Base address and size of the IPMMU registers.
-  - interrupts: Specifiers for the MMU fault interrupts. For instances that
-support secure mode two interrupts must be specified, for non-secure and
-secure mode, in that order. For instances that don't support secure mode a
-single interrupt must be specified. Not required for cache IPMMUs.
-
-  - #iommu-cells: Must be 1.
-
-Optional properties:
-
-  - renesas,ipmmu-main: reference to the main IPMMU instance in two cells.
-The first cell is a phandle to the main IPMMU and the second cell is
-the interrupt bit number associated with the particular cache IPMMU device.
-The interrupt bit number needs to match the main IPMMU IMSSTR register.
-Only used by cache IPMMU instances.
-
-
-Each bus master connected to an IPMMU must reference the IPMMU in its device
-node with the following property:
-
-  - iommus: A reference to the IPMMU in two cells. The first cell is a phandle
-to the IPMMU and the second cell the number of the micro-TLB that the
-device is connected to.
-
-
-Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
-
-   ipmmu_mx: mmu@fe951000 {
-   compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
-   reg = <0 0xfe951000 0 0x1000>;
-   interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-<0 221 IRQ_TYPE_LEVEL_HIGH>;
-   #iommu-cells = <1>;
-   };
-
-   vsp@fe928000 {
-   ...
-   iomm

RE: [PATCH v3] dt-bindings: iommu: renesas,ipmmu-vmsa: convert to json-schema

[Yoshihiro Shimoda]

Hi all,

> From: Yoshihiro Shimoda, Sent: Friday, April 17, 2020 1:35 PM

> +properties:
> +  compatible:
> +oneOf:
> +  - items:
> +  - enum:
> +  - renesas,ipmmu-r8a73a4  # R-Mobile APE6
> +  - renesas,ipmmu-r8a7743  # RZ/G1M
> +  - renesas,ipmmu-r8a7744  # RZ/G1N
> +  - renesas,ipmmu-r8a7745  # RZ/G1E
> +  - renesas,ipmmu-r8a7790  # R-Car H2
> +  - renesas,ipmmu-r8a7791  # R-Car M2-W
> +  - renesas,ipmmu-r8a7793  # R-Car M2-N
> +  - renesas,ipmmu-r8a7794  # R-Car E2
> +  - renesas,ipmmu-r8a7795  # R-Car H3

I'm afraid but this renesas,ipmmu-r8a7795 should be the below section.
So, I'll fix it.

Best regards,
Yoshihiro Shimoda

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

[PATCH v3] dt-bindings: iommu: renesas, ipmmu-vmsa: convert to json-schema

[Yoshihiro Shimoda]

Convert Renesas VMSA-Compatible IOMMU bindings documentation
to json-schema.

Note that original documentation doesn't mention renesas,ipmmu-vmsa
for R-Mobile APE6. But, R-Mobile APE6 is similar to the R-Car
Gen2. So, renesas,ipmmu-r8a73a4 belongs the renesas,ipmmu-vmsa
section.

Signed-off-by: Yoshihiro Shimoda 
---
 Changes from v2:
 - Add a description for R-Mobile APE6 on the commit log.
 - Change renesas,ipmmu-r8a73a4 section on the compatible.
 - Add items on the interrupts.
 - Add power-domains to required.
 - Add oneOf for interrupts and renesas,ipmmu-main
 https://patchwork.kernel.org/patch/11490581/

 Changes from v1:
 - Fix typo in the subject.
 - Add a description on #iommu-cells.
 https://patchwork.kernel.org/patch/11485415/

 .../bindings/iommu/renesas,ipmmu-vmsa.txt  |  73 ---
 .../bindings/iommu/renesas,ipmmu-vmsa.yaml | 101 +
 2 files changed, 101 insertions(+), 73 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
 create mode 100644 
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
deleted file mode 100644
index 020d6f2..
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Renesas VMSA-Compatible IOMMU
-
-The IPMMU is an IOMMU implementation compatible with the ARM VMSA page tables.
-It provides address translation for bus masters outside of the CPU, each
-connected to the IPMMU through a port called micro-TLB.
-
-
-Required Properties:
-
-  - compatible: Must contain SoC-specific and generic entry below in case
-the device is compatible with the R-Car Gen2 VMSA-compatible IPMMU.
-
-- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
-- "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU.
-- "renesas,ipmmu-r8a7744" for the R8A7744 (RZ/G1N) IPMMU.
-- "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU.
-- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU.
-- "renesas,ipmmu-r8a774b1" for the R8A774B1 (RZ/G2N) IPMMU.
-- "renesas,ipmmu-r8a774c0" for the R8A774C0 (RZ/G2E) IPMMU.
-- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
-- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
-- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
-- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
-- "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU.
-- "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU.
-- "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU.
-- "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU.
-- "renesas,ipmmu-r8a77980" for the R8A77980 (R-Car V3H) IPMMU.
-- "renesas,ipmmu-r8a77990" for the R8A77990 (R-Car E3) IPMMU.
-- "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU.
-- "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible
-  IPMMU.
-
-  - reg: Base address and size of the IPMMU registers.
-  - interrupts: Specifiers for the MMU fault interrupts. For instances that
-support secure mode two interrupts must be specified, for non-secure and
-secure mode, in that order. For instances that don't support secure mode a
-single interrupt must be specified. Not required for cache IPMMUs.
-
-  - #iommu-cells: Must be 1.
-
-Optional properties:
-
-  - renesas,ipmmu-main: reference to the main IPMMU instance in two cells.
-The first cell is a phandle to the main IPMMU and the second cell is
-the interrupt bit number associated with the particular cache IPMMU device.
-The interrupt bit number needs to match the main IPMMU IMSSTR register.
-Only used by cache IPMMU instances.
-
-
-Each bus master connected to an IPMMU must reference the IPMMU in its device
-node with the following property:
-
-  - iommus: A reference to the IPMMU in two cells. The first cell is a phandle
-to the IPMMU and the second cell the number of the micro-TLB that the
-device is connected to.
-
-
-Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
-
-   ipmmu_mx: mmu@fe951000 {
-   compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
-   reg = <0 0xfe951000 0 0x1000>;
-   interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-<0 221 IRQ_TYPE_LEVEL_HIGH>;
-   #iommu-cells = <1>;
-   };
-
-   vsp@fe928000 {
-   ...
-   iommus = <_mx 13>;
-   ...
-   };
diff --git a/Documentation/devicetree/bindings/

RE: [PATCH] dt-bndings: iommu: renesas,ipmmu-vmsa: convert to json-schema

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Thursday, April 16, 2020 7:06 PM

> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> 
> > > > +  renesas,ipmmu-main:
> > > > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > > > +description:
> > > > +  Reference to the main IPMMU instance in two cells. The first 
> > > > cell is
> > > > +  a phandle to the main IPMMU and the second cell is the interrupt 
> > > > bit
> > > > +  number associated with the particular cache IPMMU device. The 
> > > > interrupt
> > > > +  bit number needs to match the main IPMMU IMSSTR register. Only 
> > > > used by
> > > > +  cache IPMMU instances.
> > >
> > > This property is not valid only on R-Car Gen2 and R-Mobile APE6.
> >
> > That sounds good. But, since ipmmu_mm on R-Car Gen3 also is not valid,
> > we cannot use compatible property for detecting it.
> 
> What do you mean by "ipmmu_mm is not valid"?

I just wanted to say that ipmmu_mm node on R-Car Gen3 cannot have
this renesas,ipmmu-main property.

> > However, I realized renesas,ipmmu-main is only used by "cache IPMMU"
> > and "cache IPMMU" doesn't have interrupts property. So,
> > I described the following schema and then it seems success.
> > --
> > if:
> >   properties:
> > interrupts: false
> > then:
> >   required:
> > - renesas,ipmmu-main
> 
> But all other nodes should have interrupts properties, right?

Yes, that's right.

> So they are mutually exclusive:
> 
>   oneOf:
>  - required:
>  - interrupts
> - required:
>     - renesas,ipmmu-main

Thank you! Now I understood it and such the schema is better than mine.
I'll fix it.

> > Especially, I could find missing renesas,ipmmu-main property on 
> > r8a77980.dtsi
> > like below :)  So, I'll make and submit a fixing r8a77980.dtsi patch later 
> > (maybe tomorrow).
> 
> Good! ;-)

:)

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH] dt-bndings: iommu: renesas,ipmmu-vmsa: convert to json-schema

[Yoshihiro Shimoda]

Hi Geert-san,

Thank you for your review!

> From: Geert Uytterhoeven, Sent: Wednesday, April 15, 2020 11:21 PM
> 
> Hi Shimoda-san,
> 
> On Tue, Apr 14, 2020 at 2:26 AM Yoshihiro Shimoda
>  wrote:
> > Convert Renesas VMSA-Compatible IOMMU bindings documentation
> > to json-schema.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > @@ -0,0 +1,90 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iommu/renesas,ipmmu-vmsa.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Renesas VMSA-Compatible IOMMU
> > +
> > +maintainers:
> > +  - Yoshihiro Shimoda 
> > +
> > +description:
> > +  The IPMMU is an IOMMU implementation compatible with the ARM VMSA page 
> > tables.
> > +  It provides address translation for bus masters outside of the CPU, each
> > +  connected to the IPMMU through a port called micro-TLB.
> > +
> > +properties:
> > +  compatible:
> > +oneOf:
> > +  - items:
> > +  - enum:
> > +  - renesas,ipmmu-r8a7743  # RZ/G1M
> > +  - renesas,ipmmu-r8a7744  # RZ/G1N
> > +  - renesas,ipmmu-r8a7745  # RZ/G1E
> > +  - renesas,ipmmu-r8a7790  # R-Car H2
> > +  - renesas,ipmmu-r8a7791  # R-Car M2-W
> > +  - renesas,ipmmu-r8a7793  # R-Car M2-N
> > +  - renesas,ipmmu-r8a7794  # R-Car E2
> > +  - renesas,ipmmu-r8a7795  # R-Car H3
> > +  - const: renesas,ipmmu-vmsa  # R-Car Gen2 or RZ/G1
> > +  - items:
> > +  - enum:
> > +  - renesas,ipmmu-r8a73a4  # R-Mobile APE6
> 
> I believe the R-Mobile APE6 IPMMU is similar to the R-Car Gen2 IPMMU,
> and thus belongs in the section above instead.

I think so.
Since the original document doesn't mention about R-Mobile APE6,
I wrote this here. But, I also think R-Mobile APE6 IPMMU is similar to
the R-Car Gen2 IPMMU. So, I'll change renesas,ipmmu-r8a73a4
to the above section and fix comment of renesas,ipmmu-vmsa

> > +  - renesas,ipmmu-r8a774a1 # RZ/G2M
> > +  - renesas,ipmmu-r8a774b1 # RZ/G2N
> > +  - renesas,ipmmu-r8a774c0 # RZ/G2E
> > +  - renesas,ipmmu-r8a7796  # R-Car M3-W
> > +  - renesas,ipmmu-r8a77965 # R-Car M3-N
> > +  - renesas,ipmmu-r8a77970 # R-Car V3M
> > +  - renesas,ipmmu-r8a77980 # R-Car V3H
> > +  - renesas,ipmmu-r8a77990 # R-Car E3
> > +  - renesas,ipmmu-r8a77995 # R-Car D3
> > +
> > +  reg:
> > +maxItems: 1
> > +
> > +  interrupts:
> > +minItems: 1
> > +maxItems: 2
> > +description:
> > +  Specifiers for the MMU fault interrupts. For instances that support
> > +  secure mode two interrupts must be specified, for non-secure and 
> > secure
> > +  mode, in that order. For instances that don't support secure mode a
> > +  single interrupt must be specified. Not required for cache IPMMUs.
> 
> items:
>   - description: 
>   - description: 

I got it. I'll add items.

> > +
> > +  '#iommu-cells':
> > +const: 1
> > +
> > +  power-domains:
> > +maxItems: 1
> > +
> > +  renesas,ipmmu-main:
> > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > +description:
> > +  Reference to the main IPMMU instance in two cells. The first cell is
> > +  a phandle to the main IPMMU and the second cell is the interrupt bit
> > +  number associated with the particular cache IPMMU device. The 
> > interrupt
> > +  bit number needs to match the main IPMMU IMSSTR register. Only used 
> > by
> > +  cache IPMMU instances.
> 
> This property is not valid only on R-Car Gen2 and R-Mobile APE6.

That sounds good. But, since ipmmu_mm on R-Car Gen3 also is not valid,
we cannot use compatible property for detecting it.

However, I realized renesas,ipmmu-main is only used by "cache IPMMU"
and "cache IPMMU" doesn't have interrupts property. So,
I described the following schema and then it seems success.
--
if:
  properties:
interrupts: false
then:
  required:
- renesas,ipmmu-main
--

Especially, I could find missing renesas,ipmmu-main property on r8a77980.dtsi
like below :)  So, I'll make and submit a fixing r8a77980.dtsi patch later 
(maybe tomorrow).

  CHECK   arch/arm64/boot/dts/renesas/r8a77980-condor

[PATCH v2] dt-bindings: iommu: renesas, ipmmu-vmsa: convert to json-schema

[Yoshihiro Shimoda]

Convert Renesas VMSA-Compatible IOMMU bindings documentation
to json-schema.

Signed-off-by: Yoshihiro Shimoda 
---
 Changes from v1:
 - Fix typo in the subject.
 - Add a description on #iommu-cells.
 https://patchwork.kernel.org/patch/11485415/

 .../bindings/iommu/renesas,ipmmu-vmsa.txt  | 73 -
 .../bindings/iommu/renesas,ipmmu-vmsa.yaml | 94 ++
 2 files changed, 94 insertions(+), 73 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
 create mode 100644 
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
deleted file mode 100644
index 020d6f2..
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Renesas VMSA-Compatible IOMMU
-
-The IPMMU is an IOMMU implementation compatible with the ARM VMSA page tables.
-It provides address translation for bus masters outside of the CPU, each
-connected to the IPMMU through a port called micro-TLB.
-
-
-Required Properties:
-
-  - compatible: Must contain SoC-specific and generic entry below in case
-the device is compatible with the R-Car Gen2 VMSA-compatible IPMMU.
-
-- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
-- "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU.
-- "renesas,ipmmu-r8a7744" for the R8A7744 (RZ/G1N) IPMMU.
-- "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU.
-- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU.
-- "renesas,ipmmu-r8a774b1" for the R8A774B1 (RZ/G2N) IPMMU.
-- "renesas,ipmmu-r8a774c0" for the R8A774C0 (RZ/G2E) IPMMU.
-- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
-- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
-- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
-- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
-- "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU.
-- "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU.
-- "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU.
-- "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU.
-- "renesas,ipmmu-r8a77980" for the R8A77980 (R-Car V3H) IPMMU.
-- "renesas,ipmmu-r8a77990" for the R8A77990 (R-Car E3) IPMMU.
-- "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU.
-- "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible
-  IPMMU.
-
-  - reg: Base address and size of the IPMMU registers.
-  - interrupts: Specifiers for the MMU fault interrupts. For instances that
-support secure mode two interrupts must be specified, for non-secure and
-secure mode, in that order. For instances that don't support secure mode a
-single interrupt must be specified. Not required for cache IPMMUs.
-
-  - #iommu-cells: Must be 1.
-
-Optional properties:
-
-  - renesas,ipmmu-main: reference to the main IPMMU instance in two cells.
-The first cell is a phandle to the main IPMMU and the second cell is
-the interrupt bit number associated with the particular cache IPMMU device.
-The interrupt bit number needs to match the main IPMMU IMSSTR register.
-Only used by cache IPMMU instances.
-
-
-Each bus master connected to an IPMMU must reference the IPMMU in its device
-node with the following property:
-
-  - iommus: A reference to the IPMMU in two cells. The first cell is a phandle
-to the IPMMU and the second cell the number of the micro-TLB that the
-device is connected to.
-
-
-Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
-
-   ipmmu_mx: mmu@fe951000 {
-   compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
-   reg = <0 0xfe951000 0 0x1000>;
-   interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-<0 221 IRQ_TYPE_LEVEL_HIGH>;
-   #iommu-cells = <1>;
-   };
-
-   vsp@fe928000 {
-   ...
-   iommus = <_mx 13>;
-   ...
-   };
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
new file mode 100644
index ..2c69f1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/renesas,ipmmu-vmsa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas VMSA-Compatible IOMMU
+
+maintainers:
+  - Yoshihi

RE: [PATCH] dt-bndings: iommu: renesas, ipmmu-vmsa: convert to json-schema

[Yoshihiro Shimoda]

Hi Robin,

> From: Robin Murphy, Sent: Wednesday, April 15, 2020 2:16 AM
> 
> On 2020-04-13 11:25 am, Yoshihiro Shimoda wrote:
> [...]
> > -Each bus master connected to an IPMMU must reference the IPMMU in its 
> > device
> > -node with the following property:
> > -
> > -  - iommus: A reference to the IPMMU in two cells. The first cell is a 
> > phandle
> > -to the IPMMU and the second cell the number of the micro-TLB that the
> > -device is connected to.
> 
> This definition of what the phandle argument means...
> 
> [...]
> > +  '#iommu-cells':
> > +const: 1
>  > +
> 
> ...deserves to be captured in a description here.

Thank you for the comment! I'll fix this.

Best regards,
Yoshihiro Shimoda

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

[PATCH] dt-bndings: iommu: renesas, ipmmu-vmsa: convert to json-schema

[Yoshihiro Shimoda]

Convert Renesas VMSA-Compatible IOMMU bindings documentation
to json-schema.

Signed-off-by: Yoshihiro Shimoda 
---
 .../bindings/iommu/renesas,ipmmu-vmsa.txt  | 73 --
 .../bindings/iommu/renesas,ipmmu-vmsa.yaml | 90 ++
 2 files changed, 90 insertions(+), 73 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
 create mode 100644 
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
deleted file mode 100644
index 020d6f2..
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Renesas VMSA-Compatible IOMMU
-
-The IPMMU is an IOMMU implementation compatible with the ARM VMSA page tables.
-It provides address translation for bus masters outside of the CPU, each
-connected to the IPMMU through a port called micro-TLB.
-
-
-Required Properties:
-
-  - compatible: Must contain SoC-specific and generic entry below in case
-the device is compatible with the R-Car Gen2 VMSA-compatible IPMMU.
-
-- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
-- "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU.
-- "renesas,ipmmu-r8a7744" for the R8A7744 (RZ/G1N) IPMMU.
-- "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU.
-- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU.
-- "renesas,ipmmu-r8a774b1" for the R8A774B1 (RZ/G2N) IPMMU.
-- "renesas,ipmmu-r8a774c0" for the R8A774C0 (RZ/G2E) IPMMU.
-- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
-- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
-- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
-- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
-- "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU.
-- "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU.
-- "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU.
-- "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU.
-- "renesas,ipmmu-r8a77980" for the R8A77980 (R-Car V3H) IPMMU.
-- "renesas,ipmmu-r8a77990" for the R8A77990 (R-Car E3) IPMMU.
-- "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU.
-- "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible
-  IPMMU.
-
-  - reg: Base address and size of the IPMMU registers.
-  - interrupts: Specifiers for the MMU fault interrupts. For instances that
-support secure mode two interrupts must be specified, for non-secure and
-secure mode, in that order. For instances that don't support secure mode a
-single interrupt must be specified. Not required for cache IPMMUs.
-
-  - #iommu-cells: Must be 1.
-
-Optional properties:
-
-  - renesas,ipmmu-main: reference to the main IPMMU instance in two cells.
-The first cell is a phandle to the main IPMMU and the second cell is
-the interrupt bit number associated with the particular cache IPMMU device.
-The interrupt bit number needs to match the main IPMMU IMSSTR register.
-Only used by cache IPMMU instances.
-
-
-Each bus master connected to an IPMMU must reference the IPMMU in its device
-node with the following property:
-
-  - iommus: A reference to the IPMMU in two cells. The first cell is a phandle
-to the IPMMU and the second cell the number of the micro-TLB that the
-device is connected to.
-
-
-Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
-
-   ipmmu_mx: mmu@fe951000 {
-   compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
-   reg = <0 0xfe951000 0 0x1000>;
-   interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-<0 221 IRQ_TYPE_LEVEL_HIGH>;
-   #iommu-cells = <1>;
-   };
-
-   vsp@fe928000 {
-   ...
-   iommus = <_mx 13>;
-   ...
-   };
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
new file mode 100644
index ..3820b10
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/renesas,ipmmu-vmsa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas VMSA-Compatible IOMMU
+
+maintainers:
+  - Yoshihiro Shimoda 
+
+description:
+  The IPMMU is an IOMMU implementation compatible with the ARM VMSA page 
tables.
+  It provides addre

RE: How to fix WARN from drivers/base/dd.c in next-20200401 if CONFIG_MODULES=y?

[Yoshihiro Shimoda]

Hi again,


> I'm guessing we should add the following flush_work for 
> deferred_probe_timeout_work().
> # Sorry, I didn't test this for some reasons yet though...
> 
> +   /* wait for the deferred probe timeout workqueue to finish */
> +   if (driver_deferred_probe_timeout > 0)
> +   flush_work(_probe_timeout_work);

I'm sorry. This code caused build error because the deferred_probe_timeout_work
is struct delayed_work. Also, I don't think using flush_delayed_work() is
my expectation (wait until the timeout of deferred)...

Best regards,
Yoshihiro Shimoda

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

RE: How to fix WARN from drivers/base/dd.c in next-20200401 if CONFIG_MODULES=y?

[Yoshihiro Shimoda]

Hi John, Geert,

> From: John Stultz, Sent: Saturday, April 4, 2020 1:19 PM
> 
> On Fri, Apr 3, 2020 at 4:47 AM Geert Uytterhoeven  
> wrote:
> > On Thu, Apr 2, 2020 at 7:27 PM John Stultz  wrote:
> > > On Thu, Apr 2, 2020 at 3:17 AM Yoshihiro Shimoda
> > >  wrote:
> > > >
> > > > I found an issue after applied the following patches:
> > > > ---
> > > > 64c775f driver core: Rename deferred_probe_timeout and make it global
> > > > 0e9f8d0 driver core: Remove driver_deferred_probe_check_state_continue()
> > > > bec6c0e pinctrl: Remove use of 
> > > > driver_deferred_probe_check_state_continue()
> > > > e2cec7d driver core: Set deferred_probe_timeout to a longer default if 
> > > > CONFIG_MODULES is set
> >
> > Note that just setting deferred_probe_timeout = -1 like for the
> > CONFIG_MODULES=n case doesn't help.
> 
> Yea. I can see why in that case, as we're checking
> !IS_ENABLED(CONFIG_MODULES) directly in
> driver_deferred_probe_check_state.
> 
> I guess we could switch that to checking
> (driver_deferred_probe_timeout == -1) which would have the same logic
> and at least make it consistent if someone specifies -1 on the command
> line (since now it will effectively have it EPROBE_DEFER forever in
> that case). But also having a timeout=infinity could be useful if
> folks don't want the deferring to time out.  Maybe in the !modules
> case setting it to =0 would be the most clear.
> 
> But that's sort of a further cleanup. I'm still more worried about the
> NFS failure below.
> 
> 
> > > Hey,
> > >   Terribly sorry for the trouble. So as Robin mentioned I have a patch
> > > to remove the WARN messages, but I'm a bit more concerned about why
> > > after the 30 second delay, the ethernet driver loads:
> > >   [   36.218666] ravb e680.ethernet eth0: Base address at
> > > 0xe680, 2e:09:0a:02:eb:2d, IRQ 117.
> > > but NFS fails.
> > >
> > > Is it just that the 30 second delay is too long and NFS gives up?
> >
> > I added some debug code to mount_nfs_root(), which shows that the first
> > 3 tries happen before ravb is instantiated, and the last 3 tries happen
> > after.  So NFS root should work, if the network works.
> >
> > However, it seems the Ethernet PHY is never initialized, hence the link
> > never becomes ready.  Dmesg before/after:
> >
> >  ravb e680.ethernet eth0: Base address at 0xe680,
> > 2e:09:0a:02:ea:ff, IRQ 108.
> >
> > Good.
> >
> >  ...
> > -gpio_rcar e6052000.gpio: sense irq = 11, type = 8
> >
> > This is the GPIO the PHY IRQ is connected to.
> > Note that that GPIO controller has been instantiated before.
> >
> >  ...
> > -Micrel KSZ9031 Gigabit PHY e680.ethernet-:00:
> > attached PHY driver [Micrel KSZ9031 Gigabit PHY]
> > (mii_bus:phy_addr=e680.ethernet-:00, irq=197)
> >  ...
> > -ravb e680.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> >
> > Oops.
> >
> > -Sending DHCP requests .., OK
> > -IP-Config: Got DHCP answer from ...
> >  ...
> > +VFS: Unable to mount root fs via NFS, trying floppy.
> > +VFS: Cannot open root device "nfs" or unknown-block(2,0): error -6
> >
> > > Does booting with deferred_probe_timeout=0 work?
> >
> > It does, as now everything using optional links (DMA and IOMMU) is now
> > instantiated on first try.
> 
> Thanks so much for helping clarify this!
> 
> So it's at least good to hear that booting with
> deferred_probe_timeout=0 is working!  But I'm bummed the NFS (or as
> you pointed out in your later mail,  ip_auto_config) falls over
> because the network isn't immediately there.
> 
> Looking a little closer at the ip_auto_config() code, I think the
> issue may be that wait_for_device_probe() is effectively returning too
> early, since the probe_defer_timeout is still active? I need to dig a
> bit more on that code, on Monday, as I don't fully understand it yet.

I think so. I also investigated this issue more and then the following
patch seems to be related because return value is changed a bit.

c8c43ce driver core: Fix driver_deferred_probe_check_state() logic

# By the way, this is other topic though, IIUC we should revise
# the deferred_probe_timeout= in Documentation/admin-guide/kernel-parameters.txt
# for the commit c8c43ce. Especially " A timeout of 0 will timeout at the end 
of initcalls."
# doesn't match after we applied the commit.

I'm guessing we should add the fol

How to fix WARN from drivers/base/dd.c in next-20200401 if CONFIG_MODULES=y?

[Yoshihiro Shimoda]

Hi John,

I found an issue after applied the following patches:
---
64c775f driver core: Rename deferred_probe_timeout and make it global
0e9f8d0 driver core: Remove driver_deferred_probe_check_state_continue()
bec6c0e pinctrl: Remove use of driver_deferred_probe_check_state_continue()
e2cec7d driver core: Set deferred_probe_timeout to a longer default if 
CONFIG_MODULES is set
c8c43ce driver core: Fix driver_deferred_probe_check_state() logic
---

Before these patches, on my environment [1], some device drivers
which has iommus property output the following message when probing:

[3.05] ravb e680.ethernet: ignoring dependency for device, assuming 
no driver
[3.257174] ravb e680.ethernet eth0: Base address at 0xe680, 
2e:09:0a:02:eb:2d, IRQ 117.

So, since ravb driver is probed within 4 seconds, we can use NFS rootfs 
correctly.

However, after these patches are applied, since the patches are always waiting 
for 30 seconds
for of_iommu_configure() when IOMMU hardware is disabled, drivers/base/dd.c 
output WARN.
Also, since ravb cannot be probed for 30 seconds, we cannot use NFS rootfs 
anymore.
JFYI, I copied the kernel log to the end of this email.

I guess the patches will be merged into v5.7-rc1 because the patches are 
contained from
next-20200316, I'd like to fix the issue in v5.7-rcN cycle somehow.

[1]
- R-Car H3 (r8a77951).
- Using defconfig of arch/arm64.
-- So, the IOMMU hardware of the environment is not enabled.

Best regards,
Yoshihiro Shimoda

--- log ---
[0.000162] NOTICE:  BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.21
[0.005735] NOTICE:  BL2: PRR is R-Car H3 Ver.3.0
[0.010412] NOTICE:  BL2: Board is Salvator-XS Rev.1.0
[0.015532] NOTICE:  BL2: Boot device is HyperFlash(160MHz)
[0.021054] NOTICE:  BL2: LCM state is CM
[0.025100] NOTICE:  BL2: AVS setting succeeded. DVFS_SetVID=0x53
[0.031085] NOTICE:  BL2: CH0: 0x4 - 0x48000, 2 GiB
[0.036956] NOTICE:  BL2: CH1: 0x5 - 0x58000, 2 GiB
[0.042840] NOTICE:  BL2: CH2: 0x6 - 0x68000, 2 GiB
[0.048725] NOTICE:  BL2: CH3: 0x7 - 0x78000, 2 GiB
[0.054650] NOTICE:  BL2: DDR3200(rev.0.33)NOTICE:  [COLD_BOOT]NOTICE:  ..0
[0.100344] NOTICE:  BL2: DRAM Split is 4ch(DDR f)
[0.104839] NOTICE:  BL2: QoS is default setting(rev.0.07)
[0.110291] NOTICE:  BL2: DRAM refresh interval 1.95 usec
[0.115720] NOTICE:  BL2: v1.4(release):15dba6b
[0.120156] NOTICE:  BL2: Built : 02:55:27, Sep  4 2018
[0.125352] NOTICE:  BL2: Normal boot
[0.129004] NOTICE:  BL2: dst=0xe6322d00 src=0x818 len=512(0x200)
[0.135395] NOTICE:  BL2: dst=0x43f0 src=0x8180400 len=6144(0x1800)
[0.142003] NOTICE:  BL2: dst=0x4400 src=0x81c len=65536(0x1)
[0.149012] NOTICE:  BL2: dst=0x4410 src=0x820 len=1048576(0x10)
[0.159988] NOTICE:  BL2: dst=0x5000 src=0x864 len=1048576(0x10)


U-Boot 2015.04 (Sep 04 2018 - 10:09:18)

CPU: Renesas Electronics R8A7795 rev 3.0
Board: Salvator-X
I2C:   ready
DRAM:  7.9 GiB
Bank #0: 0x04800 - 0x0bfff, 1.9 GiB
Bank #1: 0x5 - 0x57fff, 2 GiB
Bank #2: 0x6 - 0x67fff, 2 GiB
Bank #3: 0x7 - 0x77fff, 2 GiB

MMC:   sh-sdhi: 0, sh-sdhi: 1, sh-sdhi: 2
In:serial
Out:   serial
Err:   serial
Net:   ravb
Hit any key to stop autoboot:  2 1 0 
ravb Waiting for PHY auto negotiation to complete. done
ravb: 1000Base/Full
Using ravb device
TFTP from server 192.168.10.111; our IP address is 192.168.10.224
Filename 'lava/775/tftp-deploy-8205xjm0/kernel/Image'.
Load address: 0x4808
Loading

[PATCH v3 3/6] iommu/ipmmu-vmsa: Add helper functions for MMU "context" registers

[Yoshihiro Shimoda]

Since we will have changed memory mapping of the IPMMU in the future,
This patch adds helper functions ipmmu_ctx_{reg,read,write}()
for MMU "context" registers. No behavior change.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
---
 drivers/iommu/ipmmu-vmsa.c | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 79975e1..c4fcfda 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -190,29 +190,43 @@ static void ipmmu_write(struct ipmmu_vmsa_device *mmu, 
unsigned int offset,
iowrite32(data, mmu->base + offset);
 }
 
+static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
+ unsigned int context_id, unsigned int reg)
+{
+   return context_id * IM_CTX_SIZE + reg;
+}
+
+static u32 ipmmu_ctx_read(struct ipmmu_vmsa_device *mmu,
+ unsigned int context_id, unsigned int reg)
+{
+   return ipmmu_read(mmu, ipmmu_ctx_reg(mmu, context_id, reg));
+}
+
+static void ipmmu_ctx_write(struct ipmmu_vmsa_device *mmu,
+   unsigned int context_id, unsigned int reg, u32 data)
+{
+   ipmmu_write(mmu, ipmmu_ctx_reg(mmu, context_id, reg), data);
+}
+
 static u32 ipmmu_ctx_read_root(struct ipmmu_vmsa_domain *domain,
   unsigned int reg)
 {
-   return ipmmu_read(domain->mmu->root,
- domain->context_id * IM_CTX_SIZE + reg);
+   return ipmmu_ctx_read(domain->mmu->root, domain->context_id, reg);
 }
 
 static void ipmmu_ctx_write_root(struct ipmmu_vmsa_domain *domain,
 unsigned int reg, u32 data)
 {
-   ipmmu_write(domain->mmu->root,
-   domain->context_id * IM_CTX_SIZE + reg, data);
+   ipmmu_ctx_write(domain->mmu->root, domain->context_id, reg, data);
 }
 
 static void ipmmu_ctx_write_all(struct ipmmu_vmsa_domain *domain,
unsigned int reg, u32 data)
 {
if (domain->mmu != domain->mmu->root)
-   ipmmu_write(domain->mmu,
-   domain->context_id * IM_CTX_SIZE + reg, data);
+   ipmmu_ctx_write(domain->mmu, domain->context_id, reg, data);
 
-   ipmmu_write(domain->mmu->root,
-   domain->context_id * IM_CTX_SIZE + reg, data);
+   ipmmu_ctx_write(domain->mmu->root, domain->context_id, reg, data);
 }
 
 /* 
-
@@ -913,7 +927,7 @@ static void ipmmu_device_reset(struct ipmmu_vmsa_device 
*mmu)
 
/* Disable all contexts. */
for (i = 0; i < mmu->num_ctx; ++i)
-   ipmmu_write(mmu, i * IM_CTX_SIZE + IMCTR, 0);
+   ipmmu_ctx_write(mmu, i, IMCTR, 0);
 }
 
 static const struct ipmmu_features ipmmu_features_default = {
-- 
2.7.4

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

[PATCH v3 4/6] iommu/ipmmu-vmsa: Calculate context registers' offset instead of a macro

[Yoshihiro Shimoda]

Since we will have changed memory mapping of the IPMMU in the future,
this patch uses ipmmu_features values instead of a macro to
calculate context registers offset. No behavior change.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
---
 drivers/iommu/ipmmu-vmsa.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index c4fcfda..8e2ca1c 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -50,6 +50,8 @@ struct ipmmu_features {
bool twobit_imttbcr_sl0;
bool reserved_context;
bool cache_snoop;
+   unsigned int ctx_offset_base;
+   unsigned int ctx_offset_stride;
 };
 
 struct ipmmu_vmsa_device {
@@ -99,8 +101,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device *dev)
 
 #define IM_NS_ALIAS_OFFSET 0x800
 
-#define IM_CTX_SIZE0x40
-
 /* MMU "context" registers */
 #define IMCTR  0x  /* R-Car Gen2/3 */
 #define IMCTR_INTEN(1 << 2)/* R-Car Gen2/3 */
@@ -193,7 +193,8 @@ static void ipmmu_write(struct ipmmu_vmsa_device *mmu, 
unsigned int offset,
 static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
  unsigned int context_id, unsigned int reg)
 {
-   return context_id * IM_CTX_SIZE + reg;
+   return mmu->features->ctx_offset_base +
+  context_id * mmu->features->ctx_offset_stride + reg;
 }
 
 static u32 ipmmu_ctx_read(struct ipmmu_vmsa_device *mmu,
@@ -939,6 +940,8 @@ static const struct ipmmu_features ipmmu_features_default = 
{
.twobit_imttbcr_sl0 = false,
.reserved_context = false,
.cache_snoop = true,
+   .ctx_offset_base = 0,
+   .ctx_offset_stride = 0x40,
 };
 
 static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
@@ -950,6 +953,8 @@ static const struct ipmmu_features ipmmu_features_rcar_gen3 
= {
.twobit_imttbcr_sl0 = true,
.reserved_context = true,
.cache_snoop = false,
+   .ctx_offset_base = 0,
+   .ctx_offset_stride = 0x40,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {
-- 
2.7.4

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

[PATCH v3 2/6] iommu/ipmmu-vmsa: tidyup register definitions

[Yoshihiro Shimoda]

To support different registers memory mapping hardware easily
in the future, this patch tidies up the register definitions
as below:
 - Add comments to state to which SoCs or SoC families they apply
 - Add categories about MMU "context" and uTLB registers

No change behavior.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 58 --
 1 file changed, 30 insertions(+), 28 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index c4ec166..79975e1 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -101,47 +101,49 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 
 #define IM_CTX_SIZE0x40
 
-#define IMCTR  0x
-#define IMCTR_INTEN(1 << 2)
-#define IMCTR_FLUSH(1 << 1)
-#define IMCTR_MMUEN(1 << 0)
-
-#define IMTTBCR0x0008
-#define IMTTBCR_EAE(1 << 31)
+/* MMU "context" registers */
+#define IMCTR  0x  /* R-Car Gen2/3 */
+#define IMCTR_INTEN(1 << 2)/* R-Car Gen2/3 */
+#define IMCTR_FLUSH(1 << 1)/* R-Car Gen2/3 */
+#define IMCTR_MMUEN(1 << 0)/* R-Car Gen2/3 */
+
+#define IMTTBCR0x0008  /* R-Car Gen2/3 
*/
+#define IMTTBCR_EAE(1 << 31)   /* R-Car Gen2/3 */
 #define IMTTBCR_SH0_INNER_SHAREABLE(3 << 12)   /* R-Car Gen2 only */
 #define IMTTBCR_ORGN0_WB_WA(1 << 10)   /* R-Car Gen2 only */
 #define IMTTBCR_IRGN0_WB_WA(1 << 8)/* R-Car Gen2 only */
 #define IMTTBCR_SL0_TWOBIT_LVL_1   (2 << 6)/* R-Car Gen3 only */
-#define IMTTBCR_SL0_LVL_1  (1 << 4)
+#define IMTTBCR_SL0_LVL_1  (1 << 4)/* R-Car Gen2 only */
 
-#define IMBUSCR0x000c
-#define IMBUSCR_DVM(1 << 2)
-#define IMBUSCR_BUSSEL_MASK(3 << 0)
+#define IMBUSCR0x000c  /* R-Car Gen2 
only */
+#define IMBUSCR_DVM(1 << 2)/* R-Car Gen2 only */
+#define IMBUSCR_BUSSEL_MASK(3 << 0)/* R-Car Gen2 only */
 
-#define IMTTLBR0   0x0010
-#define IMTTUBR0   0x0014
+#define IMTTLBR0   0x0010  /* R-Car Gen2/3 */
+#define IMTTUBR0   0x0014  /* R-Car Gen2/3 */
 
-#define IMSTR  0x0020
-#define IMSTR_MHIT (1 << 4)
-#define IMSTR_ABORT(1 << 2)
-#define IMSTR_PF   (1 << 1)
-#define IMSTR_TF   (1 << 0)
+#define IMSTR  0x0020  /* R-Car Gen2/3 */
+#define IMSTR_MHIT (1 << 4)/* R-Car Gen2/3 */
+#define IMSTR_ABORT(1 << 2)/* R-Car Gen2/3 */
+#define IMSTR_PF   (1 << 1)/* R-Car Gen2/3 */
+#define IMSTR_TF   (1 << 0)/* R-Car Gen2/3 */
 
-#define IMMAIR00x0028
+#define IMMAIR00x0028  /* R-Car Gen2/3 
*/
 
-#define IMELAR 0x0030  /* IMEAR on R-Car Gen2 */
-#define IMEUAR 0x0034  /* R-Car Gen3 only */
+#define IMELAR 0x0030  /* R-Car Gen2/3, IMEAR 
on R-Car Gen2 */
+#define IMEUAR 0x0034  /* R-Car Gen3 only */
 
+/* uTLB registers */
 #define IMUCTR(n)  ((n) < 32 ? IMUCTR0(n) : IMUCTR32(n))
-#define IMUCTR0(n) (0x0300 + ((n) * 16))
-#define IMUCTR32(n)(0x0600 + (((n) - 32) * 16))
-#define IMUCTR_TTSEL_MMU(n)((n) << 4)
-#define IMUCTR_FLUSH   (1 << 1)
-#define IMUCTR_MMUEN   (1 << 0)
+#define IMUCTR0(n) (0x0300 + ((n) * 16))   /* 
R-Car Gen2/3 */
+#define IMUCTR32(n)(0x0600 + (((n) - 32) * 16))/* 
R-Car Gen3 only */
+#define IMUCTR_TTSEL_MMU(n)((n) << 4)  /* R-Car Gen2/3 */
+#define IMUCTR_FLUSH   (1 << 1)/* R-Car Gen2/3 */
+#define IMUCTR_MMUEN   (1 << 0)/* R-Car Gen2/3 */
 
 #define IMUASID(n) ((n) < 32 ? IMUASID0(n) : IMUASID32(n))
-#define IMUASID0(n)(0x0308 + ((n) * 16))
-#define IMUASID32(n)   (0x0608 + (((n) - 32) * 16))
+#define IMUASID0(n)(0x0308 + ((n) * 16)) 

[PATCH v3 6/6] iommu/ipmmu-vmsa: Add utlb_offset_base

[Yoshihiro Shimoda]

Since we will have changed memory mapping of the IPMMU in the future,
this patch adds a utlb_offset_base into struct ipmmu_features
for IMUCTR and IMUASID registers. No behavior change.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 82da486..c813436 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -52,6 +52,7 @@ struct ipmmu_features {
bool cache_snoop;
unsigned int ctx_offset_base;
unsigned int ctx_offset_stride;
+   unsigned int utlb_offset_base;
 };
 
 struct ipmmu_vmsa_device {
@@ -232,7 +233,7 @@ static void ipmmu_ctx_write_all(struct ipmmu_vmsa_domain 
*domain,
 
 static u32 ipmmu_utlb_reg(struct ipmmu_vmsa_device *mmu, unsigned int reg)
 {
-   return reg;
+   return mmu->features->utlb_offset_base + reg;
 }
 
 static void ipmmu_imuasid_write(struct ipmmu_vmsa_device *mmu,
@@ -958,6 +959,7 @@ static const struct ipmmu_features ipmmu_features_default = 
{
.cache_snoop = true,
.ctx_offset_base = 0,
.ctx_offset_stride = 0x40,
+   .utlb_offset_base = 0,
 };
 
 static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
@@ -971,6 +973,7 @@ static const struct ipmmu_features ipmmu_features_rcar_gen3 
= {
.cache_snoop = false,
.ctx_offset_base = 0,
.ctx_offset_stride = 0x40,
+   .utlb_offset_base = 0,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {
-- 
2.7.4

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

[PATCH v3 5/6] iommu/ipmmu-vmsa: Add helper functions for "uTLB" registers

[Yoshihiro Shimoda]

Since we will have changed memory mapping of the IPMMU in the future,
This patch adds helper functions ipmmu_utlb_reg() and
ipmmu_imu{asid,ctr}_write() for "uTLB" registers. No behavior change.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
---
 drivers/iommu/ipmmu-vmsa.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 8e2ca1c..82da486 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -230,6 +230,23 @@ static void ipmmu_ctx_write_all(struct ipmmu_vmsa_domain 
*domain,
ipmmu_ctx_write(domain->mmu->root, domain->context_id, reg, data);
 }
 
+static u32 ipmmu_utlb_reg(struct ipmmu_vmsa_device *mmu, unsigned int reg)
+{
+   return reg;
+}
+
+static void ipmmu_imuasid_write(struct ipmmu_vmsa_device *mmu,
+   unsigned int utlb, u32 data)
+{
+   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb)), data);
+}
+
+static void ipmmu_imuctr_write(struct ipmmu_vmsa_device *mmu,
+  unsigned int utlb, u32 data)
+{
+   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUCTR(utlb)), data);
+}
+
 /* 
-
  * TLB and microTLB Management
  */
@@ -275,11 +292,10 @@ static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain 
*domain,
 */
 
/* TODO: What should we set the ASID to ? */
-   ipmmu_write(mmu, IMUASID(utlb), 0);
+   ipmmu_imuasid_write(mmu, utlb, 0);
/* TODO: Do we need to flush the microTLB ? */
-   ipmmu_write(mmu, IMUCTR(utlb),
-   IMUCTR_TTSEL_MMU(domain->context_id) | IMUCTR_FLUSH |
-   IMUCTR_MMUEN);
+   ipmmu_imuctr_write(mmu, utlb, IMUCTR_TTSEL_MMU(domain->context_id) |
+ IMUCTR_FLUSH | IMUCTR_MMUEN);
mmu->utlb_ctx[utlb] = domain->context_id;
 }
 
@@ -291,7 +307,7 @@ static void ipmmu_utlb_disable(struct ipmmu_vmsa_domain 
*domain,
 {
struct ipmmu_vmsa_device *mmu = domain->mmu;
 
-   ipmmu_write(mmu, IMUCTR(utlb), 0);
+   ipmmu_imuctr_write(mmu, utlb, 0);
mmu->utlb_ctx[utlb] = IPMMU_CTX_INVALID;
 }
 
-- 
2.7.4

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

[PATCH v3 0/6] iommu/ipmmu-vmsa: minor updates

[Yoshihiro Shimoda]

This patch series is based on the latest iommu.git / next branch
to modify the driver in the future's new hardware.

Changes from v2:
 - Rebase on the latest iommu.git / next branch.
 - Add Geert-san's Reviewed-by into patch [345]/6.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=187665

Changes from v1:
 - Remove all unused register definitions instead of selective.
   so that I didn't add Geert-san's Reviewed-by in the patch [1/3].
 - To improve code readability, add comments to the register definitions
   and add some helper functions.
 https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=184741

Yoshihiro Shimoda (6):
  iommu/ipmmu-vmsa: Remove all unused register definitions
  iommu/ipmmu-vmsa: tidyup register definitions
  iommu/ipmmu-vmsa: Add helper functions for MMU "context" registers
  iommu/ipmmu-vmsa: Calculate context registers' offset instead of a
macro
  iommu/ipmmu-vmsa: Add helper functions for "uTLB" registers
  iommu/ipmmu-vmsa: Add utlb_offset_base

 drivers/iommu/ipmmu-vmsa.c | 214 +++--
 1 file changed, 89 insertions(+), 125 deletions(-)

-- 
2.7.4

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

[PATCH v3 1/6] iommu/ipmmu-vmsa: Remove all unused register definitions

[Yoshihiro Shimoda]

To support different registers memory mapping hardware easily
in the future, this patch removes all unused register
definitions.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 76 --
 1 file changed, 76 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 5904c23..c4ec166 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -102,122 +102,46 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 #define IM_CTX_SIZE0x40
 
 #define IMCTR  0x
-#define IMCTR_TRE  (1 << 17)
-#define IMCTR_AFE  (1 << 16)
-#define IMCTR_RTSEL_MASK   (3 << 4)
-#define IMCTR_RTSEL_SHIFT  4
-#define IMCTR_TREN (1 << 3)
 #define IMCTR_INTEN(1 << 2)
 #define IMCTR_FLUSH(1 << 1)
 #define IMCTR_MMUEN(1 << 0)
 
-#define IMCAAR 0x0004
-
 #define IMTTBCR0x0008
 #define IMTTBCR_EAE(1 << 31)
-#define IMTTBCR_PMB(1 << 30)
-#define IMTTBCR_SH1_NON_SHAREABLE  (0 << 28)   /* R-Car Gen2 only */
-#define IMTTBCR_SH1_OUTER_SHAREABLE(2 << 28)   /* R-Car Gen2 only */
-#define IMTTBCR_SH1_INNER_SHAREABLE(3 << 28)   /* R-Car Gen2 only */
-#define IMTTBCR_SH1_MASK   (3 << 28)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN1_NC   (0 << 26)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN1_WB_WA(1 << 26)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN1_WT   (2 << 26)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN1_WB   (3 << 26)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN1_MASK (3 << 26)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN1_NC   (0 << 24)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN1_WB_WA(1 << 24)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN1_WT   (2 << 24)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN1_WB   (3 << 24)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN1_MASK (3 << 24)   /* R-Car Gen2 only */
-#define IMTTBCR_TSZ1_MASK  (7 << 16)
-#define IMTTBCR_TSZ1_SHIFT 16
-#define IMTTBCR_SH0_NON_SHAREABLE  (0 << 12)   /* R-Car Gen2 only */
-#define IMTTBCR_SH0_OUTER_SHAREABLE(2 << 12)   /* R-Car Gen2 only */
 #define IMTTBCR_SH0_INNER_SHAREABLE(3 << 12)   /* R-Car Gen2 only */
-#define IMTTBCR_SH0_MASK   (3 << 12)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN0_NC   (0 << 10)   /* R-Car Gen2 only */
 #define IMTTBCR_ORGN0_WB_WA(1 << 10)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN0_WT   (2 << 10)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN0_WB   (3 << 10)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN0_MASK (3 << 10)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN0_NC   (0 << 8)/* R-Car Gen2 only */
 #define IMTTBCR_IRGN0_WB_WA(1 << 8)/* R-Car Gen2 only */
-#define IMTTBCR_IRGN0_WT   (2 << 8)/* R-Car Gen2 only */
-#define IMTTBCR_IRGN0_WB   (3 << 8)/* R-Car Gen2 only */
-#define IMTTBCR_IRGN0_MASK (3 << 8)/* R-Car Gen2 only */
-#define IMTTBCR_SL0_TWOBIT_LVL_3   (0 << 6)/* R-Car Gen3 only */
-#define IMTTBCR_SL0_TWOBIT_LVL_2   (1 << 6)/* R-Car Gen3 only */
 #define IMTTBCR_SL0_TWOBIT_LVL_1   (2 << 6)/* R-Car Gen3 only */
-#define IMTTBCR_SL0_LVL_2  (0 << 4)
 #define IMTTBCR_SL0_LVL_1  (1 << 4)
-#define IMTTBCR_TSZ0_MASK  (7 << 0)
-#define IMTTBCR_TSZ0_SHIFT O
 
 #define IMBUSCR0x000c
 #define IMBUSCR_DVM(1 << 2)
-#define IMBUSCR_BUSSEL_SYS (0 << 0)
-#define IMBUSCR_BUSSEL_CCI (1 << 0)
-#define IMBUSCR_BUSSEL_IMCAAR  (2 << 0)
-#define IMBUSCR_BUSSEL_CCI_IMCAAR  (3 << 0)
 #define IMBUSCR_BUSSEL_MASK(3 << 0)
 
 #define IMTTLBR0   0x0010
 #define IMTTUBR0   0x0014
-#define IMTTLBR1   0x0018
-#define IMTTUBR1   0x001c
 
 #define IMSTR  0x0020
-#define IMSTR_ERRLVL_MASK  (3 << 12)
-#define IMSTR_ERRLVL_SHIFT 12
-#define IMSTR_ERRCODE_TLB_FORMAT   (1 << 8)
-#define IMSTR_ERRCODE_ACCESS

[PATCH v2 1/6] iommu/ipmmu-vmsa: Remove all unused register definitions

[Yoshihiro Shimoda]

To support different registers memory mapping hardware easily
in the future, this patch removes all unused register
definitions.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 76 --
 1 file changed, 76 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 9da8309..89d2a5f 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -102,122 +102,46 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 #define IM_CTX_SIZE0x40
 
 #define IMCTR  0x
-#define IMCTR_TRE  (1 << 17)
-#define IMCTR_AFE  (1 << 16)
-#define IMCTR_RTSEL_MASK   (3 << 4)
-#define IMCTR_RTSEL_SHIFT  4
-#define IMCTR_TREN (1 << 3)
 #define IMCTR_INTEN(1 << 2)
 #define IMCTR_FLUSH(1 << 1)
 #define IMCTR_MMUEN(1 << 0)
 
-#define IMCAAR 0x0004
-
 #define IMTTBCR0x0008
 #define IMTTBCR_EAE(1 << 31)
-#define IMTTBCR_PMB(1 << 30)
-#define IMTTBCR_SH1_NON_SHAREABLE  (0 << 28)   /* R-Car Gen2 only */
-#define IMTTBCR_SH1_OUTER_SHAREABLE(2 << 28)   /* R-Car Gen2 only */
-#define IMTTBCR_SH1_INNER_SHAREABLE(3 << 28)   /* R-Car Gen2 only */
-#define IMTTBCR_SH1_MASK   (3 << 28)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN1_NC   (0 << 26)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN1_WB_WA(1 << 26)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN1_WT   (2 << 26)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN1_WB   (3 << 26)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN1_MASK (3 << 26)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN1_NC   (0 << 24)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN1_WB_WA(1 << 24)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN1_WT   (2 << 24)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN1_WB   (3 << 24)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN1_MASK (3 << 24)   /* R-Car Gen2 only */
-#define IMTTBCR_TSZ1_MASK  (7 << 16)
-#define IMTTBCR_TSZ1_SHIFT 16
-#define IMTTBCR_SH0_NON_SHAREABLE  (0 << 12)   /* R-Car Gen2 only */
-#define IMTTBCR_SH0_OUTER_SHAREABLE(2 << 12)   /* R-Car Gen2 only */
 #define IMTTBCR_SH0_INNER_SHAREABLE(3 << 12)   /* R-Car Gen2 only */
-#define IMTTBCR_SH0_MASK   (3 << 12)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN0_NC   (0 << 10)   /* R-Car Gen2 only */
 #define IMTTBCR_ORGN0_WB_WA(1 << 10)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN0_WT   (2 << 10)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN0_WB   (3 << 10)   /* R-Car Gen2 only */
-#define IMTTBCR_ORGN0_MASK (3 << 10)   /* R-Car Gen2 only */
-#define IMTTBCR_IRGN0_NC   (0 << 8)/* R-Car Gen2 only */
 #define IMTTBCR_IRGN0_WB_WA(1 << 8)/* R-Car Gen2 only */
-#define IMTTBCR_IRGN0_WT   (2 << 8)/* R-Car Gen2 only */
-#define IMTTBCR_IRGN0_WB   (3 << 8)/* R-Car Gen2 only */
-#define IMTTBCR_IRGN0_MASK (3 << 8)/* R-Car Gen2 only */
-#define IMTTBCR_SL0_TWOBIT_LVL_3   (0 << 6)/* R-Car Gen3 only */
-#define IMTTBCR_SL0_TWOBIT_LVL_2   (1 << 6)/* R-Car Gen3 only */
 #define IMTTBCR_SL0_TWOBIT_LVL_1   (2 << 6)/* R-Car Gen3 only */
-#define IMTTBCR_SL0_LVL_2  (0 << 4)
 #define IMTTBCR_SL0_LVL_1  (1 << 4)
-#define IMTTBCR_TSZ0_MASK  (7 << 0)
-#define IMTTBCR_TSZ0_SHIFT O
 
 #define IMBUSCR0x000c
 #define IMBUSCR_DVM(1 << 2)
-#define IMBUSCR_BUSSEL_SYS (0 << 0)
-#define IMBUSCR_BUSSEL_CCI (1 << 0)
-#define IMBUSCR_BUSSEL_IMCAAR  (2 << 0)
-#define IMBUSCR_BUSSEL_CCI_IMCAAR  (3 << 0)
 #define IMBUSCR_BUSSEL_MASK(3 << 0)
 
 #define IMTTLBR0   0x0010
 #define IMTTUBR0   0x0014
-#define IMTTLBR1   0x0018
-#define IMTTUBR1   0x001c
 
 #define IMSTR  0x0020
-#define IMSTR_ERRLVL_MASK  (3 << 12)
-#define IMSTR_ERRLVL_SHIFT 12
-#define IMSTR_ERRCODE_TLB_FORMAT   (1 << 8)
-#define IMSTR_ERRCODE_ACCESS

[PATCH v2 5/6] iommu/ipmmu-vmsa: Add helper functions for "uTLB" registers

[Yoshihiro Shimoda]

Since we will have changed memory mapping of the IPMMU in the future,
This patch adds helper functions ipmmu_utlb_reg() and
ipmmu_imu{asid,ctr}_write() for "uTLB" registers. No behavior change.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 37bb4b7..d8385ef 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -230,6 +230,23 @@ static void ipmmu_ctx_write_all(struct ipmmu_vmsa_domain 
*domain,
ipmmu_ctx_write(domain->mmu->root, domain->context_id, reg, data);
 }
 
+static u32 ipmmu_utlb_reg(struct ipmmu_vmsa_device *mmu, unsigned int reg)
+{
+   return reg;
+}
+
+static void ipmmu_imuasid_write(struct ipmmu_vmsa_device *mmu,
+   unsigned int utlb, u32 data)
+{
+   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb)), data);
+}
+
+static void ipmmu_imuctr_write(struct ipmmu_vmsa_device *mmu,
+  unsigned int utlb, u32 data)
+{
+   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUCTR(utlb)), data);
+}
+
 /* 
-
  * TLB and microTLB Management
  */
@@ -275,11 +292,10 @@ static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain 
*domain,
 */
 
/* TODO: What should we set the ASID to ? */
-   ipmmu_write(mmu, IMUASID(utlb), 0);
+   ipmmu_imuasid_write(mmu, utlb, 0);
/* TODO: Do we need to flush the microTLB ? */
-   ipmmu_write(mmu, IMUCTR(utlb),
-   IMUCTR_TTSEL_MMU(domain->context_id) | IMUCTR_FLUSH |
-   IMUCTR_MMUEN);
+   ipmmu_imuctr_write(mmu, utlb, IMUCTR_TTSEL_MMU(domain->context_id) |
+ IMUCTR_FLUSH | IMUCTR_MMUEN);
mmu->utlb_ctx[utlb] = domain->context_id;
 }
 
@@ -291,7 +307,7 @@ static void ipmmu_utlb_disable(struct ipmmu_vmsa_domain 
*domain,
 {
struct ipmmu_vmsa_device *mmu = domain->mmu;
 
-   ipmmu_write(mmu, IMUCTR(utlb), 0);
+   ipmmu_imuctr_write(mmu, utlb, 0);
mmu->utlb_ctx[utlb] = IPMMU_CTX_INVALID;
 }
 
-- 
2.7.4

[PATCH v2 3/6] iommu/ipmmu-vmsa: Add helper functions for MMU "context" registers

[Yoshihiro Shimoda]

Since we will have changed memory mapping of the IPMMU in the future,
This patch adds helper functions ipmmu_ctx_{reg,read,write}()
for MMU "context" registers. No behavior change.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 35aae24..c60b31d 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -190,29 +190,43 @@ static void ipmmu_write(struct ipmmu_vmsa_device *mmu, 
unsigned int offset,
iowrite32(data, mmu->base + offset);
 }
 
+static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
+ unsigned int context_id, unsigned int reg)
+{
+   return context_id * IM_CTX_SIZE + reg;
+}
+
+static u32 ipmmu_ctx_read(struct ipmmu_vmsa_device *mmu,
+ unsigned int context_id, unsigned int reg)
+{
+   return ipmmu_read(mmu, ipmmu_ctx_reg(mmu, context_id, reg));
+}
+
+static void ipmmu_ctx_write(struct ipmmu_vmsa_device *mmu,
+   unsigned int context_id, unsigned int reg, u32 data)
+{
+   ipmmu_write(mmu, ipmmu_ctx_reg(mmu, context_id, reg), data);
+}
+
 static u32 ipmmu_ctx_read_root(struct ipmmu_vmsa_domain *domain,
   unsigned int reg)
 {
-   return ipmmu_read(domain->mmu->root,
- domain->context_id * IM_CTX_SIZE + reg);
+   return ipmmu_ctx_read(domain->mmu->root, domain->context_id, reg);
 }
 
 static void ipmmu_ctx_write_root(struct ipmmu_vmsa_domain *domain,
 unsigned int reg, u32 data)
 {
-   ipmmu_write(domain->mmu->root,
-   domain->context_id * IM_CTX_SIZE + reg, data);
+   ipmmu_ctx_write(domain->mmu->root, domain->context_id, reg, data);
 }
 
 static void ipmmu_ctx_write_all(struct ipmmu_vmsa_domain *domain,
unsigned int reg, u32 data)
 {
if (domain->mmu != domain->mmu->root)
-   ipmmu_write(domain->mmu,
-   domain->context_id * IM_CTX_SIZE + reg, data);
+   ipmmu_ctx_write(domain->mmu, domain->context_id, reg, data);
 
-   ipmmu_write(domain->mmu->root,
-   domain->context_id * IM_CTX_SIZE + reg, data);
+   ipmmu_ctx_write(domain->mmu->root, domain->context_id, reg, data);
 }
 
 /* 
-
@@ -911,7 +925,7 @@ static void ipmmu_device_reset(struct ipmmu_vmsa_device 
*mmu)
 
/* Disable all contexts. */
for (i = 0; i < mmu->num_ctx; ++i)
-   ipmmu_write(mmu, i * IM_CTX_SIZE + IMCTR, 0);
+   ipmmu_ctx_write(mmu, i, IMCTR, 0);
 }
 
 static const struct ipmmu_features ipmmu_features_default = {
-- 
2.7.4

[PATCH v2 6/6] iommu/ipmmu-vmsa: Add utlb_offset_base

[Yoshihiro Shimoda]

Since we will have changed memory mapping of the IPMMU in the future,
this patch adds a utlb_offset_base into struct ipmmu_features
for IMUCTR and IMUASID registers. No behavior change.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index d8385ef..1225f12 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -52,6 +52,7 @@ struct ipmmu_features {
bool cache_snoop;
unsigned int ctx_offset_base;
unsigned int ctx_offset_stride;
+   unsigned int utlb_offset_base;
 };
 
 struct ipmmu_vmsa_device {
@@ -232,7 +233,7 @@ static void ipmmu_ctx_write_all(struct ipmmu_vmsa_domain 
*domain,
 
 static u32 ipmmu_utlb_reg(struct ipmmu_vmsa_device *mmu, unsigned int reg)
 {
-   return reg;
+   return mmu->features->utlb_offset_base + reg;
 }
 
 static void ipmmu_imuasid_write(struct ipmmu_vmsa_device *mmu,
@@ -956,6 +957,7 @@ static const struct ipmmu_features ipmmu_features_default = 
{
.cache_snoop = true,
.ctx_offset_base = 0,
.ctx_offset_stride = 0x40,
+   .utlb_offset_base = 0,
 };
 
 static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
@@ -969,6 +971,7 @@ static const struct ipmmu_features ipmmu_features_rcar_gen3 
= {
.cache_snoop = false,
.ctx_offset_base = 0,
.ctx_offset_stride = 0x40,
+   .utlb_offset_base = 0,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {
-- 
2.7.4

[PATCH v2 4/6] iommu/ipmmu-vmsa: Calculate context registers' offset instead of a macro

[Yoshihiro Shimoda]

Since we will have changed memory mapping of the IPMMU in the future,
this patch uses ipmmu_features values instead of a macro to
calculate context registers offset. No behavior change.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index c60b31d..37bb4b7 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -50,6 +50,8 @@ struct ipmmu_features {
bool twobit_imttbcr_sl0;
bool reserved_context;
bool cache_snoop;
+   unsigned int ctx_offset_base;
+   unsigned int ctx_offset_stride;
 };
 
 struct ipmmu_vmsa_device {
@@ -99,8 +101,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device *dev)
 
 #define IM_NS_ALIAS_OFFSET 0x800
 
-#define IM_CTX_SIZE0x40
-
 /* MMU "context" registers */
 #define IMCTR  0x  /* R-Car Gen2/3 */
 #define IMCTR_INTEN(1 << 2)/* R-Car Gen2/3 */
@@ -193,7 +193,8 @@ static void ipmmu_write(struct ipmmu_vmsa_device *mmu, 
unsigned int offset,
 static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
  unsigned int context_id, unsigned int reg)
 {
-   return context_id * IM_CTX_SIZE + reg;
+   return mmu->features->ctx_offset_base +
+  context_id * mmu->features->ctx_offset_stride + reg;
 }
 
 static u32 ipmmu_ctx_read(struct ipmmu_vmsa_device *mmu,
@@ -937,6 +938,8 @@ static const struct ipmmu_features ipmmu_features_default = 
{
.twobit_imttbcr_sl0 = false,
.reserved_context = false,
.cache_snoop = true,
+   .ctx_offset_base = 0,
+   .ctx_offset_stride = 0x40,
 };
 
 static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
@@ -948,6 +951,8 @@ static const struct ipmmu_features ipmmu_features_rcar_gen3 
= {
.twobit_imttbcr_sl0 = true,
.reserved_context = true,
.cache_snoop = false,
+   .ctx_offset_base = 0,
+   .ctx_offset_stride = 0x40,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {
-- 
2.7.4

[PATCH v2 0/6] iommu/ipmmu-vmsa: minor updates

[Yoshihiro Shimoda]

This patch series is based on the latest iommu.git / next branch
to modify the driver in the future's new hardware.

Changes from v1:
 - Remove all unused register definitions instead of selective.
   so that I didn't add Geert-san's Reviewed-by in the patch [1/3].
 - To improve code readability, add comments to the register definitions
   and add some helper functions.
 https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=184741

Yoshihiro Shimoda (6):
  iommu/ipmmu-vmsa: Remove all unused register definitions
  iommu/ipmmu-vmsa: tidyup register definitions
  iommu/ipmmu-vmsa: Add helper functions for MMU "context" registers
  iommu/ipmmu-vmsa: Calculate context registers' offset instead of a
macro
  iommu/ipmmu-vmsa: Add helper functions for "uTLB" registers
  iommu/ipmmu-vmsa: Add utlb_offset_base

 drivers/iommu/ipmmu-vmsa.c | 214 +++--
 1 file changed, 89 insertions(+), 125 deletions(-)

-- 
2.7.4

[PATCH v2 2/6] iommu/ipmmu-vmsa: tidyup register definitions

[Yoshihiro Shimoda]

To support different registers memory mapping hardware easily
in the future, this patch tidies up the register definitions
as below:
 - Add comments to state to which SoCs or SoC families they apply
 - Add categories about MMU "context" and uTLB registers

No change behavior.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 58 --
 1 file changed, 30 insertions(+), 28 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 89d2a5f..35aae24 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -101,47 +101,49 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 
 #define IM_CTX_SIZE0x40
 
-#define IMCTR  0x
-#define IMCTR_INTEN(1 << 2)
-#define IMCTR_FLUSH(1 << 1)
-#define IMCTR_MMUEN(1 << 0)
-
-#define IMTTBCR0x0008
-#define IMTTBCR_EAE(1 << 31)
+/* MMU "context" registers */
+#define IMCTR  0x  /* R-Car Gen2/3 */
+#define IMCTR_INTEN(1 << 2)/* R-Car Gen2/3 */
+#define IMCTR_FLUSH(1 << 1)/* R-Car Gen2/3 */
+#define IMCTR_MMUEN(1 << 0)/* R-Car Gen2/3 */
+
+#define IMTTBCR0x0008  /* R-Car Gen2/3 
*/
+#define IMTTBCR_EAE(1 << 31)   /* R-Car Gen2/3 */
 #define IMTTBCR_SH0_INNER_SHAREABLE(3 << 12)   /* R-Car Gen2 only */
 #define IMTTBCR_ORGN0_WB_WA(1 << 10)   /* R-Car Gen2 only */
 #define IMTTBCR_IRGN0_WB_WA(1 << 8)/* R-Car Gen2 only */
 #define IMTTBCR_SL0_TWOBIT_LVL_1   (2 << 6)/* R-Car Gen3 only */
-#define IMTTBCR_SL0_LVL_1  (1 << 4)
+#define IMTTBCR_SL0_LVL_1  (1 << 4)/* R-Car Gen2 only */
 
-#define IMBUSCR0x000c
-#define IMBUSCR_DVM(1 << 2)
-#define IMBUSCR_BUSSEL_MASK(3 << 0)
+#define IMBUSCR0x000c  /* R-Car Gen2 
only */
+#define IMBUSCR_DVM(1 << 2)/* R-Car Gen2 only */
+#define IMBUSCR_BUSSEL_MASK(3 << 0)/* R-Car Gen2 only */
 
-#define IMTTLBR0   0x0010
-#define IMTTUBR0   0x0014
+#define IMTTLBR0   0x0010  /* R-Car Gen2/3 */
+#define IMTTUBR0   0x0014  /* R-Car Gen2/3 */
 
-#define IMSTR  0x0020
-#define IMSTR_MHIT (1 << 4)
-#define IMSTR_ABORT(1 << 2)
-#define IMSTR_PF   (1 << 1)
-#define IMSTR_TF   (1 << 0)
+#define IMSTR  0x0020  /* R-Car Gen2/3 */
+#define IMSTR_MHIT (1 << 4)/* R-Car Gen2/3 */
+#define IMSTR_ABORT(1 << 2)/* R-Car Gen2/3 */
+#define IMSTR_PF   (1 << 1)/* R-Car Gen2/3 */
+#define IMSTR_TF   (1 << 0)/* R-Car Gen2/3 */
 
-#define IMMAIR00x0028
+#define IMMAIR00x0028  /* R-Car Gen2/3 
*/
 
-#define IMELAR 0x0030  /* IMEAR on R-Car Gen2 */
-#define IMEUAR 0x0034  /* R-Car Gen3 only */
+#define IMELAR 0x0030  /* R-Car Gen2/3, IMEAR 
on R-Car Gen2 */
+#define IMEUAR 0x0034  /* R-Car Gen3 only */
 
+/* uTLB registers */
 #define IMUCTR(n)  ((n) < 32 ? IMUCTR0(n) : IMUCTR32(n))
-#define IMUCTR0(n) (0x0300 + ((n) * 16))
-#define IMUCTR32(n)(0x0600 + (((n) - 32) * 16))
-#define IMUCTR_TTSEL_MMU(n)((n) << 4)
-#define IMUCTR_FLUSH   (1 << 1)
-#define IMUCTR_MMUEN   (1 << 0)
+#define IMUCTR0(n) (0x0300 + ((n) * 16))   /* 
R-Car Gen2/3 */
+#define IMUCTR32(n)(0x0600 + (((n) - 32) * 16))/* 
R-Car Gen3 only */
+#define IMUCTR_TTSEL_MMU(n)((n) << 4)  /* R-Car Gen2/3 */
+#define IMUCTR_FLUSH   (1 << 1)/* R-Car Gen2/3 */
+#define IMUCTR_MMUEN   (1 << 0)/* R-Car Gen2/3 */
 
 #define IMUASID(n) ((n) < 32 ? IMUASID0(n) : IMUASID32(n))
-#define IMUASID0(n)(0x0308 + ((n) * 16))
-#define IMUASID32(n)   (0x0608 + (((n) - 32) * 16))
+#define IMUASID0(n)(0x0308 + ((n) * 16)) 

RE: [PATCH 3/3] iommu/ipmmu-vmsa: Add utlb_offset_base

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Friday, October 11, 2019 9:32 PM
> 
> Hi Shimoda-san,
> 
> On Wed, Oct 9, 2019 at 10:27 AM Yoshihiro Shimoda
>  wrote:
> > Since we will have changed memory mapping of the IPMMU in the future,
> > this patch adds a utlb_offset_base into struct ipmmu_features
> > for IMUCTR and IMUASID registers.
> > No behavior change.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Thanks for your patch!
> 
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -52,6 +52,7 @@ struct ipmmu_features {
> > bool cache_snoop;
> > u32 ctx_offset_base;
> > u32 ctx_offset_stride;
> > +   u32 utlb_offset_base;
> >  };
> >
> >  struct ipmmu_vmsa_device {
> > @@ -285,6 +286,11 @@ static void ipmmu_ctx_write_all(struct 
> > ipmmu_vmsa_domain *domain,
> > ipmmu_ctx_write_root(domain, reg, data);
> >  }
> >
> > +static u32 ipmmu_utlb_reg(struct ipmmu_vmsa_device *mmu, unsigned int reg)
> > +{
> > +   return mmu->features->utlb_offset_base + reg;
> > +}
> > +
> >  /* 
> > -
> >   * TLB and microTLB Management
> >   */
> > @@ -330,9 +336,9 @@ static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain 
> > *domain,
> >  */
> >
> > /* TODO: What should we set the ASID to ? */
> > -   ipmmu_write(mmu, IMUASID(utlb), 0);
> > +   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb)), 0);
> > /* TODO: Do we need to flush the microTLB ? */
> > -   ipmmu_write(mmu, IMUCTR(utlb),
> > +   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUCTR(utlb)),
> > IMUCTR_TTSEL_MMU(domain->context_id) | IMUCTR_FLUSH |
> > IMUCTR_MMUEN);
> 
> Like in [PATCH 2/3], I think providing two helpers would make this more
> readable:
> 
> ipmmu_imuasid_write(mmu, utlb, 0);
> ipmmu_imuctr_write(mmu, utlb, data);

I agree. I'll fix it.

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 2/3] iommu/ipmmu-vmsa: Calculate context registers' offset instead of a macro

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Friday, October 11, 2019 9:29 PM
> 
> Hi Shimoda-san,
> 
> On Wed, Oct 9, 2019 at 10:27 AM Yoshihiro Shimoda
>  wrote:
> > Since we will have changed memory mapping of the IPMMU in the future,
> > this patch uses ipmmu_features values instead of a macro to
> > calculate context registers offset. No behavior change.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Thanks for your patch!
> 
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -50,6 +50,8 @@ struct ipmmu_features {
> > bool twobit_imttbcr_sl0;
> > bool reserved_context;
> > bool cache_snoop;
> > +   u32 ctx_offset_base;
> > +   u32 ctx_offset_stride;
> >  };
> >
> >  struct ipmmu_vmsa_device {
> > @@ -99,8 +101,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
> > *dev)
> >
> >  #define IM_NS_ALIAS_OFFSET 0x800
> >
> > -#define IM_CTX_SIZE0x40
> > -
> >  #define IMCTR  0x
> >  #define IMCTR_TRE  (1 << 17)
> >  #define IMCTR_AFE  (1 << 16)
> > @@ -253,18 +253,25 @@ static void ipmmu_write(struct ipmmu_vmsa_device 
> > *mmu, unsigned int offset,
> > iowrite32(data, mmu->base + offset);
> >  }
> >
> > +static u32 ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu, unsigned int 
> > context_id,
> > +unsigned int reg)
> > +{
> > +   return mmu->features->ctx_offset_base +
> > +  context_id * mmu->features->ctx_offset_stride + reg;
> > +}
> > +
> >  static u32 ipmmu_ctx_read_root(struct ipmmu_vmsa_domain *domain,
> >unsigned int reg)
> >  {
> > return ipmmu_read(domain->mmu->root,
> > - domain->context_id * IM_CTX_SIZE + reg);
> > + ipmmu_ctx_reg(domain->mmu, domain->context_id, 
> > reg));
> 
> For consistency:
> 
> ipmmu_ctx_reg(domain->mmu->root, ...)
> 
> but in practice the features for domain->mmu and domain->mmu->root are
> identical anyway.
> 
> >  }
> >
> >  static void ipmmu_ctx_write_root(struct ipmmu_vmsa_domain *domain,
> >  unsigned int reg, u32 data)
> >  {
> > ipmmu_write(domain->mmu->root,
> > -   domain->context_id * IM_CTX_SIZE + reg, data);
> > +   ipmmu_ctx_reg(domain->mmu, domain->context_id, reg), 
> > data);
> 
> Likewise:
> 
> ipmmu_ctx_reg(domain->mmu->root, ...)?

Thank you for the comments! Yes, we can use domain->mmu->root to ipmmu_ctx_reg()
because ipmmu_ctx_reg() only use mmu->features.

> I find these ipmmu_{read,write}() a bit hard too read, with passing the
> mmu to both ipmmu_{read,write}() and ipmmu_ctx_reg().

I completely agree.

> What do you think about providing two helpers ipmmu_ctx_{read,write}(),
> so all users can just use e.g.
> 
> ipmmu_ctx_write(mmu, context_id, reg, data);
> 
> instead of
> 
> ipmmu_write(mmu, ipmmu_ctx_reg(mmu, context_id, reg), data);
> 
> ?

I think so. I'll fix it. Perhaps, I'll make a patch which changes
the function name at first.

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

RE: [PATCH 1/3] iommu/ipmmu-vmsa: Remove some unused register declarations

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Friday, October 11, 2019 9:11 PM
> 
> Hi Shimoda-san,
> 
> Thanks for your patch!
> 
> On Wed, Oct 9, 2019 at 10:27 AM Yoshihiro Shimoda
>  wrote:
> > To support different registers memory mapping hardware easily
> > in the future, this patch removes some unused register
> > declarations.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Reviewed-by: Geert Uytterhoeven 

Thank you for your review!

> While I can confirm the removed definitions are unused, they were
> still valid (but see comments below).
> Perhaps it would be better to add comments, to state clearly to which
> SoCs or SoC families they apply?  Or do you think this would be futile,
> and would add too much clutter to the source file in the near future?

I think adding comments to the declarations are better to avoid
incorrect implementation in the future. So, I'll make such an incremental patch.

> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -104,8 +104,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
> > *dev)
> >  #define IMCTR  0x
> >  #define IMCTR_TRE  (1 << 17)
> >  #define IMCTR_AFE  (1 << 16)
> > -#define IMCTR_RTSEL_MASK   (3 << 4)
> 
> FWIW, this is valid for R-Car Gen2 only.  On R-Car Gen3, the field
> contains 3 bits.

That's correct.

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/3] iommu/ipmmu-vmsa: Calculate context registers' offset instead of a macro

[Yoshihiro Shimoda]

Since we will have changed memory mapping of the IPMMU in the future,
this patch uses ipmmu_features values instead of a macro to
calculate context registers offset. No behavior change.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index dd554c2..76fb250 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -50,6 +50,8 @@ struct ipmmu_features {
bool twobit_imttbcr_sl0;
bool reserved_context;
bool cache_snoop;
+   u32 ctx_offset_base;
+   u32 ctx_offset_stride;
 };
 
 struct ipmmu_vmsa_device {
@@ -99,8 +101,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device *dev)
 
 #define IM_NS_ALIAS_OFFSET 0x800
 
-#define IM_CTX_SIZE0x40
-
 #define IMCTR  0x
 #define IMCTR_TRE  (1 << 17)
 #define IMCTR_AFE  (1 << 16)
@@ -253,18 +253,25 @@ static void ipmmu_write(struct ipmmu_vmsa_device *mmu, 
unsigned int offset,
iowrite32(data, mmu->base + offset);
 }
 
+static u32 ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu, unsigned int 
context_id,
+unsigned int reg)
+{
+   return mmu->features->ctx_offset_base +
+  context_id * mmu->features->ctx_offset_stride + reg;
+}
+
 static u32 ipmmu_ctx_read_root(struct ipmmu_vmsa_domain *domain,
   unsigned int reg)
 {
return ipmmu_read(domain->mmu->root,
- domain->context_id * IM_CTX_SIZE + reg);
+ ipmmu_ctx_reg(domain->mmu, domain->context_id, reg));
 }
 
 static void ipmmu_ctx_write_root(struct ipmmu_vmsa_domain *domain,
 unsigned int reg, u32 data)
 {
ipmmu_write(domain->mmu->root,
-   domain->context_id * IM_CTX_SIZE + reg, data);
+   ipmmu_ctx_reg(domain->mmu, domain->context_id, reg), data);
 }
 
 static void ipmmu_ctx_write_all(struct ipmmu_vmsa_domain *domain,
@@ -272,10 +279,10 @@ static void ipmmu_ctx_write_all(struct ipmmu_vmsa_domain 
*domain,
 {
if (domain->mmu != domain->mmu->root)
ipmmu_write(domain->mmu,
-   domain->context_id * IM_CTX_SIZE + reg, data);
+   ipmmu_ctx_reg(domain->mmu, domain->context_id, reg),
+   data);
 
-   ipmmu_write(domain->mmu->root,
-   domain->context_id * IM_CTX_SIZE + reg, data);
+   ipmmu_ctx_write_root(domain, reg, data);
 }
 
 /* 
-
@@ -974,7 +981,7 @@ static void ipmmu_device_reset(struct ipmmu_vmsa_device 
*mmu)
 
/* Disable all contexts. */
for (i = 0; i < mmu->num_ctx; ++i)
-   ipmmu_write(mmu, i * IM_CTX_SIZE + IMCTR, 0);
+   ipmmu_write(mmu, ipmmu_ctx_reg(mmu, i, IMCTR), 0);
 }
 
 static const struct ipmmu_features ipmmu_features_default = {
@@ -986,6 +993,8 @@ static const struct ipmmu_features ipmmu_features_default = 
{
.twobit_imttbcr_sl0 = false,
.reserved_context = false,
.cache_snoop = true,
+   .ctx_offset_base = 0,
+   .ctx_offset_stride = 0x40,
 };
 
 static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
@@ -997,6 +1006,8 @@ static const struct ipmmu_features 
ipmmu_features_rcar_gen3 = {
.twobit_imttbcr_sl0 = true,
.reserved_context = true,
.cache_snoop = false,
+   .ctx_offset_base = 0,
+   .ctx_offset_stride = 0x40,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {
-- 
2.7.4

[PATCH 1/3] iommu/ipmmu-vmsa: Remove some unused register declarations

[Yoshihiro Shimoda]

To support different registers memory mapping hardware easily
in the future, this patch removes some unused register
declarations.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 9da8309..dd554c2 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -104,8 +104,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 #define IMCTR  0x
 #define IMCTR_TRE  (1 << 17)
 #define IMCTR_AFE  (1 << 16)
-#define IMCTR_RTSEL_MASK   (3 << 4)
-#define IMCTR_RTSEL_SHIFT  4
 #define IMCTR_TREN (1 << 3)
 #define IMCTR_INTEN(1 << 2)
 #define IMCTR_FLUSH(1 << 1)
@@ -115,7 +113,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 
 #define IMTTBCR0x0008
 #define IMTTBCR_EAE(1 << 31)
-#define IMTTBCR_PMB(1 << 30)
 #define IMTTBCR_SH1_NON_SHAREABLE  (0 << 28)   /* R-Car Gen2 only */
 #define IMTTBCR_SH1_OUTER_SHAREABLE(2 << 28)   /* R-Car Gen2 only */
 #define IMTTBCR_SH1_INNER_SHAREABLE(3 << 28)   /* R-Car Gen2 only */
@@ -193,12 +190,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 #define IMELAR 0x0030  /* IMEAR on R-Car Gen2 */
 #define IMEUAR 0x0034  /* R-Car Gen3 only */
 
-#define IMPCTR 0x0200
-#define IMPSTR 0x0208
-#define IMPEAR 0x020c
-#define IMPMBA(n)  (0x0280 + ((n) * 4))
-#define IMPMBD(n)  (0x02c0 + ((n) * 4))
-
 #define IMUCTR(n)  ((n) < 32 ? IMUCTR0(n) : IMUCTR32(n))
 #define IMUCTR0(n) (0x0300 + ((n) * 16))
 #define IMUCTR32(n)(0x0600 + (((n) - 32) * 16))
@@ -206,8 +197,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 #define IMUCTR_FIXADD_MASK (0xff << 16)
 #define IMUCTR_FIXADD_SHIFT16
 #define IMUCTR_TTSEL_MMU(n)((n) << 4)
-#define IMUCTR_TTSEL_PMB   (8 << 4)
-#define IMUCTR_TTSEL_MASK  (15 << 4)
 #define IMUCTR_FLUSH   (1 << 1)
 #define IMUCTR_MMUEN   (1 << 0)
 
-- 
2.7.4

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

[PATCH 3/3] iommu/ipmmu-vmsa: Add utlb_offset_base

[Yoshihiro Shimoda]

Since we will have changed memory mapping of the IPMMU in the future,
this patch adds a utlb_offset_base into struct ipmmu_features
for IMUCTR and IMUASID registers.
No behavior change.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/ipmmu-vmsa.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 76fb250..bc00e58 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -52,6 +52,7 @@ struct ipmmu_features {
bool cache_snoop;
u32 ctx_offset_base;
u32 ctx_offset_stride;
+   u32 utlb_offset_base;
 };
 
 struct ipmmu_vmsa_device {
@@ -285,6 +286,11 @@ static void ipmmu_ctx_write_all(struct ipmmu_vmsa_domain 
*domain,
ipmmu_ctx_write_root(domain, reg, data);
 }
 
+static u32 ipmmu_utlb_reg(struct ipmmu_vmsa_device *mmu, unsigned int reg)
+{
+   return mmu->features->utlb_offset_base + reg;
+}
+
 /* 
-
  * TLB and microTLB Management
  */
@@ -330,9 +336,9 @@ static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain 
*domain,
 */
 
/* TODO: What should we set the ASID to ? */
-   ipmmu_write(mmu, IMUASID(utlb), 0);
+   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb)), 0);
/* TODO: Do we need to flush the microTLB ? */
-   ipmmu_write(mmu, IMUCTR(utlb),
+   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUCTR(utlb)),
IMUCTR_TTSEL_MMU(domain->context_id) | IMUCTR_FLUSH |
IMUCTR_MMUEN);
mmu->utlb_ctx[utlb] = domain->context_id;
@@ -346,7 +352,7 @@ static void ipmmu_utlb_disable(struct ipmmu_vmsa_domain 
*domain,
 {
struct ipmmu_vmsa_device *mmu = domain->mmu;
 
-   ipmmu_write(mmu, IMUCTR(utlb), 0);
+   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUCTR(utlb)), 0);
mmu->utlb_ctx[utlb] = IPMMU_CTX_INVALID;
 }
 
@@ -995,6 +1001,7 @@ static const struct ipmmu_features ipmmu_features_default 
= {
.cache_snoop = true,
.ctx_offset_base = 0,
.ctx_offset_stride = 0x40,
+   .utlb_offset_base = 0,
 };
 
 static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
@@ -1008,6 +1015,7 @@ static const struct ipmmu_features 
ipmmu_features_rcar_gen3 = {
.cache_snoop = false,
.ctx_offset_base = 0,
.ctx_offset_stride = 0x40,
+   .utlb_offset_base = 0,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {
-- 
2.7.4

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

[PATCH 0/3] iommu/ipmmu-vmsa: minor updates

[Yoshihiro Shimoda]

This patch series is based on the latest iommu.git / next branch
to modify the driver in the future's new hardware.

Yoshihiro Shimoda (3):
  iommu/ipmmu-vmsa: Remove some unused register declarations
  iommu/ipmmu-vmsa: Calculate context registers' offset instead of a
macro
  iommu/ipmmu-vmsa: Add utlb_offset_base

 drivers/iommu/ipmmu-vmsa.c | 52 ++
 1 file changed, 30 insertions(+), 22 deletions(-)

-- 
2.7.4

RE: [PATCH] iommu/ipmmu-vmsa: Only call platform_get_irq() when interrupt is mandatory

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Wednesday, October 2, 2019 3:06 AM
> 
> As platform_get_irq() now prints an error when the interrupt does not
> exist, calling it gratuitously causes scary messages like:
> 
> ipmmu-vmsa e674.mmu: IRQ index 0 not found
> 
> Fix this by moving the call to platform_get_irq() down, where the
> existence of the interrupt is mandatory.
> 
> Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to 
> platform_get_irq*()")
> Signed-off-by: Geert Uytterhoeven 
> ---
> This is a fix for v5.4-rc1.
> ---

Thank you for the patch!

Reviewed-by: Yoshihiro Shimoda 

And, I tested this patch on R-Car H3. So,

Tested-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

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

RE: [PATCH v10 3/4] block: add a helper function to merge the segments

[Yoshihiro Shimoda]

Hi Christoph,

> > Now this patch series got {Ack,Review}ed-by from each maintainer.
> > https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=166501
> >
> > So, would you pick this up through the dma-mapping tree as you said before?
> 
> I've applied it to the dma-mapping tree for 5.4 now, thanks a lot!

Thank you very much for your support!

Best regards,
Yoshihiro Shimoda

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

RE: [PATCH v10 3/4] block: add a helper function to merge the segments

[Yoshihiro Shimoda]

Hi Christoph,

Now this patch series got {Ack,Review}ed-by from each maintainer.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=166501

So, would you pick this up through the dma-mapping tree as you said before?

> From: Jens Axboe, Sent: Tuesday, September 3, 2019 6:47 AM
> 
> On 8/28/19 6:35 AM, Yoshihiro Shimoda wrote:
> > This patch adds a helper function whether a queue can merge
> > the segments by the DMA MAP layer (e.g. via IOMMU).
> 
> Reviewed-by: Jens Axboe 

Jens, thank you for your review!

Best regards,
Yoshihiro Shimoda

[PATCH v10 4/4] mmc: queue: Use bigger segments if DMA MAP layer can merge the segments

[Yoshihiro Shimoda]

When the max_segs of a mmc host is smaller than 512, the mmc
subsystem tries to use 512 segments if DMA MAP layer can merge
the segments, and then the mmc subsystem exposes such information
to the block layer by using blk_queue_can_use_dma_map_merging().

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Ulf Hansson 
Reviewed-by: Simon Horman 
---
 drivers/mmc/core/queue.c | 35 ---
 include/linux/mmc/host.h |  1 +
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 7102e2e..1e29b30 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -21,6 +21,8 @@
 #include "card.h"
 #include "host.h"
 
+#define MMC_DMA_MAP_MERGE_SEGMENTS 512
+
 static inline bool mmc_cqe_dcmd_busy(struct mmc_queue *mq)
 {
/* Allow only 1 DCMD at a time */
@@ -193,6 +195,12 @@ static void mmc_queue_setup_discard(struct request_queue 
*q,
blk_queue_flag_set(QUEUE_FLAG_SECERASE, q);
 }
 
+static unsigned int mmc_get_max_segments(struct mmc_host *host)
+{
+   return host->can_dma_map_merge ? MMC_DMA_MAP_MERGE_SEGMENTS :
+host->max_segs;
+}
+
 /**
  * mmc_init_request() - initialize the MMC-specific per-request data
  * @q: the request queue
@@ -206,7 +214,7 @@ static int __mmc_init_request(struct mmc_queue *mq, struct 
request *req,
struct mmc_card *card = mq->card;
struct mmc_host *host = card->host;
 
-   mq_rq->sg = mmc_alloc_sg(host->max_segs, gfp);
+   mq_rq->sg = mmc_alloc_sg(mmc_get_max_segments(host), gfp);
if (!mq_rq->sg)
return -ENOMEM;
 
@@ -362,13 +370,23 @@ static void mmc_setup_queue(struct mmc_queue *mq, struct 
mmc_card *card)
blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);
blk_queue_max_hw_sectors(mq->queue,
min(host->max_blk_count, host->max_req_size / 512));
-   blk_queue_max_segments(mq->queue, host->max_segs);
+   if (host->can_dma_map_merge)
+   WARN(!blk_queue_can_use_dma_map_merging(mq->queue,
+   mmc_dev(host)),
+"merging was advertised but not possible");
+   blk_queue_max_segments(mq->queue, mmc_get_max_segments(host));
 
if (mmc_card_mmc(card))
block_size = card->ext_csd.data_sector_size;
 
blk_queue_logical_block_size(mq->queue, block_size);
-   blk_queue_max_segment_size(mq->queue,
+   /*
+* After blk_queue_can_use_dma_map_merging() was called with succeed,
+* since it calls blk_queue_virt_boundary(), the mmc should not call
+* both blk_queue_max_segment_size().
+*/
+   if (!host->can_dma_map_merge)
+   blk_queue_max_segment_size(mq->queue,
round_down(host->max_seg_size, block_size));
 
dma_set_max_seg_size(mmc_dev(host), queue_max_segment_size(mq->queue));
@@ -418,6 +436,17 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card 
*card)
mq->tag_set.cmd_size = sizeof(struct mmc_queue_req);
mq->tag_set.driver_data = mq;
 
+   /*
+* Since blk_mq_alloc_tag_set() calls .init_request() of mmc_mq_ops,
+* the host->can_dma_map_merge should be set before to get max_segs
+* from mmc_get_max_segments().
+*/
+   if (host->max_segs < MMC_DMA_MAP_MERGE_SEGMENTS &&
+   dma_get_merge_boundary(mmc_dev(host)))
+   host->can_dma_map_merge = 1;
+   else
+   host->can_dma_map_merge = 0;
+
ret = blk_mq_alloc_tag_set(>tag_set);
if (ret)
return ret;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 4a351cb..c5662b3 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -396,6 +396,7 @@ struct mmc_host {
unsigned intretune_paused:1; /* re-tuning is temporarily 
disabled */
unsigned intuse_blk_mq:1;   /* use blk-mq */
unsigned intretune_crc_disable:1; /* don't trigger retune 
upon crc */
+   unsigned intcan_dma_map_merge:1; /* merging can be used */
 
int rescan_disable; /* disable card detection */
int rescan_entered; /* used with nonremovable 
devices */
-- 
2.7.4

[PATCH v10 2/4] iommu/dma: Add a new dma_map_ops of get_merge_boundary()

[Yoshihiro Shimoda]

This patch adds a new dma_map_ops of get_merge_boundary() to
expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
Acked-by: Joerg Roedel 
---
 drivers/iommu/dma-iommu.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index de68b4a..ad861bd 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1091,6 +1091,13 @@ static int iommu_dma_get_sgtable(struct device *dev, 
struct sg_table *sgt,
return ret;
 }
 
+static unsigned long iommu_dma_get_merge_boundary(struct device *dev)
+{
+   struct iommu_domain *domain = iommu_get_dma_domain(dev);
+
+   return (1UL << __ffs(domain->pgsize_bitmap)) - 1;
+}
+
 static const struct dma_map_ops iommu_dma_ops = {
.alloc  = iommu_dma_alloc,
.free   = iommu_dma_free,
@@ -1106,6 +1113,7 @@ static const struct dma_map_ops iommu_dma_ops = {
.sync_sg_for_device = iommu_dma_sync_sg_for_device,
.map_resource   = iommu_dma_map_resource,
.unmap_resource = iommu_dma_unmap_resource,
+   .get_merge_boundary = iommu_dma_get_merge_boundary,
 };
 
 /*
-- 
2.7.4

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

[PATCH v10 1/4] dma: Introduce dma_get_merge_boundary()

[Yoshihiro Shimoda]

This patch adds a new DMA API "dma_get_merge_boundary". This function
returns the DMA merge boundary if the DMA layer can merge the segments.
This patch also adds the implementation for a new dma_map_ops pointer.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Simon Horman 
---
 Documentation/DMA-API.txt   |  8 
 include/linux/dma-mapping.h |  6 ++
 kernel/dma/mapping.c| 11 +++
 3 files changed, 25 insertions(+)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index e47c63b..9c4dd3d 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -204,6 +204,14 @@ Returns the maximum size of a mapping for the device. The 
size parameter
 of the mapping functions like dma_map_single(), dma_map_page() and
 others should not be larger than the returned value.
 
+::
+
+   unsigned long
+   dma_get_merge_boundary(struct device *dev);
+
+Returns the DMA merge boundary. If the device cannot merge any the DMA address
+segments, the function returns 0.
+
 Part Id - Streaming DMA mappings
 
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 14702e2..7072b78 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -131,6 +131,7 @@ struct dma_map_ops {
int (*dma_supported)(struct device *dev, u64 mask);
u64 (*get_required_mask)(struct device *dev);
size_t (*max_mapping_size)(struct device *dev);
+   unsigned long (*get_merge_boundary)(struct device *dev);
 };
 
 #define DMA_MAPPING_ERROR  (~(dma_addr_t)0)
@@ -462,6 +463,7 @@ int dma_set_mask(struct device *dev, u64 mask);
 int dma_set_coherent_mask(struct device *dev, u64 mask);
 u64 dma_get_required_mask(struct device *dev);
 size_t dma_max_mapping_size(struct device *dev);
+unsigned long dma_get_merge_boundary(struct device *dev);
 #else /* CONFIG_HAS_DMA */
 static inline dma_addr_t dma_map_page_attrs(struct device *dev,
struct page *page, size_t offset, size_t size,
@@ -567,6 +569,10 @@ static inline size_t dma_max_mapping_size(struct device 
*dev)
 {
return 0;
 }
+static inline unsigned long dma_get_merge_boundary(struct device *dev)
+{
+   return 0;
+}
 #endif /* CONFIG_HAS_DMA */
 
 static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index b0038ca..b3077b5 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -405,3 +405,14 @@ size_t dma_max_mapping_size(struct device *dev)
return size;
 }
 EXPORT_SYMBOL_GPL(dma_max_mapping_size);
+
+unsigned long dma_get_merge_boundary(struct device *dev)
+{
+   const struct dma_map_ops *ops = get_dma_ops(dev);
+
+   if (!ops || !ops->get_merge_boundary)
+   return 0;   /* can't merge */
+
+   return ops->get_merge_boundary(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_merge_boundary);
-- 
2.7.4

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

[PATCH v10 3/4] block: add a helper function to merge the segments

[Yoshihiro Shimoda]

This patch adds a helper function whether a queue can merge
the segments by the DMA MAP layer (e.g. via IOMMU).

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Simon Horman 
 #include 
 #include 
+#include 
 
 #include "blk.h"
 #include "blk-wbt.h"
@@ -832,6 +833,28 @@ void blk_queue_write_cache(struct request_queue *q, bool 
wc, bool fua)
 }
 EXPORT_SYMBOL_GPL(blk_queue_write_cache);
 
+/**
+ * blk_queue_can_use_dma_map_merging - configure queue for merging segments.
+ * @q: the request queue for the device
+ * @dev:   the device pointer for dma
+ *
+ * Tell the block layer about merging the segments by dma map of @q.
+ */
+bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
+  struct device *dev)
+{
+   unsigned long boundary = dma_get_merge_boundary(dev);
+
+   if (!boundary)
+   return false;
+
+   /* No need to update max_segment_size. see blk_queue_virt_boundary() */
+   blk_queue_virt_boundary(q, boundary);
+
+   return true;
+}
+EXPORT_SYMBOL_GPL(blk_queue_can_use_dma_map_merging);
+
 static int __init blk_settings_init(void)
 {
blk_max_low_pfn = max_low_pfn - 1;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 1ac7901..d62d6e2 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1086,6 +1086,8 @@ extern void blk_queue_dma_alignment(struct request_queue 
*, int);
 extern void blk_queue_update_dma_alignment(struct request_queue *, int);
 extern void blk_queue_rq_timeout(struct request_queue *, unsigned int);
 extern void blk_queue_write_cache(struct request_queue *q, bool enabled, bool 
fua);
+extern bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
+ struct device *dev);
 
 /*
  * Number of physical segments as sent to the device.
-- 
2.7.4

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

[PATCH v10 0/4] treewide: improve R-Car SDHI performance

[Yoshihiro Shimoda]

This patch series is based on linux-next.git / next-20190828 tag.

Since SDHI host internal DMAC of the R-Car Gen3 cannot handle two or
more segments, the performance rate (especially, eMMC HS400 reading)
is not good. However, if IOMMU is enabled on the DMAC, since IOMMU will
map multiple scatter gather buffers as one contignous iova, the DMAC can
handle the iova as well and then the performance rate is possible to
improve. In fact, I have measured the performance by using bonnie++,
"Sequential Input - block" rate was improved on r8a7795.

To achieve this, this patch series modifies IOMMU and Block subsystem
at first. This patch series is strictly depended on each subsystem
modification, so that I submit it as treewide.

Changes from v9:
 - Rebase on next-20190828.
 - Drop a blk-setting.c patch to sort headers.
 - Remove an unnecessary condition on patch 2/4.
 - Add Joerg-san's Reviewed-by into patch 2/4.
 - Fix a condition on patch 4/4 not to call blk_queue_max_segment_size()
   as the comment.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=151067

Changes from v8:
 - Rebase on next-20190726.
 - Use "1UL" instead of just "1" for iommu_dma_get_merge_boundary().
 - Add Simon-san's Reviewed-by into all patches.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=149023

Changes from v7:
 - Rebase on next-20190722 (v5.3-rc1 + next branches of subsystems)
 - Add some Reviewed-by.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=135391

Changes from v6:
 - [1/5 for DMA MAP] A new patch.
 - [2/5 for IOMMU] A new patch.
 - [3/5 for BLOCK] Add Reviewed-by.
 - [4/5 for BLOCK] Use a new DMA MAP API instead of device_iommu_mapped().
 - [5/5 for MMC] Likewise, and some minor fix.
 - Remove patch 4/5 of v6 from this v7 patch series.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=131769

Changes from v5:
 - Almost all patches are new code.
 - [4/5 for MMC] This is a refactor patch so that I don't add any
   {Tested,Reviewed}-by tags.
 - [5/5 for MMC] Modify MMC subsystem to use bigger segments instead of
   the renesas_sdhi driver.
 - [5/5 for MMC] Use BLK_MAX_SEGMENTS (128) instead of local value
   SDHI_MAX_SEGS_IN_IOMMU (512). Even if we use BLK_MAX_SEGMENTS,
   the performance is still good.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=127511

Changes from v4:
 - [DMA MAPPING] Add a new device_dma_parameters for iova contiguous.
 - [IOMMU] Add a new capable for "merging" segments.
 - [IOMMU] Add a capable ops into the ipmmu-vmsa driver.
 - [MMC] Sort headers in renesas_sdhi_core.c.
 - [MMC] Remove the following codes that made on v3 that can be achieved by
 DMA MAPPING and IOMMU subsystem:
 -- Check if R-Car Gen3 IPMMU is used or not on patch 3.
 -- Check if all multiple segment buffers are aligned to PAGE_SIZE on patch 3.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=125593

Changes from v3:
 - Use a helper function device_iommu_mapped on patch 1 and 3.
 - Check if R-Car Gen3 IPMMU is used or not on patch 3.

Yoshihiro Shimoda (4):
  dma: Introduce dma_get_merge_boundary()
  iommu/dma: Add a new dma_map_ops of get_merge_boundary()
  block: add a helper function to merge the segments
  mmc: queue: Use bigger segments if DMA MAP layer can merge the
segments

 Documentation/DMA-API.txt   |  8 
 block/blk-settings.c| 23 +++
 drivers/iommu/dma-iommu.c   |  8 
 drivers/mmc/core/queue.c| 35 ---
 include/linux/blkdev.h  |  2 ++
 include/linux/dma-mapping.h |  6 ++
 include/linux/mmc/host.h|  1 +
 kernel/dma/mapping.c| 11 +++
 8 files changed, 91 insertions(+), 3 deletions(-)

-- 
2.7.4

RE: [PATCH v9 3/5] block: sort headers on blk-setting.c

[Yoshihiro Shimoda]

Hi Jens,

> From: Jens Axboe, Sent: Monday, August 19, 2019 11:54 PM
> 
> On 8/16/19 1:50 PM, Wolfram Sang wrote:
> > On Fri, Jul 26, 2019 at 05:31:14PM +0900, Yoshihiro Shimoda wrote:
> >> This patch sorts the headers in alphabetic order to ease
> >> the maintenance for this part.
> >>
> >> Signed-off-by: Yoshihiro Shimoda 
> >> Reviewed-by: Wolfram Sang 
> >> Reviewed-by: Simon Horman 
> >> ---
> >
> > Jens, can we have your ack for this patch so Christoph can take this
> > series via his tree (also for patch 4/5)?
> 
> Please just drop this patch.

I'm afraid, but would you also review the following patch?
https://marc.info/?l=linux-block=156412995120069=2
This patch 4/5 is a main patch of the block subsystem on this patch series.

Best regards,
Yoshihiro Shimoda

> --
> Jens Axboe

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

RE: [PATCH v9 2/5] iommu/dma: Add a new dma_map_ops of get_merge_boundary()

[Yoshihiro Shimoda]

Hi Robin,

> From: Robin Murphy, Sent: Monday, August 19, 2019 9:55 PM
> 
> On 26/07/2019 09:31, Yoshihiro Shimoda wrote:
> > This patch adds a new dma_map_ops of get_merge_boundary() to
> > expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > Reviewed-by: Simon Horman 
> > ---
> >   drivers/iommu/dma-iommu.c | 11 +++
> >   1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index a7f9c3e..2992ce4 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -1085,6 +1085,16 @@ static int iommu_dma_get_sgtable(struct device *dev, 
> > struct sg_table *sgt,
> > return ret;
> >   }
> >
> > +static unsigned long iommu_dma_get_merge_boundary(struct device *dev)
> > +{
> > +   struct iommu_domain *domain = iommu_get_dma_domain(dev);
> > +
> > +   if (domain->type != IOMMU_DOMAIN_DMA)
> 
> Did you actually need this check? In principle, if the default domain is
> not of type IOMMU_DOMAIN_DMA then the device should be assigned
> dma_direct_ops rather than iommu_dma_ops, thus it shouldn't be possible
> to get here. If you did manage to hit a case where the domain type
> didn't match the ops it would be interesting to figure out how.

Thank you for your review! You're correct. The current dma-iommu.c sets
the iommu_dma_ops to the device dma_ops only when the type is IOMMU_DOMAIN_DMA
like below:
---
if (domain->type == IOMMU_DOMAIN_DMA) {
if (iommu_dma_init_domain(domain, dma_base, size, dev))
goto out_err;
dev->dma_ops = _dma_ops;
    }
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/dma-iommu.c#n1118
---

So, I'll remove this check.

Best regards,
Yoshihiro Shimoda

> Robin.
> 
> > +   return 0;   /* can't merge */
> > +
> > +   return (1UL << __ffs(domain->pgsize_bitmap)) - 1;
> > +}
> > +
> >   static const struct dma_map_ops iommu_dma_ops = {
> > .alloc  = iommu_dma_alloc,
> > .free   = iommu_dma_free,
> > @@ -1100,6 +1110,7 @@ static const struct dma_map_ops iommu_dma_ops = {
> > .sync_sg_for_device = iommu_dma_sync_sg_for_device,
> > .map_resource   = iommu_dma_map_resource,
> > .unmap_resource = iommu_dma_unmap_resource,
> > +   .get_merge_boundary = iommu_dma_get_merge_boundary,
> >   };
> >
> >   /*
> >
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v9 3/5] block: sort headers on blk-setting.c

[Yoshihiro Shimoda]

This patch sorts the headers in alphabetic order to ease
the maintenance for this part.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Wolfram Sang 
Reviewed-by: Simon Horman 
---
 block/blk-settings.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 2ae348c..45f2c52 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -2,16 +2,16 @@
 /*
  * Functions related to setting various queue properties from drivers
  */
-#include 
-#include 
-#include 
 #include 
 #include 
-#include /* for max_pfn/max_low_pfn */
 #include 
-#include 
-#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include  /* for max_pfn/max_low_pfn */
+#include 
 
 #include "blk.h"
 #include "blk-wbt.h"
-- 
2.7.4

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

[PATCH v9 4/5] block: add a helper function to merge the segments

[Yoshihiro Shimoda]

This patch adds a helper function whether a queue can merge
the segments by the DMA MAP layer (e.g. via IOMMU).

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Simon Horman 
---
 block/blk-settings.c   | 22 ++
 include/linux/blkdev.h |  2 ++
 2 files changed, 24 insertions(+)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 45f2c52..6a78ea0 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -4,6 +4,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -831,6 +832,27 @@ void blk_queue_write_cache(struct request_queue *q, bool 
wc, bool fua)
 }
 EXPORT_SYMBOL_GPL(blk_queue_write_cache);
 
+/**
+ * blk_queue_can_use_dma_map_merging - configure queue for merging segments.
+ * @q: the request queue for the device
+ * @dev:   the device pointer for dma
+ *
+ * Tell the block layer about merging the segments by dma map of @q.
+ */
+bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
+  struct device *dev)
+{
+   unsigned long boundary = dma_get_merge_boundary(dev);
+
+   if (!boundary)
+   return false;
+
+   /* No need to update max_segment_size. see blk_queue_virt_boundary() */
+   blk_queue_virt_boundary(q, boundary);
+
+   return true;
+}
+
 static int __init blk_settings_init(void)
 {
blk_max_low_pfn = max_low_pfn - 1;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 1ef375d..f6d55e2 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1085,6 +1085,8 @@ extern void blk_queue_dma_alignment(struct request_queue 
*, int);
 extern void blk_queue_update_dma_alignment(struct request_queue *, int);
 extern void blk_queue_rq_timeout(struct request_queue *, unsigned int);
 extern void blk_queue_write_cache(struct request_queue *q, bool enabled, bool 
fua);
+extern bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
+ struct device *dev);
 
 /*
  * Number of physical segments as sent to the device.
-- 
2.7.4

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

[PATCH v9 1/5] dma: Introduce dma_get_merge_boundary()

[Yoshihiro Shimoda]

This patch adds a new DMA API "dma_get_merge_boundary". This function
returns the DMA merge boundary if the DMA layer can merge the segments.
This patch also adds the implementation for a new dma_map_ops pointer.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Simon Horman 
---
 Documentation/DMA-API.txt   |  8 
 include/linux/dma-mapping.h |  6 ++
 kernel/dma/mapping.c| 11 +++
 3 files changed, 25 insertions(+)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index e47c63b..9c4dd3d 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -204,6 +204,14 @@ Returns the maximum size of a mapping for the device. The 
size parameter
 of the mapping functions like dma_map_single(), dma_map_page() and
 others should not be larger than the returned value.
 
+::
+
+   unsigned long
+   dma_get_merge_boundary(struct device *dev);
+
+Returns the DMA merge boundary. If the device cannot merge any the DMA address
+segments, the function returns 0.
+
 Part Id - Streaming DMA mappings
 
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f7d1eea..260047a 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -131,6 +131,7 @@ struct dma_map_ops {
int (*dma_supported)(struct device *dev, u64 mask);
u64 (*get_required_mask)(struct device *dev);
size_t (*max_mapping_size)(struct device *dev);
+   unsigned long (*get_merge_boundary)(struct device *dev);
 };
 
 #define DMA_MAPPING_ERROR  (~(dma_addr_t)0)
@@ -467,6 +468,7 @@ int dma_set_mask(struct device *dev, u64 mask);
 int dma_set_coherent_mask(struct device *dev, u64 mask);
 u64 dma_get_required_mask(struct device *dev);
 size_t dma_max_mapping_size(struct device *dev);
+unsigned long dma_get_merge_boundary(struct device *dev);
 #else /* CONFIG_HAS_DMA */
 static inline dma_addr_t dma_map_page_attrs(struct device *dev,
struct page *page, size_t offset, size_t size,
@@ -572,6 +574,10 @@ static inline size_t dma_max_mapping_size(struct device 
*dev)
 {
return 0;
 }
+static inline unsigned long dma_get_merge_boundary(struct device *dev)
+{
+   return 0;
+}
 #endif /* CONFIG_HAS_DMA */
 
 static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index b945239..bef0d0a 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -388,3 +388,14 @@ size_t dma_max_mapping_size(struct device *dev)
return size;
 }
 EXPORT_SYMBOL_GPL(dma_max_mapping_size);
+
+unsigned long dma_get_merge_boundary(struct device *dev)
+{
+   const struct dma_map_ops *ops = get_dma_ops(dev);
+
+   if (!ops || !ops->get_merge_boundary)
+   return 0;   /* can't merge */
+
+   return ops->get_merge_boundary(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_merge_boundary);
-- 
2.7.4

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

[PATCH v9 0/5] treewide: improve R-Car SDHI performance

[Yoshihiro Shimoda]

This patch series is based on linux-next.git / next-20190726 tag.

Since SDHI host internal DMAC of the R-Car Gen3 cannot handle two or
more segments, the performance rate (especially, eMMC HS400 reading)
is not good. However, if IOMMU is enabled on the DMAC, since IOMMU will
map multiple scatter gather buffers as one contignous iova, the DMAC can
handle the iova as well and then the performance rate is possible to
improve. In fact, I have measured the performance by using bonnie++,
"Sequential Input - block" rate was improved on r8a7795.

To achieve this, this patch series modifies IOMMU and Block subsystem
at first. This patch series is strictly depended on each subsystem
modification, so that I submit it as treewide.

Changes from v8:
 - Rebase on next-20190726.
 - Use "1UL" instead of just "1" for iommu_dma_get_merge_boundary().
 - Add Simon-san's Reviewed-by into all patches.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=149023

Changes from v7:
 - Rebase on next-20190722 (v5.3-rc1 + next branches of subsystems)
 - Add some Reviewed-by.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=135391

Changes from v6:
 - [1/5 for DMA MAP] A new patch.
 - [2/5 for IOMMU] A new patch.
 - [3/5 for BLOCK] Add Reviewed-by.
 - [4/5 for BLOCK] Use a new DMA MAP API instead of device_iommu_mapped().
 - [5/5 for MMC] Likewise, and some minor fix.
 - Remove patch 4/5 of v6 from this v7 patch series.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=131769

Changes from v5:
 - Almost all patches are new code.
 - [4/5 for MMC] This is a refactor patch so that I don't add any
   {Tested,Reviewed}-by tags.
 - [5/5 for MMC] Modify MMC subsystem to use bigger segments instead of
   the renesas_sdhi driver.
 - [5/5 for MMC] Use BLK_MAX_SEGMENTS (128) instead of local value
   SDHI_MAX_SEGS_IN_IOMMU (512). Even if we use BLK_MAX_SEGMENTS,
   the performance is still good.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=127511

Changes from v4:
 - [DMA MAPPING] Add a new device_dma_parameters for iova contiguous.
 - [IOMMU] Add a new capable for "merging" segments.
 - [IOMMU] Add a capable ops into the ipmmu-vmsa driver.
 - [MMC] Sort headers in renesas_sdhi_core.c.
 - [MMC] Remove the following codes that made on v3 that can be achieved by
 DMA MAPPING and IOMMU subsystem:
 -- Check if R-Car Gen3 IPMMU is used or not on patch 3.
 -- Check if all multiple segment buffers are aligned to PAGE_SIZE on patch 3.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=125593

Changes from v3:
 - Use a helper function device_iommu_mapped on patch 1 and 3.
 - Check if R-Car Gen3 IPMMU is used or not on patch 3.

Yoshihiro Shimoda (5):
  dma: Introduce dma_get_merge_boundary()
  iommu/dma: Add a new dma_map_ops of get_merge_boundary()
  block: sort headers on blk-setting.c
  block: add a helper function to merge the segments
  mmc: queue: Use bigger segments if DMA MAP layer can merge the
segments

 Documentation/DMA-API.txt   |  8 
 block/blk-settings.c| 34 --
 drivers/iommu/dma-iommu.c   | 11 +++
 drivers/mmc/core/queue.c| 35 ---
 include/linux/blkdev.h  |  2 ++
 include/linux/dma-mapping.h |  6 ++
 include/linux/mmc/host.h|  1 +
 kernel/dma/mapping.c| 11 +++
 8 files changed, 99 insertions(+), 9 deletions(-)

-- 
2.7.4

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

[PATCH v9 5/5] mmc: queue: Use bigger segments if DMA MAP layer can merge the segments

[Yoshihiro Shimoda]

When the max_segs of a mmc host is smaller than 512, the mmc
subsystem tries to use 512 segments if DMA MAP layer can merge
the segments, and then the mmc subsystem exposes such information
to the block layer by using blk_queue_can_use_dma_map_merging().

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Ulf Hansson 
Reviewed-by: Simon Horman 
---
 drivers/mmc/core/queue.c | 35 ---
 include/linux/mmc/host.h |  1 +
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 7102e2e..25568dc 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -21,6 +21,8 @@
 #include "card.h"
 #include "host.h"
 
+#define MMC_DMA_MAP_MERGE_SEGMENTS 512
+
 static inline bool mmc_cqe_dcmd_busy(struct mmc_queue *mq)
 {
/* Allow only 1 DCMD at a time */
@@ -193,6 +195,12 @@ static void mmc_queue_setup_discard(struct request_queue 
*q,
blk_queue_flag_set(QUEUE_FLAG_SECERASE, q);
 }
 
+static unsigned int mmc_get_max_segments(struct mmc_host *host)
+{
+   return host->can_dma_map_merge ? MMC_DMA_MAP_MERGE_SEGMENTS :
+host->max_segs;
+}
+
 /**
  * mmc_init_request() - initialize the MMC-specific per-request data
  * @q: the request queue
@@ -206,7 +214,7 @@ static int __mmc_init_request(struct mmc_queue *mq, struct 
request *req,
struct mmc_card *card = mq->card;
struct mmc_host *host = card->host;
 
-   mq_rq->sg = mmc_alloc_sg(host->max_segs, gfp);
+   mq_rq->sg = mmc_alloc_sg(mmc_get_max_segments(host), gfp);
if (!mq_rq->sg)
return -ENOMEM;
 
@@ -362,13 +370,23 @@ static void mmc_setup_queue(struct mmc_queue *mq, struct 
mmc_card *card)
blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);
blk_queue_max_hw_sectors(mq->queue,
min(host->max_blk_count, host->max_req_size / 512));
-   blk_queue_max_segments(mq->queue, host->max_segs);
+   if (host->can_dma_map_merge)
+   WARN(!blk_queue_can_use_dma_map_merging(mq->queue,
+   mmc_dev(host)),
+"merging was advertised but not possible");
+   blk_queue_max_segments(mq->queue, mmc_get_max_segments(host));
 
if (mmc_card_mmc(card))
block_size = card->ext_csd.data_sector_size;
 
blk_queue_logical_block_size(mq->queue, block_size);
-   blk_queue_max_segment_size(mq->queue,
+   /*
+* After blk_queue_can_use_dma_map_merging() was called with succeed,
+* since it calls blk_queue_virt_boundary(), the mmc should not call
+* both blk_queue_max_segment_size().
+*/
+   if (host->can_dma_map_merge)
+   blk_queue_max_segment_size(mq->queue,
round_down(host->max_seg_size, block_size));
 
dma_set_max_seg_size(mmc_dev(host), queue_max_segment_size(mq->queue));
@@ -418,6 +436,17 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card 
*card)
mq->tag_set.cmd_size = sizeof(struct mmc_queue_req);
mq->tag_set.driver_data = mq;
 
+   /*
+* Since blk_mq_alloc_tag_set() calls .init_request() of mmc_mq_ops,
+* the host->can_dma_map_merge should be set before to get max_segs
+* from mmc_get_max_segments().
+*/
+   if (host->max_segs < MMC_DMA_MAP_MERGE_SEGMENTS &&
+   dma_get_merge_boundary(mmc_dev(host)))
+   host->can_dma_map_merge = 1;
+   else
+   host->can_dma_map_merge = 0;
+
ret = blk_mq_alloc_tag_set(>tag_set);
if (ret)
return ret;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 4a351cb..c5662b3 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -396,6 +396,7 @@ struct mmc_host {
unsigned intretune_paused:1; /* re-tuning is temporarily 
disabled */
unsigned intuse_blk_mq:1;   /* use blk-mq */
unsigned intretune_crc_disable:1; /* don't trigger retune 
upon crc */
+   unsigned intcan_dma_map_merge:1; /* merging can be used */
 
int rescan_disable; /* disable card detection */
int rescan_entered; /* used with nonremovable 
devices */
-- 
2.7.4

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

[PATCH v9 2/5] iommu/dma: Add a new dma_map_ops of get_merge_boundary()

[Yoshihiro Shimoda]

This patch adds a new dma_map_ops of get_merge_boundary() to
expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
---
 drivers/iommu/dma-iommu.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index a7f9c3e..2992ce4 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1085,6 +1085,16 @@ static int iommu_dma_get_sgtable(struct device *dev, 
struct sg_table *sgt,
return ret;
 }
 
+static unsigned long iommu_dma_get_merge_boundary(struct device *dev)
+{
+   struct iommu_domain *domain = iommu_get_dma_domain(dev);
+
+   if (domain->type != IOMMU_DOMAIN_DMA)
+   return 0;   /* can't merge */
+
+   return (1UL << __ffs(domain->pgsize_bitmap)) - 1;
+}
+
 static const struct dma_map_ops iommu_dma_ops = {
.alloc  = iommu_dma_alloc,
.free   = iommu_dma_free,
@@ -1100,6 +1110,7 @@ static const struct dma_map_ops iommu_dma_ops = {
.sync_sg_for_device = iommu_dma_sync_sg_for_device,
.map_resource   = iommu_dma_map_resource,
.unmap_resource = iommu_dma_unmap_resource,
+   .get_merge_boundary = iommu_dma_get_merge_boundary,
 };
 
 /*
-- 
2.7.4

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

RE: [PATCH v8 2/5] iommu/dma: Add a new dma_map_ops of get_merge_boundary()

[Yoshihiro Shimoda]

Hello!

> From: Sergei Shtylyov, Sent: Tuesday, July 23, 2019 5:17 PM
> 
> Hello!
> 
> On 23.07.2019 8:26, Yoshihiro Shimoda wrote:
> 
> > This patch adds a new dma_map_ops of get_merge_boundary() to
> > expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >   drivers/iommu/dma-iommu.c | 11 +++
> >   1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index a7f9c3e..f3e5f2b 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -1085,6 +1085,16 @@ static int iommu_dma_get_sgtable(struct device *dev, 
> > struct sg_table *sgt,
> > return ret;
> >   }
> >
> > +static unsigned long iommu_dma_get_merge_boundary(struct device *dev)
> > +{
> > +   struct iommu_domain *domain = iommu_get_dma_domain(dev);
> > +
> > +   if (domain->type != IOMMU_DOMAIN_DMA)
> > +   return 0;   /* can't merge */
> > +
> > +   return (1 << __ffs(domain->pgsize_bitmap)) - 1;
> 
> Not 1UL?

Thank you for your review! I'll fix it.

Best regards,
Yoshihiro Shimoda

> > +}
> > +
> >   static const struct dma_map_ops iommu_dma_ops = {
> > .alloc  = iommu_dma_alloc,
> > .free   = iommu_dma_free,
> [...]
> 
> MBR, Sergei
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v8 5/5] mmc: queue: Use bigger segments if DMA MAP layer can merge the segments

[Yoshihiro Shimoda]

When the max_segs of a mmc host is smaller than 512, the mmc
subsystem tries to use 512 segments if DMA MAP layer can merge
the segments, and then the mmc subsystem exposes such information
to the block layer by using blk_queue_can_use_dma_map_merging().

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Ulf Hansson 
---
 drivers/mmc/core/queue.c | 35 ---
 include/linux/mmc/host.h |  1 +
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index e327f80..ce337b2 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -20,6 +20,8 @@
 #include "card.h"
 #include "host.h"
 
+#define MMC_DMA_MAP_MERGE_SEGMENTS 512
+
 static inline bool mmc_cqe_dcmd_busy(struct mmc_queue *mq)
 {
/* Allow only 1 DCMD at a time */
@@ -192,6 +194,12 @@ static void mmc_queue_setup_discard(struct request_queue 
*q,
blk_queue_flag_set(QUEUE_FLAG_SECERASE, q);
 }
 
+static unsigned int mmc_get_max_segments(struct mmc_host *host)
+{
+   return host->can_dma_map_merge ? MMC_DMA_MAP_MERGE_SEGMENTS :
+host->max_segs;
+}
+
 /**
  * mmc_init_request() - initialize the MMC-specific per-request data
  * @q: the request queue
@@ -205,7 +213,7 @@ static int __mmc_init_request(struct mmc_queue *mq, struct 
request *req,
struct mmc_card *card = mq->card;
struct mmc_host *host = card->host;
 
-   mq_rq->sg = mmc_alloc_sg(host->max_segs, gfp);
+   mq_rq->sg = mmc_alloc_sg(mmc_get_max_segments(host), gfp);
if (!mq_rq->sg)
return -ENOMEM;
 
@@ -361,13 +369,23 @@ static void mmc_setup_queue(struct mmc_queue *mq, struct 
mmc_card *card)
blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);
blk_queue_max_hw_sectors(mq->queue,
min(host->max_blk_count, host->max_req_size / 512));
-   blk_queue_max_segments(mq->queue, host->max_segs);
+   if (host->can_dma_map_merge)
+   WARN(!blk_queue_can_use_dma_map_merging(mq->queue,
+   mmc_dev(host)),
+"merging was advertised but not possible");
+   blk_queue_max_segments(mq->queue, mmc_get_max_segments(host));
 
if (mmc_card_mmc(card))
block_size = card->ext_csd.data_sector_size;
 
blk_queue_logical_block_size(mq->queue, block_size);
-   blk_queue_max_segment_size(mq->queue,
+   /*
+* After blk_queue_can_use_dma_map_merging() was called with succeed,
+* since it calls blk_queue_virt_boundary(), the mmc should not call
+* both blk_queue_max_segment_size().
+*/
+   if (host->can_dma_map_merge)
+   blk_queue_max_segment_size(mq->queue,
round_down(host->max_seg_size, block_size));
 
dma_set_max_seg_size(mmc_dev(host), queue_max_segment_size(mq->queue));
@@ -417,6 +435,17 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card 
*card)
mq->tag_set.cmd_size = sizeof(struct mmc_queue_req);
mq->tag_set.driver_data = mq;
 
+   /*
+* Since blk_mq_alloc_tag_set() calls .init_request() of mmc_mq_ops,
+* the host->can_dma_map_merge should be set before to get max_segs
+* from mmc_get_max_segments().
+*/
+   if (host->max_segs < MMC_DMA_MAP_MERGE_SEGMENTS &&
+   dma_get_merge_boundary(mmc_dev(host)))
+   host->can_dma_map_merge = 1;
+   else
+   host->can_dma_map_merge = 0;
+
ret = blk_mq_alloc_tag_set(>tag_set);
if (ret)
return ret;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 4a351cb..c5662b3 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -396,6 +396,7 @@ struct mmc_host {
unsigned intretune_paused:1; /* re-tuning is temporarily 
disabled */
unsigned intuse_blk_mq:1;   /* use blk-mq */
unsigned intretune_crc_disable:1; /* don't trigger retune 
upon crc */
+   unsigned intcan_dma_map_merge:1; /* merging can be used */
 
int rescan_disable; /* disable card detection */
int rescan_entered; /* used with nonremovable 
devices */
-- 
2.7.4

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

[PATCH v8 3/5] block: sort headers on blk-setting.c

[Yoshihiro Shimoda]

This patch sorts the headers in alphabetic order to ease
the maintenance for this part.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Wolfram Sang 
---
 block/blk-settings.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 2ae348c..45f2c52 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -2,16 +2,16 @@
 /*
  * Functions related to setting various queue properties from drivers
  */
-#include 
-#include 
-#include 
 #include 
 #include 
-#include /* for max_pfn/max_low_pfn */
 #include 
-#include 
-#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include  /* for max_pfn/max_low_pfn */
+#include 
 
 #include "blk.h"
 #include "blk-wbt.h"
-- 
2.7.4

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

[PATCH v8 0/5] treewide: improve R-Car SDHI performance

[Yoshihiro Shimoda]

This patch series is based on linux-next.git / next-20190722 tag.

Since SDHI host internal DMAC of the R-Car Gen3 cannot handle two or
more segments, the performance rate (especially, eMMC HS400 reading)
is not good. However, if IOMMU is enabled on the DMAC, since IOMMU will
map multiple scatter gather buffers as one contignous iova, the DMAC can
handle the iova as well and then the performance rate is possible to
improve. In fact, I have measured the performance by using bonnie++,
"Sequential Input - block" rate was improved on r8a7795.

To achieve this, this patch series modifies IOMMU and Block subsystem
at first. This patch series is strictly depended on each subsystem
modification, so that I submit it as treewide.

Changes from v7:
 - Rebase on next-20190722 (v5.3-rc1 + next branches of subsystems)
 - Add some Reviewed-by.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=135391

Changes from v6:
 - [1/5 for DMA MAP] A new patch.
 - [2/5 for IOMMU] A new patch.
 - [3/5 for BLOCK] Add Reviewed-by.
 - [4/5 for BLOCK] Use a new DMA MAP API instead of device_iommu_mapped().
 - [5/5 for MMC] Likewise, and some minor fix.
 - Remove patch 4/5 of v6 from this v7 patch series.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=131769

Changes from v5:
 - Almost all patches are new code.
 - [4/5 for MMC] This is a refactor patch so that I don't add any
   {Tested,Reviewed}-by tags.
 - [5/5 for MMC] Modify MMC subsystem to use bigger segments instead of
   the renesas_sdhi driver.
 - [5/5 for MMC] Use BLK_MAX_SEGMENTS (128) instead of local value
   SDHI_MAX_SEGS_IN_IOMMU (512). Even if we use BLK_MAX_SEGMENTS,
   the performance is still good.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=127511

Changes from v4:
 - [DMA MAPPING] Add a new device_dma_parameters for iova contiguous.
 - [IOMMU] Add a new capable for "merging" segments.
 - [IOMMU] Add a capable ops into the ipmmu-vmsa driver.
 - [MMC] Sort headers in renesas_sdhi_core.c.
 - [MMC] Remove the following codes that made on v3 that can be achieved by
 DMA MAPPING and IOMMU subsystem:
 -- Check if R-Car Gen3 IPMMU is used or not on patch 3.
 -- Check if all multiple segment buffers are aligned to PAGE_SIZE on patch 3.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=125593

Changes from v3:
 - Use a helper function device_iommu_mapped on patch 1 and 3.
 - Check if R-Car Gen3 IPMMU is used or not on patch 3.

Yoshihiro Shimoda (5):
  dma: Introduce dma_get_merge_boundary()
  iommu/dma: Add a new dma_map_ops of get_merge_boundary()
  block: sort headers on blk-setting.c
  block: add a helper function to merge the segments
  mmc: queue: Use bigger segments if DMA MAP layer can merge the
segments

 Documentation/DMA-API.txt   |  8 
 block/blk-settings.c| 34 --
 drivers/iommu/dma-iommu.c   | 11 +++
 drivers/mmc/core/queue.c| 35 ---
 include/linux/blkdev.h  |  2 ++
 include/linux/dma-mapping.h |  6 ++
 include/linux/mmc/host.h|  1 +
 kernel/dma/mapping.c| 11 +++
 8 files changed, 99 insertions(+), 9 deletions(-)

-- 
2.7.4

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

[PATCH v8 1/5] dma: Introduce dma_get_merge_boundary()

[Yoshihiro Shimoda]

This patch adds a new DMA API "dma_get_merge_boundary". This function
returns the DMA merge boundary if the DMA layer can merge the segments.
This patch also adds the implementation for a new dma_map_ops pointer.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Christoph Hellwig 
---
 Documentation/DMA-API.txt   |  8 
 include/linux/dma-mapping.h |  6 ++
 kernel/dma/mapping.c| 11 +++
 3 files changed, 25 insertions(+)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index e47c63b..9c4dd3d 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -204,6 +204,14 @@ Returns the maximum size of a mapping for the device. The 
size parameter
 of the mapping functions like dma_map_single(), dma_map_page() and
 others should not be larger than the returned value.
 
+::
+
+   unsigned long
+   dma_get_merge_boundary(struct device *dev);
+
+Returns the DMA merge boundary. If the device cannot merge any the DMA address
+segments, the function returns 0.
+
 Part Id - Streaming DMA mappings
 
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index e11b115..f700f8a 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -131,6 +131,7 @@ struct dma_map_ops {
int (*dma_supported)(struct device *dev, u64 mask);
u64 (*get_required_mask)(struct device *dev);
size_t (*max_mapping_size)(struct device *dev);
+   unsigned long (*get_merge_boundary)(struct device *dev);
 };
 
 #define DMA_MAPPING_ERROR  (~(dma_addr_t)0)
@@ -467,6 +468,7 @@ int dma_set_mask(struct device *dev, u64 mask);
 int dma_set_coherent_mask(struct device *dev, u64 mask);
 u64 dma_get_required_mask(struct device *dev);
 size_t dma_max_mapping_size(struct device *dev);
+unsigned long dma_get_merge_boundary(struct device *dev);
 #else /* CONFIG_HAS_DMA */
 static inline dma_addr_t dma_map_page_attrs(struct device *dev,
struct page *page, size_t offset, size_t size,
@@ -572,6 +574,10 @@ static inline size_t dma_max_mapping_size(struct device 
*dev)
 {
return 0;
 }
+static inline unsigned long dma_get_merge_boundary(struct device *dev)
+{
+   return 0;
+}
 #endif /* CONFIG_HAS_DMA */
 
 static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 1f628e7..e8da02e 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -379,3 +379,14 @@ size_t dma_max_mapping_size(struct device *dev)
return size;
 }
 EXPORT_SYMBOL_GPL(dma_max_mapping_size);
+
+unsigned long dma_get_merge_boundary(struct device *dev)
+{
+   const struct dma_map_ops *ops = get_dma_ops(dev);
+
+   if (!ops || !ops->get_merge_boundary)
+   return 0;   /* can't merge */
+
+   return ops->get_merge_boundary(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_merge_boundary);
-- 
2.7.4

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

[PATCH v8 4/5] block: add a helper function to merge the segments

[Yoshihiro Shimoda]

This patch adds a helper function whether a queue can merge
the segments by the DMA MAP layer (e.g. via IOMMU).

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Christoph Hellwig 
---
 block/blk-settings.c   | 22 ++
 include/linux/blkdev.h |  2 ++
 2 files changed, 24 insertions(+)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 45f2c52..6a78ea0 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -4,6 +4,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -831,6 +832,27 @@ void blk_queue_write_cache(struct request_queue *q, bool 
wc, bool fua)
 }
 EXPORT_SYMBOL_GPL(blk_queue_write_cache);
 
+/**
+ * blk_queue_can_use_dma_map_merging - configure queue for merging segments.
+ * @q: the request queue for the device
+ * @dev:   the device pointer for dma
+ *
+ * Tell the block layer about merging the segments by dma map of @q.
+ */
+bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
+  struct device *dev)
+{
+   unsigned long boundary = dma_get_merge_boundary(dev);
+
+   if (!boundary)
+   return false;
+
+   /* No need to update max_segment_size. see blk_queue_virt_boundary() */
+   blk_queue_virt_boundary(q, boundary);
+
+   return true;
+}
+
 static int __init blk_settings_init(void)
 {
blk_max_low_pfn = max_low_pfn - 1;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 1ef375d..f6d55e2 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1085,6 +1085,8 @@ extern void blk_queue_dma_alignment(struct request_queue 
*, int);
 extern void blk_queue_update_dma_alignment(struct request_queue *, int);
 extern void blk_queue_rq_timeout(struct request_queue *, unsigned int);
 extern void blk_queue_write_cache(struct request_queue *q, bool enabled, bool 
fua);
+extern bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
+ struct device *dev);
 
 /*
  * Number of physical segments as sent to the device.
-- 
2.7.4

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

[PATCH v8 2/5] iommu/dma: Add a new dma_map_ops of get_merge_boundary()

[Yoshihiro Shimoda]

This patch adds a new dma_map_ops of get_merge_boundary() to
expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/iommu/dma-iommu.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index a7f9c3e..f3e5f2b 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1085,6 +1085,16 @@ static int iommu_dma_get_sgtable(struct device *dev, 
struct sg_table *sgt,
return ret;
 }
 
+static unsigned long iommu_dma_get_merge_boundary(struct device *dev)
+{
+   struct iommu_domain *domain = iommu_get_dma_domain(dev);
+
+   if (domain->type != IOMMU_DOMAIN_DMA)
+   return 0;   /* can't merge */
+
+   return (1 << __ffs(domain->pgsize_bitmap)) - 1;
+}
+
 static const struct dma_map_ops iommu_dma_ops = {
.alloc  = iommu_dma_alloc,
.free   = iommu_dma_free,
@@ -1100,6 +1110,7 @@ static const struct dma_map_ops iommu_dma_ops = {
.sync_sg_for_device = iommu_dma_sync_sg_for_device,
.map_resource   = iommu_dma_map_resource,
.unmap_resource = iommu_dma_unmap_resource,
+   .get_merge_boundary = iommu_dma_get_merge_boundary,
 };
 
 /*
-- 
2.7.4

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

[RFC PATCH v7 4/5] block: add a helper function to merge the segments

[Yoshihiro Shimoda]

This patch adds a helper function whether a queue can merge
the segments by the DMA MAP layer (e.g. via IOMMU).

Signed-off-by: Yoshihiro Shimoda 
---
 block/blk-settings.c   | 22 ++
 include/linux/blkdev.h |  2 ++
 2 files changed, 24 insertions(+)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 45f2c52..6a78ea0 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -4,6 +4,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -831,6 +832,27 @@ void blk_queue_write_cache(struct request_queue *q, bool 
wc, bool fua)
 }
 EXPORT_SYMBOL_GPL(blk_queue_write_cache);
 
+/**
+ * blk_queue_can_use_dma_map_merging - configure queue for merging segments.
+ * @q: the request queue for the device
+ * @dev:   the device pointer for dma
+ *
+ * Tell the block layer about merging the segments by dma map of @q.
+ */
+bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
+  struct device *dev)
+{
+   unsigned long boundary = dma_get_merge_boundary(dev);
+
+   if (!boundary)
+   return false;
+
+   /* No need to update max_segment_size. see blk_queue_virt_boundary() */
+   blk_queue_virt_boundary(q, boundary);
+
+   return true;
+}
+
 static int __init blk_settings_init(void)
 {
blk_max_low_pfn = max_low_pfn - 1;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 592669b..a7a839d 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1091,6 +1091,8 @@ extern void blk_queue_dma_alignment(struct request_queue 
*, int);
 extern void blk_queue_update_dma_alignment(struct request_queue *, int);
 extern void blk_queue_rq_timeout(struct request_queue *, unsigned int);
 extern void blk_queue_write_cache(struct request_queue *q, bool enabled, bool 
fua);
+extern bool blk_queue_can_use_dma_map_merging(struct request_queue *q,
+ struct device *dev);
 
 /*
  * Number of physical segments as sent to the device.
-- 
2.7.4

[RFC PATCH v7 0/5] treewide: improve R-Car SDHI performance

[Yoshihiro Shimoda]

This patch series is based on iommu.git / next branch.

Since SDHI host internal DMAC of the R-Car Gen3 cannot handle two or
more segments, the performance rate (especially, eMMC HS400 reading)
is not good. However, if IOMMU is enabled on the DMAC, since IOMMU will
map multiple scatter gather buffers as one contignous iova, the DMAC can
handle the iova as well and then the performance rate is possible to
improve. In fact, I have measured the performance by using bonnie++,
"Sequential Input - block" rate was improved on r8a7795.

To achieve this, this patch series modifies IOMMU and Block subsystem
at first. Since I'd like to get any feedback from each subsystem whether
this way is acceptable for upstream, I submit it to treewide with RFC.

Changes from v6:
 - [1/5 for DMA MAP] A new patch.
 - [2/5 for IOMMU] A new patch.
 - [3/5 for BLOCK] Add Reviewed-by.
 - [4/5 for BLOCK] Use a new DMA MAP API instead of device_iommu_mapped().
 - [5/5 for MMC] Likewise, and some minor fix.
 - Remove patch 4/5 of v6 from this v7 patch series.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=131769

Changes from v5:
 - Almost all patches are new code.
 - [4/5 for MMC] This is a refactor patch so that I don't add any
   {Tested,Reviewed}-by tags.
 - [5/5 for MMC] Modify MMC subsystem to use bigger segments instead of
   the renesas_sdhi driver.
 - [5/5 for MMC] Use BLK_MAX_SEGMENTS (128) instead of local value
   SDHI_MAX_SEGS_IN_IOMMU (512). Even if we use BLK_MAX_SEGMENTS,
   the performance is still good.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=127511

Changes from v4:
 - [DMA MAPPING] Add a new device_dma_parameters for iova contiguous.
 - [IOMMU] Add a new capable for "merging" segments.
 - [IOMMU] Add a capable ops into the ipmmu-vmsa driver.
 - [MMC] Sort headers in renesas_sdhi_core.c.
 - [MMC] Remove the following codes that made on v3 that can be achieved by
 DMA MAPPING and IOMMU subsystem:
 -- Check if R-Car Gen3 IPMMU is used or not on patch 3.
 -- Check if all multiple segment buffers are aligned to PAGE_SIZE on patch 3.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=125593

Changes from v3:
 - Use a helper function device_iommu_mapped on patch 1 and 3.
 - Check if R-Car Gen3 IPMMU is used or not on patch 3.
 - Check if all multiple segment buffers are aligned to PAGE_SIZE on patch 3.
 - Add Reviewed-by Wolfram-san on patch 1 and 2. Note that I also got his
   Reviewed-by on patch 3, but I changed it from v2. So, I didn't add
   his Reviewed-by at this time.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=120985

Changes from v2:
 - Add some conditions in the init_card().
 - Add a comment in the init_card().
 - Add definitions for some "MAX_SEGS".
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=116729

Changes from v1:
 - Remove adding init_card ops into struct tmio_mmc_dma_ops and
   tmio_mmc_host and just set init_card on renesas_sdhi_core.c.
 - Revise typos on "mmc: tmio: No memory size limitation if runs on IOMMU".
 - Add Simon-san's Reviewed-by on a tmio patch.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=110485

Yoshihiro Shimoda (5):
  dma: Introduce dma_get_merge_boundary()
  iommu/dma: Add a new dma_map_ops of get_merge_boundary()
  block: sort headers on blk-setting.c
  block: add a helper function to merge the segments
  mmc: queue: Use bigger segments if DMA MAP layer can merge the
segments

 Documentation/DMA-API.txt   |  8 
 block/blk-settings.c| 34 --
 drivers/iommu/dma-iommu.c   | 11 +++
 drivers/mmc/core/queue.c| 35 ---
 include/linux/blkdev.h  |  2 ++
 include/linux/dma-mapping.h |  6 ++
 include/linux/mmc/host.h|  1 +
 kernel/dma/mapping.c| 11 +++
 8 files changed, 99 insertions(+), 9 deletions(-)

-- 
2.7.4

[RFC PATCH v7 1/5] dma: Introduce dma_get_merge_boundary()

[Yoshihiro Shimoda]

This patch adds a new DMA API "dma_get_merge_boundary". This function
returns the DMA merge boundary if the DMA layer can merge the segments.
This patch also adds the implementation for a new dma_map_ops pointer.

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/DMA-API.txt   |  8 
 include/linux/dma-mapping.h |  6 ++
 kernel/dma/mapping.c| 11 +++
 3 files changed, 25 insertions(+)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 0076150..11a2647 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -204,6 +204,14 @@ Returns the maximum size of a mapping for the device. The 
size parameter
 of the mapping functions like dma_map_single(), dma_map_page() and
 others should not be larger than the returned value.
 
+::
+
+   unsigned long
+   dma_get_merge_boundary(struct device *dev);
+
+Returns the DMA merge boundary. If the device cannot merge any the DMA address
+segments, the function returns 0.
+
 Part Id - Streaming DMA mappings
 
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 6309a72..e81e076 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -131,6 +131,7 @@ struct dma_map_ops {
int (*dma_supported)(struct device *dev, u64 mask);
u64 (*get_required_mask)(struct device *dev);
size_t (*max_mapping_size)(struct device *dev);
+   unsigned long (*get_merge_boundary)(struct device *dev);
 };
 
 #define DMA_MAPPING_ERROR  (~(dma_addr_t)0)
@@ -467,6 +468,7 @@ int dma_set_mask(struct device *dev, u64 mask);
 int dma_set_coherent_mask(struct device *dev, u64 mask);
 u64 dma_get_required_mask(struct device *dev);
 size_t dma_max_mapping_size(struct device *dev);
+unsigned long dma_get_merge_boundary(struct device *dev);
 #else /* CONFIG_HAS_DMA */
 static inline dma_addr_t dma_map_page_attrs(struct device *dev,
struct page *page, size_t offset, size_t size,
@@ -572,6 +574,10 @@ static inline size_t dma_max_mapping_size(struct device 
*dev)
 {
return 0;
 }
+static inline unsigned long dma_get_merge_boundary(struct device *dev)
+{
+   return 0;
+}
 #endif /* CONFIG_HAS_DMA */
 
 static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index f7afdad..8e262cf 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -367,3 +367,14 @@ size_t dma_max_mapping_size(struct device *dev)
return size;
 }
 EXPORT_SYMBOL_GPL(dma_max_mapping_size);
+
+unsigned long dma_get_merge_boundary(struct device *dev)
+{
+   const struct dma_map_ops *ops = get_dma_ops(dev);
+
+   if (!ops || !ops->get_merge_boundary)
+   return 0;   /* can't merge */
+
+   return ops->get_merge_boundary(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_merge_boundary);
-- 
2.7.4

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

[RFC PATCH v7 3/5] block: sort headers on blk-setting.c

[Yoshihiro Shimoda]

This patch sorts the headers in alphabetic order to ease
the maintenance for this part.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Wolfram Sang 
---
 block/blk-settings.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 2ae348c..45f2c52 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -2,16 +2,16 @@
 /*
  * Functions related to setting various queue properties from drivers
  */
-#include 
-#include 
-#include 
 #include 
 #include 
-#include /* for max_pfn/max_low_pfn */
 #include 
-#include 
-#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include  /* for max_pfn/max_low_pfn */
+#include 
 
 #include "blk.h"
 #include "blk-wbt.h"
-- 
2.7.4

[RFC PATCH v7 5/5] mmc: queue: Use bigger segments if DMA MAP layer can merge the segments

[Yoshihiro Shimoda]

When the max_segs of a mmc host is smaller than 512, the mmc
subsystem tries to use 512 segments if DMA MAP layer can merge
the segments, and then the mmc subsystem exposes such information
to the block layer by using blk_queue_can_use_dma_map_merging().

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/mmc/core/queue.c | 35 ---
 include/linux/mmc/host.h |  1 +
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 92900a0..ab0ecc6 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -24,6 +24,8 @@
 #include "card.h"
 #include "host.h"
 
+#define MMC_DMA_MAP_MERGE_SEGMENTS 512
+
 static inline bool mmc_cqe_dcmd_busy(struct mmc_queue *mq)
 {
/* Allow only 1 DCMD at a time */
@@ -196,6 +198,12 @@ static void mmc_queue_setup_discard(struct request_queue 
*q,
blk_queue_flag_set(QUEUE_FLAG_SECERASE, q);
 }
 
+static unsigned int mmc_get_max_segments(struct mmc_host *host)
+{
+   return host->can_dma_map_merge ? MMC_DMA_MAP_MERGE_SEGMENTS :
+host->max_segs;
+}
+
 /**
  * mmc_init_request() - initialize the MMC-specific per-request data
  * @q: the request queue
@@ -209,7 +217,7 @@ static int __mmc_init_request(struct mmc_queue *mq, struct 
request *req,
struct mmc_card *card = mq->card;
struct mmc_host *host = card->host;
 
-   mq_rq->sg = mmc_alloc_sg(host->max_segs, gfp);
+   mq_rq->sg = mmc_alloc_sg(mmc_get_max_segments(host), gfp);
if (!mq_rq->sg)
return -ENOMEM;
 
@@ -368,13 +376,23 @@ static void mmc_setup_queue(struct mmc_queue *mq, struct 
mmc_card *card)
blk_queue_bounce_limit(mq->queue, limit);
blk_queue_max_hw_sectors(mq->queue,
min(host->max_blk_count, host->max_req_size / 512));
-   blk_queue_max_segments(mq->queue, host->max_segs);
+   if (host->can_dma_map_merge)
+   WARN(!blk_queue_can_use_dma_map_merging(mq->queue,
+   mmc_dev(host)),
+"merging was advertised but not possible");
+   blk_queue_max_segments(mq->queue, mmc_get_max_segments(host));
 
if (mmc_card_mmc(card))
block_size = card->ext_csd.data_sector_size;
 
blk_queue_logical_block_size(mq->queue, block_size);
-   blk_queue_max_segment_size(mq->queue,
+   /*
+* After blk_queue_can_use_dma_map_merging() was called with succeed,
+* since it calls blk_queue_virt_boundary(), the mmc should not call
+* both blk_queue_max_segment_size().
+*/
+   if (host->can_dma_map_merge)
+   blk_queue_max_segment_size(mq->queue,
round_down(host->max_seg_size, block_size));
 
dma_set_max_seg_size(mmc_dev(host), queue_max_segment_size(mq->queue));
@@ -424,6 +442,17 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card 
*card)
mq->tag_set.cmd_size = sizeof(struct mmc_queue_req);
mq->tag_set.driver_data = mq;
 
+   /*
+* Since blk_mq_alloc_tag_set() calls .init_request() of mmc_mq_ops,
+* the host->can_dma_map_merge should be set before to get max_segs
+* from mmc_get_max_segments().
+*/
+   if (host->max_segs < MMC_DMA_MAP_MERGE_SEGMENTS &&
+   dma_get_merge_boundary(mmc_dev(host)))
+   host->can_dma_map_merge = 1;
+   else
+   host->can_dma_map_merge = 0;
+
ret = blk_mq_alloc_tag_set(>tag_set);
if (ret)
return ret;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 43d0f0c..10c3719 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -398,6 +398,7 @@ struct mmc_host {
unsigned intretune_now:1;   /* do re-tuning at next req */
unsigned intretune_paused:1; /* re-tuning is temporarily 
disabled */
unsigned intuse_blk_mq:1;   /* use blk-mq */
+   unsigned intcan_dma_map_merge:1; /* merging can be used */
 
int rescan_disable; /* disable card detection */
int rescan_entered; /* used with nonremovable 
devices */
-- 
2.7.4