devicetree: Add generic IOMMU device tree bindings
Subsystems (3)
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
From: Thierry Reding <[email protected]>
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
---
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
Documentation/devicetree/bindings/iommu/iommu.txt new file +182 -0
@@ -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 at 1 { + reg = <1>; + iommus = <&{/iommu}>; + }; + + /* static association with IOMMU */ + master at 2 { + reg = <2>; + iommus = <&{/iommu}>; + }; + +Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + }; + + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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>; + }; + };
Signature · 1 line
2.0.3
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 7 lines · Thierry Reding
From: Thierry Reding <[email protected]>
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:
Quoted 6 lines
https://lkml.org/lkml/2014/4/27/346Acked-by Will Deacon <[email protected]>Reviewed-by Arnd Bergmann <[email protected]>Acked-by Rob Herring <[email protected]>Signed-off-by Thierry Reding <[email protected]>
This looks good to me, and you've adressed the only comments I had, so:
Thanks for putting this together!
Mark.
Quoted 221 lines
---
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 windowChanges 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 exampleChanges in v3:
- use #iommu-cells instead of #address-cells/#size-cells
- drop optional iommu-names propertyChanges 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 exampleDocumentation/devicetree/bindings/iommu/iommu.txt | 182 ++++++++++++++++++++++ 1 file changed, 182 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txtDocumentation/devicetree/bindings/iommu/iommu.txt new file +182
-0@@ -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 at 1 { + reg = <1>; + iommus = <&{/iommu}>; + }; + + /* static association with IOMMU */ + master at 2 { + reg = <2>; + iommus = <&{/iommu}>; + }; + +Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + }; + + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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>; + }; + };Signature · 1 line
2.0.3
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
In reply to Thierry RedingQuoted 7 lines · Thierry Reding
From: Thierry Reding <[email protected]>
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:
Quoted 6 lines
https://lkml.org/lkml/2014/4/27/346Acked-by Will Deacon <[email protected]>Reviewed-by Arnd Bergmann <[email protected]>Acked-by Rob Herring <[email protected]>Signed-off-by Thierry Reding <[email protected]>
Applied, thanks everyone.
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 8 lines · Joerg Roedel
Quoted 7 lines · Thierry Reding
From: Thierry Reding <[email protected]>
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:
Quoted 8 lines
Quoted 6 lines
https://lkml.org/lkml/2014/4/27/346Acked-by Will Deacon <[email protected]>Reviewed-by Arnd Bergmann <[email protected]>Acked-by Rob Herring <[email protected]>Signed-off-by Thierry Reding <[email protected]>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
Joerg Roedel
maintainerPATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 7 lines · Olof Johansson
Quoted 2 lines
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
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 11 lines · Joerg Roedel
Quoted 7 lines · Olof Johansson
Quoted 2 lines
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:
-Olof
Joerg Roedel
maintainerPATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 10 lines · Olof Johansson
Quoted 9 lines · Joerg Roedel
Quoted 7 lines · Olof Johansson
Quoted 2 lines
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.
Quoted 7 lines
Quoted 2 lines
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 <[email protected]>
Thanks, added your Reviewed-by and will push the new tree out in the evening.
Joerg
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
In reply to Thierry RedingHi Thierry,
Quoted 7 lines · On Thursday 31 July 2014 12:43:03 Thierry Reding wrote:
From: Thierry Reding <[email protected]>
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:
Quoted 6 lines
https://lkml.org/lkml/2014/4/27/346Acked-by Will Deacon <[email protected]>Reviewed-by Arnd Bergmann <[email protected]>Acked-by Rob Herring <[email protected]>Signed-off-by Thierry Reding <[email protected]>
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.
Quoted 217 lines
---
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 windowChanges 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 exampleChanges in v3:
- use #iommu-cells instead of #address-cells/#size-cells
- drop optional iommu-names propertyChanges 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 exampleDocumentation/devicetree/bindings/iommu/iommu.txt | 182 ++++++++++++++++++++++ 1 file changed, 182 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt(quoted diff) +0
-0
b/Documentation/devicetree/bindings/iommu/iommu.txtnew file mode 100644 index 000000000000..5a8b4624defcDocumentation/devicetree/bindings/iommu/iommu.txt new file +1
-0@@ -0,0 +1,182 @@ +This document describes the generic device tree binding for IOMMUs andtheir +master(s).
Documentation/devicetree/bindings/iommu/iommu.txt new file +8
-0+ + +IOMMU device node: +================== + +An IOMMU can provide the following services: + +* Remap address space to allow devices to access physical memory rangesthat + they otherwise wouldn't be capable of accessing.
Documentation/devicetree/bindings/iommu/iommu.txt new file +4
-0+ + Example: 32-bit DMA to 64-bit physical addresses + +* Implement scatter-gather at page level granularity so that the devicedoes + not have to.
Documentation/devicetree/bindings/iommu/iommu.txt new file +2
-0+ +* Provide system protection against "rogue" DMA by forcing all accesses togo + through the IOMMU and faulting when encountering accesses to unmapped
Documentation/devicetree/bindings/iommu/iommu.txt new file +7
-0+ address regions. + +* Provide address space isolation between multiple contexts. + + Example: Virtualization + +Device nodes compatible with this binding represent hardware with some ofthe +above capabilities.
Documentation/devicetree/bindings/iommu/iommu.txt new file +12
-0+ +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 encodean + address.
Documentation/devicetree/bindings/iommu/iommu.txt new file +6
-0+ +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 allowthe + 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.Documentation/devicetree/bindings/iommu/iommu.txt new file +2
-0+ +Note that these are merely examples and real-world use-cases may usedifferent +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. +
Documentation/devicetree/bindings/iommu/iommu.txt new file +5
-0+ +IOMMU master node: +================== + +Devices that access memory through an IOMMU are called masters. A devicecan +have multiple master interfaces (to one or more IOMMU devices).
Documentation/devicetree/bindings/iommu/iommu.txt new file +4
-0+ +Required properties: +-------------------- +- iommus: A list of phandle and IOMMU specifier pairs that describe theIOMMU + master interfaces of the device. One entry in the list describes one master + interface of the device.
Documentation/devicetree/bindings/iommu/iommu.txt new file +2
-0+ +When an "iommus" property is specified in a device tree node, the IOMMUwill +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.
Documentation/devicetree/bindings/iommu/iommu.txt new file +6
-0+ + +Notes: +====== + +One possible extension to the above is to use an "iommus" property alongwith +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.
Documentation/devicetree/bindings/iommu/iommu.txt new file +83
-0+ + +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 at 1 { + reg = <1>; + iommus = <&{/iommu}>; + }; + + /* static association with IOMMU */ + master at 2 { + reg = <2>; + iommus = <&{/iommu}>; + }; + +Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + }; + + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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>; + }; + };
Signature · 3 lines
Regards, Laurent Pinchart
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
In reply to Thierry RedingQuoted 7 lines · Thierry Reding
Documentation/devicetree/bindings/iommu/iommu.txt new file +7
-0+Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + };
Documentation/devicetree/bindings/iommu/iommu.txt line 160
Quoted 10 lines
Documentation/devicetree/bindings/iommu/iommu.txt new file +10
-0+ + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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?
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 47 lines
-----Original Message-----
From: iommu-bounces at lists.linux-foundation.org [mailto:iommu- bounces at lists.linux-foundation.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 at vger.kernel.org; Olof Johansson; iommu at lists.linux-foundation.org; Rob Herring; linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsQuoted 7 lines · Thierry Reding
Documentation/devicetree/bindings/iommu/iommu.txt new file +7
-0+Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + };Documentation/devicetree/bindings/iommu/iommu.txt line 160
Quoted 10 lines
Documentation/devicetree/bindings/iommu/iommu.txt new file +10
-0+ + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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?
Quoted 7 lines
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
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Hi Varun,
Quoted 48 lines · Varun Sethi
Quoted 48 lines
-----Original Message-----
From: iommu-bounces at lists.linux-foundation.org [mailto:iommu- bounces at lists.linux-foundation.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 at vger.kernel.org; Olof Johansson; iommu at lists.linux-foundation.org; Rob Herring; linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsQuoted 7 lines · Thierry Reding
Documentation/devicetree/bindings/iommu/iommu.txt new file +7
-0+Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + };Documentation/devicetree/bindings/iommu/iommu.txt line 160
Quoted 10 lines
Documentation/devicetree/bindings/iommu/iommu.txt new file +10
-0+ + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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.
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Hi Hiroshi,
Quoted 71 lines
-----Original Message-----
From: Hiroshi Doyu [mailto:hdoyu at nvidia.com]
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 at vger.kernel.org; Olof Johansson; iommu at lists.linux-foundation.org; Rob Herring; linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsHi Varun,
Quoted 49 lines · Varun Sethi
Quoted 49 lines
-----Original Message-----
From: iommu-bounces at lists.linux-foundation.org [mailto:iommu- bounces at lists.linux-foundation.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 at vger.kernel.org; Olof Johansson; iommu at lists.linux-foundation.org; Rob Herring; linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsQuoted 7 lines · Thierry Reding
Documentation/devicetree/bindings/iommu/iommu.txt new file +7
-0+Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + };Documentation/devicetree/bindings/iommu/iommu.txt line 160
Quoted 10 lines
Documentation/devicetree/bindings/iommu/iommu.txt new file +10
-0+ + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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.
Quoted 7 lines
Quoted 4 lines
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?
Quoted 7 lines
No, "SoC master ID" is completely independenf of SMR.
Quoted 2 lines
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 at 1 {
/* device has master ID 42 in the IOMMU */
iommus = <&{/iommu} 42>;
master-id-reg = <phandle offset>
};-Varun
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 85 lines · Varun Sethi
Hi Hiroshi,
Quoted 71 lines
-----Original Message-----
From: Hiroshi Doyu [mailto:hdoyu at nvidia.com]
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 at vger.kernel.org; Olof Johansson; iommu at lists.linux-foundation.org; Rob Herring; linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsHi Varun,
Quoted 49 lines · Varun Sethi
Quoted 49 lines
-----Original Message-----
From: iommu-bounces at lists.linux-foundation.org [mailto:iommu- bounces at lists.linux-foundation.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 at vger.kernel.org; Olof Johansson; iommu at lists.linux-foundation.org; Rob Herring; linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsQuoted 7 lines · Thierry Reding
Documentation/devicetree/bindings/iommu/iommu.txt new file +7
-0+Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + };Documentation/devicetree/bindings/iommu/iommu.txt line 160
Quoted 10 lines
Documentation/devicetree/bindings/iommu/iommu.txt new file +10
-0+ + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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.
Quoted 7 lines
Quoted 4 lines
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?
Quoted 7 lines
No, "SoC master ID" is completely independenf of SMR.
Quoted 2 lines
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.
Quoted 5 lines
master at 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 at 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?
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 120 lines
-----Original Message-----
From: Hiroshi Doyu [mailto:hdoyu at nvidia.com]
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 at vger.kernel.org; Olof Johansson; iommu at lists.linux- foundation.org; Rob Herring; linux-tegra at vger.kernel.org; linux-arm- kernel at lists.infradead.org; Yoder Stuart-B08248
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsQuoted 82 lines · Varun Sethi
Hi Hiroshi,
Quoted 72 lines
-----Original Message-----
From: Hiroshi Doyu [mailto:hdoyu at nvidia.com]
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 at vger.kernel.org; Olof Johansson; iommu at lists.linux-foundation.org; Rob Herring; linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsHi Varun,
Quoted 49 lines · Varun Sethi
Quoted 49 lines
-----Original Message-----
From: iommu-bounces at lists.linux-foundation.org [mailto:iommu- bounces at lists.linux-foundation.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 at vger.kernel.org; Olof Johansson; iommu at lists.linux-foundation.org; Rob Herring; linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsQuoted 7 lines · Thierry Reding
Documentation/devicetree/bindings/iommu/iommu.txt new file +7
-0+Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + };Documentation/devicetree/bindings/iommu/iommu.txt line 160
Quoted 10 lines
Documentation/devicetree/bindings/iommu/iommu.txt new file +10
-0+ + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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.
Quoted 7 lines
Quoted 4 lines
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?
Quoted 7 lines
No, "SoC master ID" is completely independenf of SMR.
Quoted 2 lines
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.
Quoted 8 lines
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 at 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 at 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_notifierandADD_DEVICEshould 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.
Quoted 5 lines
IOW, SoC only needs to register
ADD_DEVICEinbus_notifierto map StreamID to a device. This needs to be executed earlier than IOMMU bus'sADD_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
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 33 lines · Varun Sethi
Quoted 33 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 8 lines
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 at 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 at 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_notifierandADD_DEVICEshould 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_DEVICEinbus_notifierto map StreamID to a device. This needs to be executed earlier than IOMMU bus'sADD_DEVICE, though.
Quoted 7 lines
Quoted 1 line
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.
Quoted 2 lines
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?
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 62 lines
-----Original Message-----
From: Hiroshi Doyu [mailto:hdoyu at nvidia.com]
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 at vger.kernel.org; Olof Johansson; iommu at lists.linux- foundation.org; Rob Herring; linux-tegra at vger.kernel.org; linux-arm- kernel at lists.infradead.org; Yoder Stuart-B08248
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsQuoted 2 lines · Varun Sethi
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Also, for dynamic stream ID allocation we would need to represent the specific master register (to store the stream ID) in the
device tree.
Quoted 31 lines
Quoted 31 lines
Quoted 4 lines
Quoted 3 lines
I assmue that the above means that iMX has such configuration register to map steramID and a device dynamically.
Quoted 8 lines
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 at 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 at 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_notifierandADD_DEVICEshould 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_DEVICEinbus_notifierto map StreamID to a device. This needs to be executed earlier than IOMMU bus'sADD_DEVICE, though.Quoted 7 lines
Quoted 1 line
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.
Quoted 2 lines
I was thinking more on the lines of updating the device stream id while attaching a device to the domain.
Quoted 6 lines
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
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
In reply to Hiroshi DoyuQuoted 34 lines · Hiroshi Doyu
Quoted 7 lines · Thierry Reding
Documentation/devicetree/bindings/iommu/iommu.txt new file +7
-0+Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + };Documentation/devicetree/bindings/iommu/iommu.txt line 160
Quoted 10 lines
Documentation/devicetree/bindings/iommu/iommu.txt new file +10
-0+ + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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?
Quoted 7 lines
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
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 57 lines · Will Deacon
Quoted 34 lines · Hiroshi Doyu
Quoted 7 lines · Thierry Reding
Documentation/devicetree/bindings/iommu/iommu.txt new file +7
-0+Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + };Documentation/devicetree/bindings/iommu/iommu.txt line 160
Quoted 10 lines
Documentation/devicetree/bindings/iommu/iommu.txt new file +10
-0+ + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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?
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 3 lines
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.
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Quoted 15 lines · Hiroshi Doyu
Quoted 14 lines · Will Deacon
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 9 lines
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">;
Quoted 7 lines
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
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
In reply to Will DeaconHi Will,
Quoted 48 lines
-----Original Message-----
From: iommu-bounces at lists.linux-foundation.org [mailto:iommu- bounces at lists.linux-foundation.org] On Behalf Of Will Deacon
Sent: Friday, August 15, 2014 5:21 PM
To: Hiroshi Doyu
Cc: Mark Rutland; devicetree at vger.kernel.org; Stephen Warren; Arnd Bergmann; Rob Herring; iommu at lists.linux-foundation.org; Thierry Reding; linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindingsQuoted 37 lines · Hiroshi Doyu
Quoted 7 lines · Thierry Reding
Documentation/devicetree/bindings/iommu/iommu.txt new file +7
-0+Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + };Documentation/devicetree/bindings/iommu/iommu.txt line 160
Quoted 10 lines
Documentation/devicetree/bindings/iommu/iommu.txt new file +10
-0+ + master at 1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master at 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.
Quoted 8 lines
Quoted 4 lines
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
PATCH v5 1/1 devicetree: Add generic IOMMU device tree bindings
Hi Varun,
Quoted 10 lines · Varun Sethi
Quoted 3 lines
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