linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 02/10] devicetree: Add generic IOMMU device tree bindings
Date: Thu, 26 Jun 2014 22:49:42 +0200	[thread overview]
Message-ID: <1403815790-8548-3-git-send-email-thierry.reding@gmail.com> (raw)
In-Reply-To: <1403815790-8548-1-git-send-email-thierry.reding@gmail.com>

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

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
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 | 156 ++++++++++++++++++++++
 1 file changed, 156 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..f8f03f057156
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/iommu.txt
@@ -0,0 +1,156 @@
+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.
+
+Typical values for the above include:
+- #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.
+- #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.
+- #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.
+
+
+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.
+
+
+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
+		 * address translation is always enabled.
+		 */
+		#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 {
+		/* device has master ID 42 in the IOMMU */
+		iommus = <&/iommu 42>;
+	};
+
+Multiple-master IOMMU with configurable DMA window:
+---------------------------------------------------
+
+	/ {
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		iommu {
+			/* master ID, address and length of DMA window */
+			#iommu-cells = <4>;
+		};
+
+		master {
+			/* master ID 42, 4 GiB DMA window starting at 0 */
+			iommus = <&/iommu  42  0  0x1 0x0>;
+		};
+	};
-- 
2.0.0

  parent reply	other threads:[~2014-06-26 20:49 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-26 20:49 [RFC 00/10] Add NVIDIA Tegra124 IOMMU support Thierry Reding
2014-06-26 20:49 ` [RFC 01/10] iommu: Add IOMMU device registry Thierry Reding
2014-06-27  6:58   ` Thierry Reding
2014-07-03 10:37     ` Varun Sethi
2014-07-04 11:05   ` Joerg Roedel
2014-07-04 13:47     ` Thierry Reding
2014-07-04 13:49       ` Will Deacon
2014-07-06 18:17         ` Arnd Bergmann
2014-07-07 11:42           ` Thierry Reding
2014-06-26 20:49 ` Thierry Reding [this message]
2014-06-27 13:55   ` [PATCH v3 02/10] devicetree: Add generic IOMMU device tree bindings Will Deacon
2014-06-30 22:24   ` Stephen Warren
2014-07-04  6:42   ` Varun Sethi
2014-07-04  9:05     ` Arnd Bergmann
2014-06-26 20:49 ` [RFC 03/10] of: Add NVIDIA Tegra124 memory controller binding Thierry Reding
2014-06-26 20:49 ` [RFC 04/10] memory: Add Tegra124 memory controller support Thierry Reding
2014-06-27  7:41   ` Joseph Lo
2014-06-27  8:17     ` Thierry Reding
2014-06-27  8:24       ` Hiroshi Doyu
2014-06-27  9:46   ` Hiroshi DOyu
2014-06-27 11:08     ` Thierry Reding
2014-06-27 21:33       ` Stephen Warren
2014-06-27 11:07   ` Arnd Bergmann
2014-06-27 11:15     ` Thierry Reding
2014-06-27 21:37       ` Stephen Warren
2014-06-27 13:29   ` Mikko Perttunen
2014-06-30 22:43   ` Stephen Warren
2014-07-01 12:14   ` Hiroshi Doyu
2014-06-26 20:49 ` [RFC 05/10] ARM: tegra: Add memory controller on Tegra124 Thierry Reding
2014-06-26 20:49 ` [RFC 06/10] ARM: tegra: tegra124: Enable IOMMU for display controllers Thierry Reding
2014-06-26 20:49 ` [RFC 07/10] ARM: tegra: tegra124: Enable IOMMU for SDMMC controllers Thierry Reding
2014-06-26 20:49 ` [RFC 08/10] ARM: tegra: Select ARM_DMA_USE_IOMMU Thierry Reding
2014-06-26 20:49 ` [RFC 09/10] drm/tegra: Add IOMMU support Thierry Reding
2014-06-27  9:46   ` Hiroshi DOyu
2014-06-27 10:54     ` Arnd Bergmann
2014-06-27 11:03       ` Hiroshi Doyu
2014-06-27 10:58     ` Thierry Reding
2014-09-30 18:48   ` Sean Paul
2014-10-01 15:54     ` Sean Paul
2014-10-02  8:39       ` Thierry Reding
2014-11-05  9:50       ` Thierry Reding
2014-11-05 10:26     ` Thierry Reding
2014-06-26 20:49 ` [RFC 10/10] mmc: sdhci-tegra: " Thierry Reding
2014-06-27  9:46   ` Hiroshi DOyu
2014-06-27 11:01     ` Thierry Reding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1403815790-8548-3-git-send-email-thierry.reding@gmail.com \
    --to=thierry.reding@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).