[PATCH] iommu/ipmmu-vmsa: Include SoC part number in DT binding docs

[PATCH] iommu/ipmmu-vmsa: Include SoC part number in DT binding docs

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Add part numbers for APE6 and current set of R-Car Gen2 SoCs to the
IPMMU DT binding documentation. The example is also updated to show
how the generic compatible string may be used as fallback.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |   12 ++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- 0001/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
+++ work/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt	2015-10-18 15:53:08.850513000 +0900
@@ -7,7 +7,15 @@ connected to the IPMMU through a port ca
 
 Required Properties:
 
-  - compatible: Must contain "renesas,ipmmu-vmsa".
+  - compatible: Must contain one of the following:
+
+    - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) 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-vmsa" for generic R-Car Gen2 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
@@ -27,7 +35,7 @@ node with the following property:
 Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
 
 	ipmmu_mx: mmu@fe951000 {
-		compatible = "renasas,ipmmu-vmsa";
+		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>;

Re: [PATCH] iommu/ipmmu-vmsa: Include SoC part number in DT binding docs

[Laurent Pinchart]

Hi Magnus,

Thank you for the patch.

On Monday 19 October 2015 12:10:03 Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
> 
> Add part numbers for APE6 and current set of R-Car Gen2 SoCs to the
> IPMMU DT binding documentation. The example is also updated to show
> how the generic compatible string may be used as fallback.

I'd use a wording stronger than "may" here, as the generic compatible value is 
required. I would also explicitly state that in the bindings documentation.

> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> ---
> 
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |   12
> ++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
> 
> --- 0001/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
> +++
> work/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt	
2015-10
> -18 15:53:08.850513000 +0900 @@ -7,7 +7,15 @@ connected to the IPMMU through
> a port ca
> 
>  Required Properties:
> 
> -  - compatible: Must contain "renesas,ipmmu-vmsa".
> +  - compatible: Must contain one of the following:
> +
> +    - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) 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-vmsa" for generic R-Car Gen2 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 @@
> -27,7 +35,7 @@ node with the following property:
>  Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
> 
>  	ipmmu_mx: mmu@fe951000 {
> -		compatible = "renasas,ipmmu-vmsa";
> +		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>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH] iommu/ipmmu-vmsa: Include SoC part number in DT binding docs

[Magnus Damm]

Hi Laurent,

On Mon, Oct 19, 2015 at 3:44 PM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> Hi Magnus,
>
> Thank you for the patch.

Thanks for your feedback!

> On Monday 19 October 2015 12:10:03 Magnus Damm wrote:
>> From: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
>>
>> Add part numbers for APE6 and current set of R-Car Gen2 SoCs to the
>> IPMMU DT binding documentation. The example is also updated to show
>> how the generic compatible string may be used as fallback.
>
> I'd use a wording stronger than "may" here, as the generic compatible value is
> required. I would also explicitly state that in the bindings documentation.

I don't mind using a different wording, but it becomes a bit difficult
to describe exactly when to use the generic compatible string and when
not to. Is it always required, or does it depend on the hardware?

 "For compatible hardware please use the generic compat string."
Compatible with what? =)

Any ideas how to describe it correctly in the binding documentation?

Cheers,

/ magnus

Re: [PATCH] iommu/ipmmu-vmsa: Include SoC part number in DT binding docs

[Laurent Pinchart]

Hi Magnus,

On Tuesday 20 October 2015 17:58:17 Magnus Damm wrote:
> On Mon, Oct 19, 2015 at 3:44 PM, Laurent Pinchart wrote:
> > On Monday 19 October 2015 12:10:03 Magnus Damm wrote:
> >> From: Magnus Damm <damm+renesas@opensource.se>
> >> 
> >> Add part numbers for APE6 and current set of R-Car Gen2 SoCs to the
> >> IPMMU DT binding documentation. The example is also updated to show
> >> how the generic compatible string may be used as fallback.
> > 
> > I'd use a wording stronger than "may" here, as the generic compatible
> > value is required. I would also explicitly state that in the bindings
> > documentation.
>
> I don't mind using a different wording, but it becomes a bit difficult
> to describe exactly when to use the generic compatible string and when
> not to. Is it always required, or does it depend on the hardware?
> 
>  "For compatible hardware please use the generic compat string."
> Compatible with what? =)
> 
> Any ideas how to describe it correctly in the binding documentation?

Given that the generic compat string is always required I'd just say so. We 
can then update the DT bindings later when we'll introduce the first SoC not 
compatible with the generic compat string.

-- 
Regards,

Laurent Pinchart