[PATCH v5] devicetree: Add generic IOMMU device tree bindings

[PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Thierry Reding]

From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU as
discussed here:

    https://lkml.org/lkml/2014/4/27/346

Acked-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Reviewed-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Changes in v5:
- clarify comment about dma-ranges vs. IOMMU regarding a device's
  disabled state
- use proper DTS syntax reference absolute nodes for phandles
- clarify the meaning of the #iommu-cells = <0> example
- remove confusing (and unnecessary) #address-cells and #size-cells from
  multi-master windowed IOMMU example and clarify the meaning of DMA
  window

Changes in v4:
- clarify that disabling an IOMMU DT node may not disable translation
- be more explicit that examples are only examples
- add multi-ID master example

Changes in v3:
- use #iommu-cells instead of #address-cells/#size-cells
- drop optional iommu-names property

Changes in v2:
- add notes about "dma-ranges" property (drop note from commit message)
- document priorities of "iommus" property vs. "dma-ranges" property
- drop #iommu-cells in favour of #address-cells and #size-cells
- remove multiple-master device example

 Documentation/devicetree/bindings/iommu/iommu.txt | 182 ++++++++++++++++++++++
 1 file changed, 182 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt b/Documentation/devicetree/bindings/iommu/iommu.txt
new file mode 100644
index 000000000000..5a8b4624defc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/iommu.txt
@@ -0,0 +1,182 @@
+This document describes the generic device tree binding for IOMMUs and their
+master(s).
+
+
+IOMMU device node:
+==================
+
+An IOMMU can provide the following services:
+
+* Remap address space to allow devices to access physical memory ranges that
+  they otherwise wouldn't be capable of accessing.
+
+  Example: 32-bit DMA to 64-bit physical addresses
+
+* Implement scatter-gather at page level granularity so that the device does
+  not have to.
+
+* Provide system protection against "rogue" DMA by forcing all accesses to go
+  through the IOMMU and faulting when encountering accesses to unmapped
+  address regions.
+
+* Provide address space isolation between multiple contexts.
+
+  Example: Virtualization
+
+Device nodes compatible with this binding represent hardware with some of the
+above capabilities.
+
+IOMMUs can be single-master or multiple-master. Single-master IOMMU devices
+typically have a fixed association to the master device, whereas multiple-
+master IOMMU devices can translate accesses from more than one master.
+
+The device tree node of the IOMMU device's parent bus must contain a valid
+"dma-ranges" property that describes how the physical address space of the
+IOMMU maps to memory. An empty "dma-ranges" property means that there is a
+1:1 mapping from IOMMU to memory.
+
+Required properties:
+--------------------
+- #iommu-cells: The number of cells in an IOMMU specifier needed to encode an
+  address.
+
+The meaning of the IOMMU specifier is defined by the device tree binding of
+the specific IOMMU. Below are a few examples of typical use-cases:
+
+- #iommu-cells = <0>: Single master IOMMU devices are not configurable and
+  therefore no additional information needs to be encoded in the specifier.
+  This may also apply to multiple master IOMMU devices that do not allow the
+  association of masters to be configured. Note that an IOMMU can by design
+  be multi-master yet only expose a single master in a given configuration.
+  In such cases the number of cells will usually be 1 as in the next case.
+- #iommu-cells = <1>: Multiple master IOMMU devices may need to be configured
+  in order to enable translation for a given master. In such cases the single
+  address cell corresponds to the master device's ID. In some cases more than
+  one cell can be required to represent a single master ID.
+- #iommu-cells = <4>: Some IOMMU devices allow the DMA window for masters to
+  be configured. The first cell of the address in this may contain the master
+  device's ID for example, while the second cell could contain the start of
+  the DMA window for the given device. The length of the DMA window is given
+  by the third and fourth cells.
+
+Note that these are merely examples and real-world use-cases may use different
+definitions to represent their individual needs. Always refer to the specific
+IOMMU binding for the exact meaning of the cells that make up the specifier.
+
+
+IOMMU master node:
+==================
+
+Devices that access memory through an IOMMU are called masters. A device can
+have multiple master interfaces (to one or more IOMMU devices).
+
+Required properties:
+--------------------
+- iommus: A list of phandle and IOMMU specifier pairs that describe the IOMMU
+  master interfaces of the device. One entry in the list describes one master
+  interface of the device.
+
+When an "iommus" property is specified in a device tree node, the IOMMU will
+be used for address translation. If a "dma-ranges" property exists in the
+device's parent node it will be ignored. An exception to this rule is if the
+referenced IOMMU is disabled, in which case the "dma-ranges" property of the
+parent shall take effect. Note that merely disabling a device tree node does
+not guarantee that the IOMMU is really disabled since the hardware may not
+have a means to turn off translation. But it is invalid in such cases to
+disable the IOMMU's device tree node in the first place because it would
+prevent any driver from properly setting up the translations.
+
+
+Notes:
+======
+
+One possible extension to the above is to use an "iommus" property along with
+a "dma-ranges" property in a bus device node (such as PCI host bridges). This
+can be useful to describe how children on the bus relate to the IOMMU if they
+are not explicitly listed in the device tree (e.g. PCI devices). However, the
+requirements of that use-case haven't been fully determined yet. Implementing
+this is therefore not recommended without further discussion and extension of
+this binding.
+
+
+Examples:
+=========
+
+Single-master IOMMU:
+--------------------
+
+	iommu {
+		#iommu-cells = <0>;
+	};
+
+	master {
+		iommus = <&{/iommu}>;
+	};
+
+Multiple-master IOMMU with fixed associations:
+----------------------------------------------
+
+	/* multiple-master IOMMU */
+	iommu {
+		/*
+		 * Masters are statically associated with this IOMMU and share
+		 * the same address translations because the IOMMU does not
+		 * have sufficient information to distinguish between masters.
+		 *
+		 * Consequently address translation is always on or off for
+		 * all masters at any given point in time.
+		 */
+		#iommu-cells = <0>;
+	};
+
+	/* static association with IOMMU */
+	master@1 {
+		reg = <1>;
+		iommus = <&{/iommu}>;
+	};
+
+	/* static association with IOMMU */
+	master@2 {
+		reg = <2>;
+		iommus = <&{/iommu}>;
+	};
+
+Multiple-master IOMMU:
+----------------------
+
+	iommu {
+		/* the specifier represents the ID of the master */
+		#iommu-cells = <1>;
+	};
+
+	master@1 {
+		/* device has master ID 42 in the IOMMU */
+		iommus = <&{/iommu} 42>;
+	};
+
+	master@2 {
+		/* device has master IDs 23 and 24 in the IOMMU */
+		iommus = <&{/iommu} 23>, <&{/iommu} 24>;
+	};
+
+Multiple-master IOMMU with configurable DMA window:
+---------------------------------------------------
+
+	/ {
+		iommu {
+			/*
+			 * One cell for the master ID and one cell for the
+			 * address of the DMA window. The length of the DMA
+			 * window is encoded in two cells.
+			 *
+			 * The DMA window is the range addressable by the
+			 * master (i.e. the I/O virtual address space).
+			 */
+			#iommu-cells = <4>;
+		};
+
+		master {
+			/* master ID 42, 4 GiB DMA window starting at 0 */
+			iommus = <&{/iommu}  42  0  0x1 0x0>;
+		};
+	};
-- 
2.0.3

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Mark Rutland]

On Thu, Jul 31, 2014 at 11:43:03AM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
> discussed here:
> 
>     https://lkml.org/lkml/2014/4/27/346
> 
> Acked-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> Reviewed-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

This looks good to me, and you've adressed the only comments I had, so:

Reviewed-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>

Thanks for putting this together!

Mark.

