On 27/06/18 18:46, Rob Herring wrote:
On Tue, Jun 26, 2018 at 11:59 AM Jean-Philippe Brucker
<jean-philippe.bruc...@arm.com> wrote:
On 25/06/18 20:27, Rob Herring wrote:
On Thu, Jun 21, 2018 at 08:06:51PM +0100, Jean-Philippe Brucker wrote:
A virtio-mmio node may represent a virtio-iommu device. This is discovered
by the virtio driver at probe time, but the DMA topology isn't
discoverable and must be described by firmware. For DT the standard IOMMU
description is used, as specified in bindings/iommu/iommu.txt and
bindings/pci/pci-iommu.txt. Like many other IOMMUs, virtio-iommu
distinguishes masters by their endpoint IDs, which requires one IOMMU cell
in the "iommus" property.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.bruc...@arm.com>
---
Documentation/devicetree/bindings/virtio/mmio.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/virtio/mmio.txt
b/Documentation/devicetree/bindings/virtio/mmio.txt
index 5069c1b8e193..337da0e3a87f 100644
--- a/Documentation/devicetree/bindings/virtio/mmio.txt
+++ b/Documentation/devicetree/bindings/virtio/mmio.txt
@@ -8,6 +8,14 @@ Required properties:
- reg: control registers base address and size including
configuration space
- interrupts: interrupt generated by the device
+Required properties for virtio-iommu:
+
+- #iommu-cells: When the node describes a virtio-iommu device, it is
+ linked to DMA masters using the "iommus" property as
+ described in devicetree/bindings/iommu/iommu.txt. For
+ virtio-iommu #iommu-cells must be 1, each cell describing
+ a single endpoint ID.
The iommus property should also be documented for the client side.
Isn't section "IOMMU master node" of iommu.txt sufficient? Since the
iommus property applies to any DMA master, not only virtio-mmio devices,
the canonical description in iommu.txt seems the best place for it, and
I'm not sure what to add in this file. Maybe a short example below the
virtio_block one?
No, because somewhere we have to capture if 'iommus' is valid for
'virtio-mmio' or not. Hopefully soon we'll actually be able to
validate that.
Indeed, it's rather unusual to have a single compatible which may either
be an IOMMU or an IOMMU client (but not both at once, I hope!), so
nailing down the exact semantics as clearly as possible would definitely
be desirable.
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
