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
next prev 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).