> ---
> Changes in v5:
> - clarify comment about dma-ranges vs. IOMMU regarding a device's
>   disabled state
> - use proper DTS syntax reference absolute nodes for phandles
> - clarify the meaning of the #iommu-cells = <0> example
> - remove confusing (and unnecessary) #address-cells and #size-cells from
>   multi-master windowed IOMMU example and clarify the meaning of DMA
>   window
> 
> Changes in v4:
> - clarify that disabling an IOMMU DT node may not disable translation
> - be more explicit that examples are only examples
> - add multi-ID master example
> 
> Changes in v3:
> - use #iommu-cells instead of #address-cells/#size-cells
> - drop optional iommu-names property
> 
> Changes in v2:
> - add notes about "dma-ranges" property (drop note from commit message)
> - document priorities of "iommus" property vs. "dma-ranges" property
> - drop #iommu-cells in favour of #address-cells and #size-cells
> - remove multiple-master device example
> 
>  Documentation/devicetree/bindings/iommu/iommu.txt | 182 ++++++++++++++++++++++
>  1 file changed, 182 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt b/Documentation/devicetree/bindings/iommu/iommu.txt
> new file mode 100644
> index 000000000000..5a8b4624defc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/iommu.txt
> @@ -0,0 +1,182 @@
> +This document describes the generic device tree binding for IOMMUs and their
> +master(s).
> +
> +
> +IOMMU device node:
> +==================
> +
> +An IOMMU can provide the following services:
> +
> +* Remap address space to allow devices to access physical memory ranges that
> +  they otherwise wouldn't be capable of accessing.
> +
> +  Example: 32-bit DMA to 64-bit physical addresses
> +
> +* Implement scatter-gather at page level granularity so that the device does
> +  not have to.
> +
> +* Provide system protection against "rogue" DMA by forcing all accesses to go
> +  through the IOMMU and faulting when encountering accesses to unmapped
> +  address regions.
> +
> +* Provide address space isolation between multiple contexts.
> +
> +  Example: Virtualization
> +
> +Device nodes compatible with this binding represent hardware with some of the
> +above capabilities.
> +
> +IOMMUs can be single-master or multiple-master. Single-master IOMMU devices
> +typically have a fixed association to the master device, whereas multiple-
> +master IOMMU devices can translate accesses from more than one master.
> +
> +The device tree node of the IOMMU device's parent bus must contain a valid
> +"dma-ranges" property that describes how the physical address space of the
> +IOMMU maps to memory. An empty "dma-ranges" property means that there is a
> +1:1 mapping from IOMMU to memory.
> +
> +Required properties:
> +--------------------
> +- #iommu-cells: The number of cells in an IOMMU specifier needed to encode an
> +  address.
> +
> +The meaning of the IOMMU specifier is defined by the device tree binding of
> +the specific IOMMU. Below are a few examples of typical use-cases:
> +
> +- #iommu-cells = <0>: Single master IOMMU devices are not configurable and
> +  therefore no additional information needs to be encoded in the specifier.
> +  This may also apply to multiple master IOMMU devices that do not allow the
> +  association of masters to be configured. Note that an IOMMU can by design
> +  be multi-master yet only expose a single master in a given configuration.
> +  In such cases the number of cells will usually be 1 as in the next case.
> +- #iommu-cells = <1>: Multiple master IOMMU devices may need to be configured
> +  in order to enable translation for a given master. In such cases the single
> +  address cell corresponds to the master device's ID. In some cases more than
> +  one cell can be required to represent a single master ID.
> +- #iommu-cells = <4>: Some IOMMU devices allow the DMA window for masters to
> +  be configured. The first cell of the address in this may contain the master
> +  device's ID for example, while the second cell could contain the start of
> +  the DMA window for the given device. The length of the DMA window is given
> +  by the third and fourth cells.
> +
> +Note that these are merely examples and real-world use-cases may use different
> +definitions to represent their individual needs. Always refer to the specific
> +IOMMU binding for the exact meaning of the cells that make up the specifier.
> +
> +
> +IOMMU master node:
> +==================
> +
> +Devices that access memory through an IOMMU are called masters. A device can
> +have multiple master interfaces (to one or more IOMMU devices).
> +
> +Required properties:
> +--------------------
> +- iommus: A list of phandle and IOMMU specifier pairs that describe the IOMMU
> +  master interfaces of the device. One entry in the list describes one master
> +  interface of the device.
> +
> +When an "iommus" property is specified in a device tree node, the IOMMU will
> +be used for address translation. If a "dma-ranges" property exists in the
> +device's parent node it will be ignored. An exception to this rule is if the
> +referenced IOMMU is disabled, in which case the "dma-ranges" property of the
> +parent shall take effect. Note that merely disabling a device tree node does
> +not guarantee that the IOMMU is really disabled since the hardware may not
> +have a means to turn off translation. But it is invalid in such cases to
> +disable the IOMMU's device tree node in the first place because it would
> +prevent any driver from properly setting up the translations.
> +
> +
> +Notes:
> +======
> +
> +One possible extension to the above is to use an "iommus" property along with
> +a "dma-ranges" property in a bus device node (such as PCI host bridges). This
> +can be useful to describe how children on the bus relate to the IOMMU if they
> +are not explicitly listed in the device tree (e.g. PCI devices). However, the
> +requirements of that use-case haven't been fully determined yet. Implementing
> +this is therefore not recommended without further discussion and extension of
> +this binding.
> +
> +
> +Examples:
> +=========
> +
> +Single-master IOMMU:
> +--------------------
> +
> +	iommu {
> +		#iommu-cells = <0>;
> +	};
> +
> +	master {
> +		iommus = <&{/iommu}>;
> +	};
> +
> +Multiple-master IOMMU with fixed associations:
> +----------------------------------------------
> +
> +	/* multiple-master IOMMU */
> +	iommu {
> +		/*
> +		 * Masters are statically associated with this IOMMU and share
> +		 * the same address translations because the IOMMU does not
> +		 * have sufficient information to distinguish between masters.
> +		 *
> +		 * Consequently address translation is always on or off for
> +		 * all masters at any given point in time.
> +		 */
> +		#iommu-cells = <0>;
> +	};
> +
> +	/* static association with IOMMU */
> +	master@1 {
> +		reg = <1>;
> +		iommus = <&{/iommu}>;
> +	};
> +
> +	/* static association with IOMMU */
> +	master@2 {
> +		reg = <2>;
> +		iommus = <&{/iommu}>;
> +	};
> +
> +Multiple-master IOMMU:
> +----------------------
> +
> +	iommu {
> +		/* the specifier represents the ID of the master */
> +		#iommu-cells = <1>;
> +	};
> +
> +	master@1 {
> +		/* device has master ID 42 in the IOMMU */
> +		iommus = <&{/iommu} 42>;
> +	};
> +
> +	master@2 {
> +		/* device has master IDs 23 and 24 in the IOMMU */
> +		iommus = <&{/iommu} 23>, <&{/iommu} 24>;
> +	};
> +
> +Multiple-master IOMMU with configurable DMA window:
> +---------------------------------------------------
> +
> +	/ {
> +		iommu {
> +			/*
> +			 * One cell for the master ID and one cell for the
> +			 * address of the DMA window. The length of the DMA
> +			 * window is encoded in two cells.
> +			 *
> +			 * The DMA window is the range addressable by the
> +			 * master (i.e. the I/O virtual address space).
> +			 */
> +			#iommu-cells = <4>;
> +		};
> +
> +		master {
> +			/* master ID 42, 4 GiB DMA window starting at 0 */
> +			iommus = <&{/iommu}  42  0  0x1 0x0>;
> +		};
> +	};
> -- 
> 2.0.3
> 
> 

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Joerg Roedel]

