[PATCH v3 1/2] dt-bindings: arm: xen: document Xen iommu device

[Sergiy Kibrik <Sergiy_Kibrik@xxxxxxxx>]

In IOMMU-capable system hypervisor usually takes over IOMMU control.
Generally guest domains don't need to care about IOMMU management and take any
extra actions. Yet in some cases a knowledge about which device is protected
may be useful for privileged domain.

In compliance with iommu bindings this can be achieved with device-level
iommus property specified with dummy Xen iommu device.

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@xxxxxxxx>
---
 Documentation/devicetree/bindings/arm/xen.txt | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
index db5c56db30ec..98efa95c0d1b 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -58,3 +58,29 @@ Documentation/arm/uefi.rst, which are provided by the 
regular UEFI stub. However
 they differ because they are provided by the Xen hypervisor, together with a 
set
 of UEFI runtime services implemented via hypercalls, see
 
http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
+
+* XEN IOMMU device
+
+In compliance with iommu bindings Xen virtual IOMMU device node represents
+hypervisor-managed IOMMU [1]. Platform devices specified as IOMMU masters of
+this xen-iommu device are protected by hypervisor-managed platform IOMMU.
+
+Required properties:
+
+- compatible:  Should be "xen,iommu-el2-v1"
+- #iommu-cells: must be 0
+
+Example:
+
+xen-iommu {
+       compatible = "xen,iommu-el2-v1";
+       #iommu-cells = <0>;
+};
+
+video@fe001000 {
+       ...
+       /* this platform device is IOMMU-protected by hypervisor */
+       iommus = <&xen-iommu 0x0>;
+};
+
+[1] Documentation/devicetree/bindings/iommu/iommu.txt
-- 
2.25.1