On Thu, Jul 31, 2014 at 12:43:03PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
> discussed here:
> 
>     https://lkml.org/lkml/2014/4/27/346
> 
> Acked-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> Reviewed-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Applied, thanks everyone.

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Olof Johansson]

On Thu, Jul 31, 2014 at 5:04 AM, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Jul 31, 2014 at 12:43:03PM +0200, Thierry Reding wrote:
>> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>
>> This commit introduces a generic device tree binding for IOMMU devices.
>> Only a very minimal subset is described here, but it is enough to cover
>> the requirements of both the Exynos System MMU and Tegra SMMU as
>> discussed here:
>>
>>     https://lkml.org/lkml/2014/4/27/346
>>
>> Acked-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
>> Reviewed-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Applied, thanks everyone.

Really?

Gee, thanks for giving people a chance to reply with acks. It's
considered polite to do so when there has been outstanding questions.


-Olof

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Joerg Roedel]

On Thu, Jul 31, 2014 at 08:38:47AM -0700, Olof Johansson wrote:
> >
> > Applied, thanks everyone.
> 
> Really?
> 
> Gee, thanks for giving people a chance to reply with acks. It's
> considered polite to do so when there has been outstanding questions.

Its not pushed yet, I can still make changes. Do you have any objections
or an Ack?


	Joerg

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Olof Johansson]

On Thu, Jul 31, 2014 at 9:36 AM, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Jul 31, 2014 at 08:38:47AM -0700, Olof Johansson wrote:
>> >
>> > Applied, thanks everyone.
>>
>> Really?
>>
>> Gee, thanks for giving people a chance to reply with acks. It's
>> considered polite to do so when there has been outstanding questions.
>
> Its not pushed yet, I can still make changes. Do you have any objections
> or an Ack?

No outstanding objections. We have some things to amend with later but
that's perfectly fine:

Reviewed-by: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>


-Olof

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Joerg Roedel]

On Thu, Jul 31, 2014 at 10:14:08AM -0700, Olof Johansson wrote:
> On Thu, Jul 31, 2014 at 9:36 AM, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote:
> > On Thu, Jul 31, 2014 at 08:38:47AM -0700, Olof Johansson wrote:
> >> >
> >> > Applied, thanks everyone.
> >>
> >> Really?
> >>
> >> Gee, thanks for giving people a chance to reply with acks. It's
> >> considered polite to do so when there has been outstanding questions.
> >
> > Its not pushed yet, I can still make changes. Do you have any objections
> > or an Ack?
> 
> No outstanding objections. We have some things to amend with later but
> that's perfectly fine:
> 
> Reviewed-by: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>

Thanks, added your Reviewed-by and will push the new tree out in the
evening.


	Joerg

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Laurent Pinchart]

Hi Thierry,

On Thursday 31 July 2014 12:43:03 Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
> discussed here:
> 
>     https://lkml.org/lkml/2014/4/27/346
> 
> Acked-by: Will Deacon <will.deacon@arm.com>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Thierry Reding <treding@nvidia.com>

Thank you for the great work. This is nearly identical to my own IOMMU DT 
bindings experiment developed with the Renesas IPMMU-VMSA driver, so I can't 
disagree.

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> ---
> Changes in v5:
> - clarify comment about dma-ranges vs. IOMMU regarding a device's
>   disabled state
> - use proper DTS syntax reference absolute nodes for phandles
> - clarify the meaning of the #iommu-cells = <0> example
> - remove confusing (and unnecessary) #address-cells and #size-cells from
>   multi-master windowed IOMMU example and clarify the meaning of DMA
>   window
> 
> Changes in v4:
> - clarify that disabling an IOMMU DT node may not disable translation
> - be more explicit that examples are only examples
> - add multi-ID master example
> 
> Changes in v3:
> - use #iommu-cells instead of #address-cells/#size-cells
> - drop optional iommu-names property
> 
> Changes in v2:
> - add notes about "dma-ranges" property (drop note from commit message)
> - document priorities of "iommus" property vs. "dma-ranges" property
> - drop #iommu-cells in favour of #address-cells and #size-cells
> - remove multiple-master device example
> 
>  Documentation/devicetree/bindings/iommu/iommu.txt | 182
> ++++++++++++++++++++++ 1 file changed, 182 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt
> 
> diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt
> b/Documentation/devicetree/bindings/iommu/iommu.txt new file mode 100644
> index 000000000000..5a8b4624defc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/iommu.txt
> @@ -0,0 +1,182 @@
> +This document describes the generic device tree binding for IOMMUs and
> their +master(s).
> +
> +
> +IOMMU device node:
> +==================
> +
> +An IOMMU can provide the following services:
> +
> +* Remap address space to allow devices to access physical memory ranges
> that +  they otherwise wouldn't be capable of accessing.
> +
> +  Example: 32-bit DMA to 64-bit physical addresses
> +
> +* Implement scatter-gather at page level granularity so that the device
> does +  not have to.
> +
> +* Provide system protection against "rogue" DMA by forcing all accesses to
> go +  through the IOMMU and faulting when encountering accesses to unmapped
> +  address regions.
> +
> +* Provide address space isolation between multiple contexts.
> +
> +  Example: Virtualization
> +
> +Device nodes compatible with this binding represent hardware with some of
> the +above capabilities.
> +
> +IOMMUs can be single-master or multiple-master. Single-master IOMMU devices
> +typically have a fixed association to the master device, whereas multiple-
> +master IOMMU devices can translate accesses from more than one master. +
> +The device tree node of the IOMMU device's parent bus must contain a valid
> +"dma-ranges" property that describes how the physical address space of the
> +IOMMU maps to memory. An empty "dma-ranges" property means that there is a
> +1:1 mapping from IOMMU to memory.
> +
> +Required properties:
> +--------------------
> +- #iommu-cells: The number of cells in an IOMMU specifier needed to encode
> an +  address.
> +
> +The meaning of the IOMMU specifier is defined by the device tree binding of
> +the specific IOMMU. Below are a few examples of typical use-cases: +
> +- #iommu-cells = <0>: Single master IOMMU devices are not configurable and
> +  therefore no additional information needs to be encoded in the specifier.
> +  This may also apply to multiple master IOMMU devices that do not allow
> the +  association of masters to be configured. Note that an IOMMU can by
> design +  be multi-master yet only expose a single master in a given
> configuration. +  In such cases the number of cells will usually be 1 as in
> the next case. +- #iommu-cells = <1>: Multiple master IOMMU devices may
> need to be configured +  in order to enable translation for a given master.
> In such cases the single +  address cell corresponds to the master device's
> ID. In some cases more than +  one cell can be required to represent a
> single master ID.
> +- #iommu-cells = <4>: Some IOMMU devices allow the DMA window for masters
> to +  be configured. The first cell of the address in this may contain the
> master +  device's ID for example, while the second cell could contain the
> start of +  the DMA window for the given device. The length of the DMA
> window is given +  by the third and fourth cells.
> +
> +Note that these are merely examples and real-world use-cases may use
> different +definitions to represent their individual needs. Always refer to
> the specific +IOMMU binding for the exact meaning of the cells that make up
> the specifier. +
> +
> +IOMMU master node:
> +==================
> +
> +Devices that access memory through an IOMMU are called masters. A device
> can +have multiple master interfaces (to one or more IOMMU devices).
> +
> +Required properties:
> +--------------------
> +- iommus: A list of phandle and IOMMU specifier pairs that describe the
> IOMMU +  master interfaces of the device. One entry in the list describes
> one master +  interface of the device.
> +
> +When an "iommus" property is specified in a device tree node, the IOMMU
> will +be used for address translation. If a "dma-ranges" property exists in
> the +device's parent node it will be ignored. An exception to this rule is
> if the +referenced IOMMU is disabled, in which case the "dma-ranges"
> property of the +parent shall take effect. Note that merely disabling a
> device tree node does +not guarantee that the IOMMU is really disabled
> since the hardware may not +have a means to turn off translation. But it is
> invalid in such cases to +disable the IOMMU's device tree node in the first
> place because it would +prevent any driver from properly setting up the
> translations.
> +
> +
> +Notes:
> +======
> +
> +One possible extension to the above is to use an "iommus" property along
> with +a "dma-ranges" property in a bus device node (such as PCI host
> bridges). This +can be useful to describe how children on the bus relate to
> the IOMMU if they +are not explicitly listed in the device tree (e.g. PCI
> devices). However, the +requirements of that use-case haven't been fully
> determined yet. Implementing +this is therefore not recommended without
> further discussion and extension of +this binding.
> +
> +
> +Examples:
> +=========
> +
> +Single-master IOMMU:
> +--------------------
> +
> +	iommu {
> +		#iommu-cells = <0>;
> +	};
> +
> +	master {
> +		iommus = <&{/iommu}>;
> +	};
> +
> +Multiple-master IOMMU with fixed associations:
> +----------------------------------------------
> +
> +	/* multiple-master IOMMU */
> +	iommu {
> +		/*
> +		 * Masters are statically associated with this IOMMU and share
> +		 * the same address translations because the IOMMU does not
> +		 * have sufficient information to distinguish between masters.
> +		 *
> +		 * Consequently address translation is always on or off for
> +		 * all masters at any given point in time.
> +		 */
> +		#iommu-cells = <0>;
> +	};
> +
> +	/* static association with IOMMU */
> +	master@1 {
> +		reg = <1>;
> +		iommus = <&{/iommu}>;
> +	};
> +
> +	/* static association with IOMMU */
> +	master@2 {
> +		reg = <2>;
> +		iommus = <&{/iommu}>;
> +	};
> +
> +Multiple-master IOMMU:
> +----------------------
> +
> +	iommu {
> +		/* the specifier represents the ID of the master */
> +		#iommu-cells = <1>;
> +	};
> +
> +	master@1 {
> +		/* device has master ID 42 in the IOMMU */
> +		iommus = <&{/iommu} 42>;
> +	};
> +
> +	master@2 {
> +		/* device has master IDs 23 and 24 in the IOMMU */
> +		iommus = <&{/iommu} 23>, <&{/iommu} 24>;
> +	};
> +
> +Multiple-master IOMMU with configurable DMA window:
> +---------------------------------------------------
> +
> +	/ {
> +		iommu {
> +			/*
> +			 * One cell for the master ID and one cell for the
> +			 * address of the DMA window. The length of the DMA
> +			 * window is encoded in two cells.
> +			 *
> +			 * The DMA window is the range addressable by the
> +			 * master (i.e. the I/O virtual address space).
> +			 */
> +			#iommu-cells = <4>;
> +		};
> +
> +		master {
> +			/* master ID 42, 4 GiB DMA window starting at 0 */
> +			iommus = <&{/iommu}  42  0  0x1 0x0>;
> +		};
> +	};

-- 
Regards,

Laurent Pinchart

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Hiroshi Doyu]

Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> +Multiple-master IOMMU:
> +----------------------
> +
> +       iommu {
> +               /* the specifier represents the ID of the master */
> +               #iommu-cells = <1>;
> +       };
> +
> +       master@1 {
> +               /* device has master ID 42 in the IOMMU */
> +               iommus = <&{/iommu} 42>;
> +       };
> +
> +       master@2 {
> +               /* device has master IDs 23 and 24 in the IOMMU */
> +               iommus = <&{/iommu} 23>, <&{/iommu} 24>;
> +       };

I think that this "master ID" will be parsed in IOMMU driver. For
example, ARM,SMMU expects "streamID" as "master ID", right?

If a SoC has a feature to configure to assign streamID to devices at
runtime, "streamID" is not equal to "master ID".

  iommus = <&{/smmu} "soc specific master ID">;

"soc master ID" needs to be translated into "streamID" by SoC SW. It
seems that ARM,SMMU kernel driver doesn't expect this kind of ID
translation. If ARM,SMMU kernel driver is used as is, "soc master ID"
would be incompatible? ARM,SMMU needs such translation before
parsing. Is this my understanding right?

If so I think that this master ID configuration/translation may be quite
reasonable requirment for SoC using ARM,SMMU.

Can we consider this ID translation within ARM,SMMU compatibility?

IOW, is it possible to implement some SoC specific hook for ID
translation/configuration in ARM,SMMU kernel driver?

RE: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Varun Sethi]

> -----Original Message-----
> From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Hiroshi Doyu
> Sent: Thursday, August 14, 2014 12:18 PM
> To: Thierry Reding; Stephen Warren; Arnd Bergmann; Will Deacon
> Cc: Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Olof Johansson;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Rob Herring; linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings
> 
> 
> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> 
> > +Multiple-master IOMMU:
> > +----------------------
> > +
> > +       iommu {
> > +               /* the specifier represents the ID of the master */
> > +               #iommu-cells = <1>;
> > +       };
> > +
> > +       master@1 {
> > +               /* device has master ID 42 in the IOMMU */
> > +               iommus = <&{/iommu} 42>;
> > +       };
> > +
> > +       master@2 {
> > +               /* device has master IDs 23 and 24 in the IOMMU */
> > +               iommus = <&{/iommu} 23>, <&{/iommu} 24>;
> > +       };
> 
> I think that this "master ID" will be parsed in IOMMU driver. For example,
> ARM,SMMU expects "streamID" as "master ID", right?
> 
> If a SoC has a feature to configure to assign streamID to devices at runtime,
> "streamID" is not equal to "master ID".
> 
>   iommus = <&{/smmu} "soc specific master ID">;
> 
> "soc master ID" needs to be translated into "streamID" by SoC SW. It seems
> that ARM,SMMU kernel driver doesn't expect this kind of ID translation. If
> ARM,SMMU kernel driver is used as is, "soc master ID"
> would be incompatible? ARM,SMMU needs such translation before parsing. Is
> this my understanding right?
> 
> If so I think that this master ID configuration/translation may be quite
> reasonable requirment for SoC using ARM,SMMU.
> 
> Can we consider this ID translation within ARM,SMMU compatibility?
> 
> IOW, is it possible to implement some SoC specific hook for ID
> translation/configuration in ARM,SMMU kernel driver?


Can the id translation be done using a SMR mask? Also, for dynamic stream ID allocation we would need to represent the specific master register (to store the stream ID) in the device tree.

-Varun

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Hiroshi Doyu]

Hi Varun,

Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:

>> -----Original Message-----
>> From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
>> bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Hiroshi Doyu
>> Sent: Thursday, August 14, 2014 12:18 PM
>> To: Thierry Reding; Stephen Warren; Arnd Bergmann; Will Deacon
>> Cc: Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Olof Johansson;
>> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Rob Herring; linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings
>> 
>> 
>> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> 
>> > +Multiple-master IOMMU:
>> > +----------------------
>> > +
>> > +       iommu {
>> > +               /* the specifier represents the ID of the master */
>> > +               #iommu-cells = <1>;
>> > +       };
>> > +
>> > +       master@1 {
>> > +               /* device has master ID 42 in the IOMMU */
>> > +               iommus = <&{/iommu} 42>;
>> > +       };
>> > +
>> > +       master@2 {
>> > +               /* device has master IDs 23 and 24 in the IOMMU */
>> > +               iommus = <&{/iommu} 23>, <&{/iommu} 24>;
>> > +       };
>> 
>> I think that this "master ID" will be parsed in IOMMU driver. For example,
>> ARM,SMMU expects "streamID" as "master ID", right?
>> 
>> If a SoC has a feature to configure to assign streamID to devices at runtime,
>> "streamID" is not equal to "master ID".
>> 
>>   iommus = <&{/smmu} "soc specific master ID">;
>> 
>> "soc master ID" needs to be translated into "streamID" by SoC SW. It seems
>> that ARM,SMMU kernel driver doesn't expect this kind of ID translation. If
>> ARM,SMMU kernel driver is used as is, "soc master ID"
>> would be incompatible? ARM,SMMU needs such translation before parsing. Is
>> this my understanding right?
>> 
>> If so I think that this master ID configuration/translation may be quite
>> reasonable requirment for SoC using ARM,SMMU.
>> 
>> Can we consider this ID translation within ARM,SMMU compatibility?
>> 
>> IOW, is it possible to implement some SoC specific hook for ID
>> translation/configuration in ARM,SMMU kernel driver?
>
>
> Can the id translation be done using a SMR mask?

No, "SoC master ID" is completely independenf of SMR.

> Also, for dynamic stream ID allocation we would need to represent the
> specific master register (to store the stream ID) in the device tree.

I assmue that the above means that iMX has such configuration register
to map steramID and a device dynamically.

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Will Deacon]

On Thu, Aug 14, 2014 at 07:47:42AM +0100, Hiroshi Doyu wrote:
> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> 
> > +Multiple-master IOMMU:
> > +----------------------
> > +
> > +       iommu {
> > +               /* the specifier represents the ID of the master */
> > +               #iommu-cells = <1>;
> > +       };
> > +
> > +       master@1 {
> > +               /* device has master ID 42 in the IOMMU */
> > +               iommus = <&{/iommu} 42>;
> > +       };
> > +
> > +       master@2 {
> > +               /* device has master IDs 23 and 24 in the IOMMU */
> > +               iommus = <&{/iommu} 23>, <&{/iommu} 24>;
> > +       };
> 
> I think that this "master ID" will be parsed in IOMMU driver. For
> example, ARM,SMMU expects "streamID" as "master ID", right?
> 
> If a SoC has a feature to configure to assign streamID to devices at
> runtime, "streamID" is not equal to "master ID".
> 
>   iommus = <&{/smmu} "soc specific master ID">;
> 
> "soc master ID" needs to be translated into "streamID" by SoC SW. It
> seems that ARM,SMMU kernel driver doesn't expect this kind of ID
> translation. If ARM,SMMU kernel driver is used as is, "soc master ID"
> would be incompatible? ARM,SMMU needs such translation before
> parsing. Is this my understanding right?
> 
> If so I think that this master ID configuration/translation may be quite
> reasonable requirment for SoC using ARM,SMMU.
> 
> Can we consider this ID translation within ARM,SMMU compatibility?
> 
> IOW, is it possible to implement some SoC specific hook for ID
> translation/configuration in ARM,SMMU kernel driver?

I think there's some confusion here. The ARM architected SMMU does not
perform any StreamID translation -- it sees an incoming ID and uses that to
lookup a set of translation tables. However, for hotpluggable buses (e.g.
PCI), we need a way to communicate the StreamIDs for a newly discovered
device to the SMMU. I expect that this would be described as a translation
from another ID (e.g. requester id for PCI), so *that* is where the
translation occurs.

This translation can be described as a simple base + offset calculation,
e.g. StreamID = RequesterID + offset. Ideally, you'd have one offset per
host controller (and described in the host controller DT node), but you
could also imagine building tables where each RequesterID maps to a
different StreamID.

The final thing to mention is that some SoCs may have device hotplug
architectures that aren't like PCIe, so we may well need glue code there to
`allocate' StreamIDs from a fixed portion of the numberspace.

We don't need to solve all of these problems in one go, but the base +
offset code will certainly be useful; not just for the SMMU but also for
the GIC (where we have DeviceIDs). Mark Rutland is looking at this.

Will

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Hiroshi Doyu]

Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> writes:

> On Thu, Aug 14, 2014 at 07:47:42AM +0100, Hiroshi Doyu wrote:
>> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> 
>> > +Multiple-master IOMMU:
>> > +----------------------
>> > +
>> > +       iommu {
>> > +               /* the specifier represents the ID of the master */
>> > +               #iommu-cells = <1>;
>> > +       };
>> > +
>> > +       master@1 {
>> > +               /* device has master ID 42 in the IOMMU */
>> > +               iommus = <&{/iommu} 42>;
>> > +       };
>> > +
>> > +       master@2 {
>> > +               /* device has master IDs 23 and 24 in the IOMMU */
>> > +               iommus = <&{/iommu} 23>, <&{/iommu} 24>;
>> > +       };
>> 
>> I think that this "master ID" will be parsed in IOMMU driver. For
>> example, ARM,SMMU expects "streamID" as "master ID", right?
>> 
>> If a SoC has a feature to configure to assign streamID to devices at
>> runtime, "streamID" is not equal to "master ID".
>> 
>>   iommus = <&{/smmu} "soc specific master ID">;
>> 
>> "soc master ID" needs to be translated into "streamID" by SoC SW. It
>> seems that ARM,SMMU kernel driver doesn't expect this kind of ID
>> translation. If ARM,SMMU kernel driver is used as is, "soc master ID"
>> would be incompatible? ARM,SMMU needs such translation before
>> parsing. Is this my understanding right?
>> 
>> If so I think that this master ID configuration/translation may be quite
>> reasonable requirment for SoC using ARM,SMMU.
>> 
>> Can we consider this ID translation within ARM,SMMU compatibility?
>> 
>> IOW, is it possible to implement some SoC specific hook for ID
>> translation/configuration in ARM,SMMU kernel driver?
>
> I think there's some confusion here. The ARM architected SMMU does not
> perform any StreamID translation -- it sees an incoming ID and uses that to
> lookup a set of translation tables. However, for hotpluggable buses (e.g.
> PCI), we need a way to communicate the StreamIDs for a newly discovered
> device to the SMMU. I expect that this would be described as a translation
> from another ID (e.g. requester id for PCI), so *that* is where the
> translation occurs.
>
> This translation can be described as a simple base + offset calculation,
> e.g. StreamID = RequesterID + offset. Ideally, you'd have one offset per
> host controller (and described in the host controller DT node), but you
> could also imagine building tables where each RequesterID maps to a
> different StreamID.
>
> The final thing to mention is that some SoCs may have device hotplug
> architectures that aren't like PCIe, so we may well need glue code there to
> `allocate' StreamIDs from a fixed portion of the numberspace.

Ok, I can assume that, when parsing generic IOMMU binding, SoC specific
callback could be called from ARM,SMMU driver to assign allocated
"StreamIDs" to thier "RequesterIDs".

IOW, IOMMU generic binding for ARM,SMMU can have RequresterID instead of
StreamID.

  Not:
  	iommus = <&{/arm-smmu} "StreamID">;
  
  Instead, can be:
  	iommus = <&{/arm-smmu} "RequresterID">;

If I extend the above, even ARM,SMMU driver could have any number of
params, which SoC requires with keeping "arm,mmu-*" compatibility?

  	iommus = <&{/arm-msmmu} param1 param2 param3 param4 .....>;

How to parse params depends on SoC. Parsing params is done at SoC
callback, right?

> We don't need to solve all of these problems in one go, but the base +
> offset code will certainly be useful; not just for the SMMU but also for
> the GIC (where we have DeviceIDs). Mark Rutland is looking at this.

Any pointer would be really appreciated.

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Will Deacon]

On Fri, Aug 15, 2014 at 01:29:41PM +0100, Hiroshi Doyu wrote:
> Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> writes:
> > I think there's some confusion here. The ARM architected SMMU does not
> > perform any StreamID translation -- it sees an incoming ID and uses that to
> > lookup a set of translation tables. However, for hotpluggable buses (e.g.
> > PCI), we need a way to communicate the StreamIDs for a newly discovered
> > device to the SMMU. I expect that this would be described as a translation
> > from another ID (e.g. requester id for PCI), so *that* is where the
> > translation occurs.
> >
> > This translation can be described as a simple base + offset calculation,
> > e.g. StreamID = RequesterID + offset. Ideally, you'd have one offset per
> > host controller (and described in the host controller DT node), but you
> > could also imagine building tables where each RequesterID maps to a
> > different StreamID.
> >
> > The final thing to mention is that some SoCs may have device hotplug
> > architectures that aren't like PCIe, so we may well need glue code there to
> > `allocate' StreamIDs from a fixed portion of the numberspace.
> 
> Ok, I can assume that, when parsing generic IOMMU binding, SoC specific
> callback could be called from ARM,SMMU driver to assign allocated
> "StreamIDs" to thier "RequesterIDs".

The mapping should be done as part of the ->add_device callback, at the same
time as the iommu_group initialisation.

> IOW, IOMMU generic binding for ARM,SMMU can have RequresterID instead of
> StreamID.
> 
>   Not:
>   	iommus = <&{/arm-smmu} "StreamID">;
>   
>   Instead, can be:
>   	iommus = <&{/arm-smmu} "RequresterID">;
> 
> If I extend the above, even ARM,SMMU driver could have any number of
> params, which SoC requires with keeping "arm,mmu-*" compatibility?
> 
>   	iommus = <&{/arm-msmmu} param1 param2 param3 param4 .....>;
> 
> How to parse params depends on SoC. Parsing params is done at SoC
> callback, right?

No, I still don't think this is quite right. The SMMU deals with StreamIDs.
End of story. However, for a hotpluggable bus, you may need to determine
that StreamID from another dynamic ID. In the case of PCI, you can
dynamically find the RequesterID, then we'd just have an offset in the DT
node for the PCI host controller that describes how that maps to the StreamID.

So actually, we need to treat host controllers differently from end-points
in the binding, which would allow us to describe these transformations.

Will

RE: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Varun Sethi]

Hi Hiroshi,

> -----Original Message-----
> From: Hiroshi Doyu [mailto:hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org]
> Sent: Thursday, August 14, 2014 9:35 PM
> To: Sethi Varun-B16395
> Cc: Hiroshi Doyu; Thierry Reding; Stephen Warren; Arnd Bergmann; Will
> Deacon; Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Olof Johansson;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Rob Herring; linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings
> 
> Hi Varun,
> 
> Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:
> 
> >> -----Original Message-----
> >> From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> >> bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Hiroshi Doyu
> >> Sent: Thursday, August 14, 2014 12:18 PM
> >> To: Thierry Reding; Stephen Warren; Arnd Bergmann; Will Deacon
> >> Cc: Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Olof Johansson;
> >> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Rob Herring;
> >> linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> >> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree
> >> bindings
> >>
> >>
> >> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> >>
> >> > +Multiple-master IOMMU:
> >> > +----------------------
> >> > +
> >> > +       iommu {
> >> > +               /* the specifier represents the ID of the master */
> >> > +               #iommu-cells = <1>;
> >> > +       };
> >> > +
> >> > +       master@1 {
> >> > +               /* device has master ID 42 in the IOMMU */
> >> > +               iommus = <&{/iommu} 42>;
> >> > +       };
> >> > +
> >> > +       master@2 {
> >> > +               /* device has master IDs 23 and 24 in the IOMMU */
> >> > +               iommus = <&{/iommu} 23>, <&{/iommu} 24>;
> >> > +       };
> >>
> >> I think that this "master ID" will be parsed in IOMMU driver. For
> >> example, ARM,SMMU expects "streamID" as "master ID", right?
> >>
> >> If a SoC has a feature to configure to assign streamID to devices at
> >> runtime, "streamID" is not equal to "master ID".
> >>
> >>   iommus = <&{/smmu} "soc specific master ID">;
> >>
> >> "soc master ID" needs to be translated into "streamID" by SoC SW. It
> >> seems that ARM,SMMU kernel driver doesn't expect this kind of ID
> >> translation. If ARM,SMMU kernel driver is used as is, "soc master ID"
> >> would be incompatible? ARM,SMMU needs such translation before
> >> parsing. Is this my understanding right?
> >>
> >> If so I think that this master ID configuration/translation may be
> >> quite reasonable requirment for SoC using ARM,SMMU.
> >>
> >> Can we consider this ID translation within ARM,SMMU compatibility?
> >>
> >> IOW, is it possible to implement some SoC specific hook for ID
> >> translation/configuration in ARM,SMMU kernel driver?
> >
> >
> > Can the id translation be done using a SMR mask?
> 
> No, "SoC master ID" is completely independenf of SMR.
> 
> > Also, for dynamic stream ID allocation we would need to represent the
> > specific master register (to store the stream ID) in the device tree.
> 
> I assmue that the above means that iMX has such configuration register to map
> steramID and a device dynamically.
We have per master registers for setting the stream ID on the Layerscape platforms. My point was that we would need the iommu master node
to include a reference to the master id register.
master@1 {
               /* device has master ID 42 in the IOMMU */
             iommus = <&{/iommu} 42>;
             master-id-reg = <phandle offset>
};

-Varun

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Hiroshi Doyu]

Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:

> Hi Hiroshi,
>
>> -----Original Message-----
>> From: Hiroshi Doyu [mailto:hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org]
>> Sent: Thursday, August 14, 2014 9:35 PM
>> To: Sethi Varun-B16395
>> Cc: Hiroshi Doyu; Thierry Reding; Stephen Warren; Arnd Bergmann; Will
>> Deacon; Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Olof Johansson;
>> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Rob Herring; linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings
>> 
>> Hi Varun,
>> 
>> Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:
>> 
>> >> -----Original Message-----
>> >> From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
>> >> bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Hiroshi Doyu
>> >> Sent: Thursday, August 14, 2014 12:18 PM
>> >> To: Thierry Reding; Stephen Warren; Arnd Bergmann; Will Deacon
>> >> Cc: Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Olof Johansson;
>> >> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Rob Herring;
>> >> linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> >> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree
>> >> bindings
>> >>
>> >>
>> >> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> >>
>> >> > +Multiple-master IOMMU:
>> >> > +----------------------
>> >> > +
>> >> > +       iommu {
>> >> > +               /* the specifier represents the ID of the master */
>> >> > +               #iommu-cells = <1>;
>> >> > +       };
>> >> > +
>> >> > +       master@1 {
>> >> > +               /* device has master ID 42 in the IOMMU */
>> >> > +               iommus = <&{/iommu} 42>;
>> >> > +       };
>> >> > +
>> >> > +       master@2 {
>> >> > +               /* device has master IDs 23 and 24 in the IOMMU */
>> >> > +               iommus = <&{/iommu} 23>, <&{/iommu} 24>;
>> >> > +       };
>> >>
>> >> I think that this "master ID" will be parsed in IOMMU driver. For
>> >> example, ARM,SMMU expects "streamID" as "master ID", right?
>> >>
>> >> If a SoC has a feature to configure to assign streamID to devices at
>> >> runtime, "streamID" is not equal to "master ID".
>> >>
>> >>   iommus = <&{/smmu} "soc specific master ID">;
>> >>
>> >> "soc master ID" needs to be translated into "streamID" by SoC SW. It
>> >> seems that ARM,SMMU kernel driver doesn't expect this kind of ID
>> >> translation. If ARM,SMMU kernel driver is used as is, "soc master ID"
>> >> would be incompatible? ARM,SMMU needs such translation before
>> >> parsing. Is this my understanding right?
>> >>
>> >> If so I think that this master ID configuration/translation may be
>> >> quite reasonable requirment for SoC using ARM,SMMU.
>> >>
>> >> Can we consider this ID translation within ARM,SMMU compatibility?
>> >>
>> >> IOW, is it possible to implement some SoC specific hook for ID
>> >> translation/configuration in ARM,SMMU kernel driver?
>> >
>> >
>> > Can the id translation be done using a SMR mask?
>> 
>> No, "SoC master ID" is completely independenf of SMR.
>> 
>> > Also, for dynamic stream ID allocation we would need to represent the
>> > specific master register (to store the stream ID) in the device tree.
>> 
>> I assmue that the above means that iMX has such configuration register to map
>> steramID and a device dynamically.
>
> We have per master registers for setting the stream ID on the
> Layerscape platforms. My point was that we would need the iommu master
> node to include a reference to the master id register.
>
> master@1 {
>                /* device has master ID 42 in the IOMMU */
>              iommus = <&{/iommu} 42>;
>              master-id-reg = <phandle offset>
> };

In the above, for "iommus=" bindings, you wouldn't need to break
ARM,SMMU compatibility at all if you set "streamID" exactly as below.

  master@1 {
                 /* device has master ID 42 in the IOMMU */
               iommus = <&{/iommu} 'any given streamID'>;
               master-id-reg = <phandle offset>
  };

And your SoC needs to register bus_notifier and ADD_DEVICE should
configure to map 'any given streamID' to a device via the above
register. This wouldn't need any modification from ARM,SMMU driver and
keep the iommus bindings as it is.

IOW, SoC only needs to register ADD_DEVICE in bus_notifier to map
StreamID to a device. This needs to be executed earlier than IOMMU bus's
ADD_DEVICE, though.

Is my understanding right?

RE: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Varun Sethi]

> -----Original Message-----
> From: Hiroshi Doyu [mailto:hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org]
> Sent: Tuesday, August 19, 2014 3:34 PM
> To: Sethi Varun-B16395; Will Deacon
> Cc: Hiroshi Doyu; Thierry Reding; Stephen Warren; Arnd Bergmann; Mark
> Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Olof Johansson; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org; Rob Herring; linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Yoder Stuart-B08248
> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings
> 
> 
> Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:
> 
> > Hi Hiroshi,
> >
> >> -----Original Message-----
> >> From: Hiroshi Doyu [mailto:hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org]
> >> Sent: Thursday, August 14, 2014 9:35 PM
> >> To: Sethi Varun-B16395
> >> Cc: Hiroshi Doyu; Thierry Reding; Stephen Warren; Arnd Bergmann; Will
> >> Deacon; Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Olof Johansson;
> >> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Rob Herring;
> >> linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> >> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree
> >> bindings
> >>
> >> Hi Varun,
> >>
> >> Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:
> >>
> >> >> -----Original Message-----
> >> >> From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> >> >> bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Hiroshi Doyu
> >> >> Sent: Thursday, August 14, 2014 12:18 PM
> >> >> To: Thierry Reding; Stephen Warren; Arnd Bergmann; Will Deacon
> >> >> Cc: Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Olof Johansson;
> >> >> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Rob Herring;
> >> >> linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> >> >> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree
> >> >> bindings
> >> >>
> >> >>
> >> >> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> >> >>
> >> >> > +Multiple-master IOMMU:
> >> >> > +----------------------
> >> >> > +
> >> >> > +       iommu {
> >> >> > +               /* the specifier represents the ID of the master */
> >> >> > +               #iommu-cells = <1>;
> >> >> > +       };
> >> >> > +
> >> >> > +       master@1 {
> >> >> > +               /* device has master ID 42 in the IOMMU */
> >> >> > +               iommus = <&{/iommu} 42>;
> >> >> > +       };
> >> >> > +
> >> >> > +       master@2 {
> >> >> > +               /* device has master IDs 23 and 24 in the IOMMU */
> >> >> > +               iommus = <&{/iommu} 23>, <&{/iommu} 24>;
> >> >> > +       };
> >> >>
> >> >> I think that this "master ID" will be parsed in IOMMU driver. For
> >> >> example, ARM,SMMU expects "streamID" as "master ID", right?
> >> >>
> >> >> If a SoC has a feature to configure to assign streamID to devices
> >> >> at runtime, "streamID" is not equal to "master ID".
> >> >>
> >> >>   iommus = <&{/smmu} "soc specific master ID">;
> >> >>
> >> >> "soc master ID" needs to be translated into "streamID" by SoC SW.
> >> >> It seems that ARM,SMMU kernel driver doesn't expect this kind of
> >> >> ID translation. If ARM,SMMU kernel driver is used as is, "soc master ID"
> >> >> would be incompatible? ARM,SMMU needs such translation before
> >> >> parsing. Is this my understanding right?
> >> >>
> >> >> If so I think that this master ID configuration/translation may be
> >> >> quite reasonable requirment for SoC using ARM,SMMU.
> >> >>
> >> >> Can we consider this ID translation within ARM,SMMU compatibility?
> >> >>
> >> >> IOW, is it possible to implement some SoC specific hook for ID
> >> >> translation/configuration in ARM,SMMU kernel driver?
> >> >
> >> >
> >> > Can the id translation be done using a SMR mask?
> >>
> >> No, "SoC master ID" is completely independenf of SMR.
> >>
> >> > Also, for dynamic stream ID allocation we would need to represent
> >> > the specific master register (to store the stream ID) in the device tree.
> >>
> >> I assmue that the above means that iMX has such configuration
> >> register to map steramID and a device dynamically.
> >
> > We have per master registers for setting the stream ID on the
> > Layerscape platforms. My point was that we would need the iommu master
> > node to include a reference to the master id register.
> >
> > master@1 {
> >                /* device has master ID 42 in the IOMMU */
> >              iommus = <&{/iommu} 42>;
> >              master-id-reg = <phandle offset> };
> 
> In the above, for "iommus=" bindings, you wouldn't need to break
> ARM,SMMU compatibility at all if you set "streamID" exactly as below.
> 
>   master@1 {
>                  /* device has master ID 42 in the IOMMU */
>                iommus = <&{/iommu} 'any given streamID'>;
>                master-id-reg = <phandle offset>
>   };
> 
> And your SoC needs to register bus_notifier and ADD_DEVICE should configure
> to map 'any given streamID' to a device via the above register. This wouldn't
> need any modification from ARM,SMMU driver and keep the iommus bindings
> as it is.
> 
> IOW, SoC only needs to register ADD_DEVICE in bus_notifier to map StreamID
> to a device. This needs to be executed earlier than IOMMU bus's ADD_DEVICE,
> though.
> 
> Is my understanding right?
I don't think that SOC specific code needs a bus notifier for setting the stream ID. It can be done as a part of SOC specific initialization. The device tree can be updated to reflect the correct stream ID (SMMU driver can get the updated stream ID from device tree). 
I was thinking more on the lines of updating the device stream id while attaching a device to the domain.  

-Varun

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Hiroshi Doyu]

Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:

>> >> > Also, for dynamic stream ID allocation we would need to represent
>> >> > the specific master register (to store the stream ID) in the device tree.
>> >>
>> >> I assmue that the above means that iMX has such configuration
>> >> register to map steramID and a device dynamically.
>> >
>> > We have per master registers for setting the stream ID on the
>> > Layerscape platforms. My point was that we would need the iommu master
>> > node to include a reference to the master id register.
>> >
>> > master@1 {
>> >                /* device has master ID 42 in the IOMMU */
>> >              iommus = <&{/iommu} 42>;
>> >              master-id-reg = <phandle offset> };
>> 
>> In the above, for "iommus=" bindings, you wouldn't need to break
>> ARM,SMMU compatibility at all if you set "streamID" exactly as below.
>> 
>>   master@1 {
>>                  /* device has master ID 42 in the IOMMU */
>>                iommus = <&{/iommu} 'any given streamID'>;
>>                master-id-reg = <phandle offset>
>>   };
>> 
>> And your SoC needs to register bus_notifier and ADD_DEVICE should configure
>> to map 'any given streamID' to a device via the above register. This wouldn't
>> need any modification from ARM,SMMU driver and keep the iommus bindings
>> as it is.
>> 
>> IOW, SoC only needs to register ADD_DEVICE in bus_notifier to map StreamID
>> to a device. This needs to be executed earlier than IOMMU bus's ADD_DEVICE,
>> though.
>> 
>> Is my understanding right?
>
> I don't think that SOC specific code needs a bus notifier for setting
> the stream ID. It can be done as a part of SOC specific
> initialization. The device tree can be updated to reflect the correct
> stream ID (SMMU driver can get the updated stream ID from device
> tree). 

That's possible.

> I was thinking more on the lines of updating the device stream id
> while attaching a device to the domain.

I thought the same but this would break the ARM,SMMU /compatibility/
since the 1st param of "iommus=" is always expected as "streamID".

If streamID can be assigned dynamically like PCIe, not like streamID
statically set in DT, how should we describe this dynmaic steramID
shifting/assignment in DT?

RE: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Varun Sethi]

> -----Original Message-----
> From: Hiroshi Doyu [mailto:hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org]
> Sent: Tuesday, August 19, 2014 4:33 PM
> To: Sethi Varun-B16395; Will Deacon
> Cc: Hiroshi Doyu; Thierry Reding; Stephen Warren; Arnd Bergmann; Mark
> Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Olof Johansson; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org; Rob Herring; linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Yoder Stuart-B08248
> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings
> 
> 
> Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:
> 
> >> >> > Also, for dynamic stream ID allocation we would need to
> >> >> > represent the specific master register (to store the stream ID) in the
> device tree.
> >> >>
> >> >> I assmue that the above means that iMX has such configuration
> >> >> register to map steramID and a device dynamically.
> >> >
> >> > We have per master registers for setting the stream ID on the
> >> > Layerscape platforms. My point was that we would need the iommu
> >> > master node to include a reference to the master id register.
> >> >
> >> > master@1 {
> >> >                /* device has master ID 42 in the IOMMU */
> >> >              iommus = <&{/iommu} 42>;
> >> >              master-id-reg = <phandle offset> };
> >>
> >> In the above, for "iommus=" bindings, you wouldn't need to break
> >> ARM,SMMU compatibility at all if you set "streamID" exactly as below.
> >>
> >>   master@1 {
> >>                  /* device has master ID 42 in the IOMMU */
> >>                iommus = <&{/iommu} 'any given streamID'>;
> >>                master-id-reg = <phandle offset>
> >>   };
> >>
> >> And your SoC needs to register bus_notifier and ADD_DEVICE should
> >> configure to map 'any given streamID' to a device via the above
> >> register. This wouldn't need any modification from ARM,SMMU driver
> >> and keep the iommus bindings as it is.
> >>
> >> IOW, SoC only needs to register ADD_DEVICE in bus_notifier to map
> >> StreamID to a device. This needs to be executed earlier than IOMMU
> >> bus's ADD_DEVICE, though.
> >>
> >> Is my understanding right?
> >
> > I don't think that SOC specific code needs a bus notifier for setting
> > the stream ID. It can be done as a part of SOC specific
> > initialization. The device tree can be updated to reflect the correct
> > stream ID (SMMU driver can get the updated stream ID from device
> > tree).
> 
> That's possible.
> 
> > I was thinking more on the lines of updating the device stream id
> > while attaching a device to the domain.
> 
> I thought the same but this would break the ARM,SMMU /compatibility/ since
> the 1st param of "iommus=" is always expected as "streamID".
> 
> If streamID can be assigned dynamically like PCIe, not like streamID statically
> set in DT, how should we describe this dynmaic steramID shifting/assignment in
> DT?
 Can you dynamically program the stream ID for the device? If yes, then you require a unique numberspace for allocating a streamID. I am not clear on the stream ID translation requirement.

-Varun

RE: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Varun Sethi]

Hi Will,

> -----Original Message-----
> From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Will Deacon
> Sent: Friday, August 15, 2014 5:21 PM
> To: Hiroshi Doyu
> Cc: Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Stephen Warren; Arnd
> Bergmann; Rob Herring; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Thierry Reding;
> linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings
> 
> On Thu, Aug 14, 2014 at 07:47:42AM +0100, Hiroshi Doyu wrote:
> > Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> >
> > > +Multiple-master IOMMU:
> > > +----------------------
> > > +
> > > +       iommu {
> > > +               /* the specifier represents the ID of the master */
> > > +               #iommu-cells = <1>;
> > > +       };
> > > +
> > > +       master@1 {
> > > +               /* device has master ID 42 in the IOMMU */
> > > +               iommus = <&{/iommu} 42>;
> > > +       };
> > > +
> > > +       master@2 {
> > > +               /* device has master IDs 23 and 24 in the IOMMU */
> > > +               iommus = <&{/iommu} 23>, <&{/iommu} 24>;
> > > +       };
> >
> > I think that this "master ID" will be parsed in IOMMU driver. For
> > example, ARM,SMMU expects "streamID" as "master ID", right?
> >
> > If a SoC has a feature to configure to assign streamID to devices at
> > runtime, "streamID" is not equal to "master ID".
> >
> >   iommus = <&{/smmu} "soc specific master ID">;
> >
> > "soc master ID" needs to be translated into "streamID" by SoC SW. It
> > seems that ARM,SMMU kernel driver doesn't expect this kind of ID
> > translation. If ARM,SMMU kernel driver is used as is, "soc master ID"
> > would be incompatible? ARM,SMMU needs such translation before parsing.
> > Is this my understanding right?
> >
> > If so I think that this master ID configuration/translation may be
> > quite reasonable requirment for SoC using ARM,SMMU.
> >
> > Can we consider this ID translation within ARM,SMMU compatibility?
> >
> > IOW, is it possible to implement some SoC specific hook for ID
> > translation/configuration in ARM,SMMU kernel driver?
> 
> I think there's some confusion here. The ARM architected SMMU does not
> perform any StreamID translation -- it sees an incoming ID and uses that to
> lookup a set of translation tables. 

I don't completely agree with this. In case of MMU-500  don't we have the "TBUID + device assigned stream ID" representing the stream ID for matching at the TCU? In case of our platform, we have hot pluggable device objects comprising of devices connected to different TBUs. We have a requirement to use a single stream ID for all the distributed objects. We will have to use the stream ID masking capability to mask out the TBU ID.

-Varun

Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings

[Will Deacon]

Hi Varun,

On Tue, Aug 19, 2014 at 01:11:43PM +0100, Varun Sethi wrote:
> > I think there's some confusion here. The ARM architected SMMU does not
> > perform any StreamID translation -- it sees an incoming ID and uses that to
> > lookup a set of translation tables. 
> 
> I don't completely agree with this. In case of MMU-500  don't we have the
> "TBUID + device assigned stream ID" representing the stream ID for
> matching at the TCU? In case of our platform, we have hot pluggable device
> objects comprising of devices connected to different TBUs. We have a
> requirement to use a single stream ID for all the distributed objects. We
> will have to use the stream ID masking capability to mask out the TBU ID.

Please try to avoid mixing up micro-architectural details (i.e. how the
MMU-500 is integrated) with the software view defined by the architecture.

The point was that we don't need to over-engineer Linux to perform things
like StreamID (re)assignment, because that isn't the way the architecture is
designed. Your hotplug architecture may require the notion of masks, but
we can treat that as a fixed property of the hardware as opposed to something
we have to manage in the OS.

Will