All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Cho KyongHo <pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Fri, 23 May 2014 22:36:35 +0200	[thread overview]
Message-ID: <1400877395-4235-1-git-send-email-thierry.reding@gmail.com> (raw)

From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Apologies for the noise, but apparently I mistyped one of the email
addresses, should be fixed now.

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 | 167 ++++++++++++++++++++++
 1 file changed, 167 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..6ce759afcc94
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/iommu.txt
@@ -0,0 +1,167 @@
+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:
+--------------------
+- #address-cells: The number of cells in an IOMMU specifier needed to encode
+  an address.
+- #size-cells: The number of cells in an IOMMU specifier needed to represent
+  the length of an address range.
+
+Typical values for the above include:
+- #address-cells = <0>, size-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.
+- #address-cells = <1>, size-cells = <0>: 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.
+- #address-cells = <2>, size-cells = <2>: 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 specified by two additional 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.
+
+Optional properties:
+--------------------
+- iommu-names: A list of names identifying each entry in the "iommus"
+  property.
+
+
+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 {
+		#address-cells = <0>;
+		#size-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.
+		 */
+		#address-cells = <0>;
+		#size-cells = <0>;
+	};
+
+	/* static association with IOMMU */
+	master@1 {
+		reg = <1>;
+		iommus = <&/iommu>;
+	};
+
+	/* static association with IOMMU */
+	master@2 {
+		reg = <2>;
+		iommus = <&/iommu>;
+	};
+
+Multiple-master IOMMU:
+----------------------
+
+	iommu {
+		/* the specifier represents the ID of the master */
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	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 of DMA window */
+			#address-cells = <2>;
+			#size-cells = <2>;
+		};
+
+		master {
+			/* master ID 42, 4 GiB DMA window starting at 0 */
+			iommus = <&/iommu  42 0  0x1 0x0>;
+		};
+	};
-- 
1.9.2

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Cho KyongHo <pullip.cho@samsung.com>,
	Grant Grundler <grundler@chromium.org>,
	Dave Martin <Dave.Martin@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Will Deacon <will.deacon@arm.com>, Joerg Roedel <joro@8bytes.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Hiroshi Doyu <hdoyu@nvidia.com>,
	devicetree@vger.kernel.org, iommu@lists.linux-foundation.org,
	linux-arm-kernel@lists.infradead.org,
	linux-tegra@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Fri, 23 May 2014 22:36:35 +0200	[thread overview]
Message-ID: <1400877395-4235-1-git-send-email-thierry.reding@gmail.com> (raw)

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>
---
Apologies for the noise, but apparently I mistyped one of the email
addresses, should be fixed now.

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 | 167 ++++++++++++++++++++++
 1 file changed, 167 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..6ce759afcc94
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/iommu.txt
@@ -0,0 +1,167 @@
+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:
+--------------------
+- #address-cells: The number of cells in an IOMMU specifier needed to encode
+  an address.
+- #size-cells: The number of cells in an IOMMU specifier needed to represent
+  the length of an address range.
+
+Typical values for the above include:
+- #address-cells = <0>, size-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.
+- #address-cells = <1>, size-cells = <0>: 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.
+- #address-cells = <2>, size-cells = <2>: 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 specified by two additional 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.
+
+Optional properties:
+--------------------
+- iommu-names: A list of names identifying each entry in the "iommus"
+  property.
+
+
+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 {
+		#address-cells = <0>;
+		#size-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.
+		 */
+		#address-cells = <0>;
+		#size-cells = <0>;
+	};
+
+	/* static association with IOMMU */
+	master@1 {
+		reg = <1>;
+		iommus = <&/iommu>;
+	};
+
+	/* static association with IOMMU */
+	master@2 {
+		reg = <2>;
+		iommus = <&/iommu>;
+	};
+
+Multiple-master IOMMU:
+----------------------
+
+	iommu {
+		/* the specifier represents the ID of the master */
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	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 of DMA window */
+			#address-cells = <2>;
+			#size-cells = <2>;
+		};
+
+		master {
+			/* master ID 42, 4 GiB DMA window starting at 0 */
+			iommus = <&/iommu  42 0  0x1 0x0>;
+		};
+	};
-- 
1.9.2


WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Fri, 23 May 2014 22:36:35 +0200	[thread overview]
Message-ID: <1400877395-4235-1-git-send-email-thierry.reding@gmail.com> (raw)

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>
---
Apologies for the noise, but apparently I mistyped one of the email
addresses, should be fixed now.

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 | 167 ++++++++++++++++++++++
 1 file changed, 167 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..6ce759afcc94
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/iommu.txt
@@ -0,0 +1,167 @@
+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:
+--------------------
+- #address-cells: The number of cells in an IOMMU specifier needed to encode
+  an address.
+- #size-cells: The number of cells in an IOMMU specifier needed to represent
+  the length of an address range.
+
+Typical values for the above include:
+- #address-cells = <0>, size-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.
+- #address-cells = <1>, size-cells = <0>: 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.
+- #address-cells = <2>, size-cells = <2>: 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 specified by two additional 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.
+
+Optional properties:
+--------------------
+- iommu-names: A list of names identifying each entry in the "iommus"
+  property.
+
+
+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 {
+		#address-cells = <0>;
+		#size-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.
+		 */
+		#address-cells = <0>;
+		#size-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 */
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	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 of DMA window */
+			#address-cells = <2>;
+			#size-cells = <2>;
+		};
+
+		master {
+			/* master ID 42, 4 GiB DMA window starting at 0 */
+			iommus = <&/iommu  42 0  0x1 0x0>;
+		};
+	};
-- 
1.9.2

             reply	other threads:[~2014-05-23 20:36 UTC|newest]

Thread overview: 215+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-23 20:36 Thierry Reding [this message]
2014-05-23 20:36 ` [PATCH v2] devicetree: Add generic IOMMU device tree bindings Thierry Reding
2014-05-23 20:36 ` Thierry Reding
     [not found] ` <1400877395-4235-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-29 15:52   ` Stephen Warren
2014-05-29 15:52     ` Stephen Warren
2014-05-29 15:52     ` Stephen Warren
2014-05-30  7:30     ` Thierry Reding
2014-05-30  7:30       ` Thierry Reding
2014-05-30 11:27       ` Dave Martin
2014-05-30 11:27         ` Dave Martin
2014-05-30 11:27         ` Dave Martin
     [not found]         ` <20140530112728.GB3949-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-30 19:11           ` Arnd Bergmann
2014-05-30 19:11             ` Arnd Bergmann
2014-05-30 19:11             ` Arnd Bergmann
2014-06-02 10:56             ` Dave Martin
2014-06-02 10:56               ` Dave Martin
2014-06-02 10:56               ` Dave Martin
2014-06-04 21:12         ` Thierry Reding
2014-06-04 21:12           ` Thierry Reding
2014-06-04 21:12           ` Thierry Reding
2014-06-16 12:57           ` Will Deacon
2014-06-16 12:57             ` Will Deacon
2014-06-16 12:57             ` Will Deacon
2014-06-17 11:58             ` Thierry Reding
2014-06-17 11:58               ` Thierry Reding
2014-06-17 11:58               ` Thierry Reding
2014-06-17 12:18               ` Will Deacon
2014-06-17 12:18                 ` Will Deacon
2014-06-17 12:18                 ` Will Deacon
2014-06-17 23:37                 ` Thierry Reding
2014-06-17 23:37                   ` Thierry Reding
2014-06-17 23:37                   ` Thierry Reding
2014-06-18 10:14                   ` Will Deacon
2014-06-18 10:14                     ` Will Deacon
2014-06-18 10:14                     ` Will Deacon
     [not found]                     ` <20140618101439.GF32699-5wv7dgnIgG8@public.gmane.org>
2014-06-20 15:53                       ` Arnd Bergmann
2014-06-20 15:53                         ` Arnd Bergmann
2014-06-20 15:53                         ` Arnd Bergmann
2014-06-20 17:50                         ` Will Deacon
2014-06-20 17:50                           ` Will Deacon
2014-06-20 17:50                           ` Will Deacon
2014-06-20 18:55                           ` Arnd Bergmann
2014-06-20 18:55                             ` Arnd Bergmann
2014-06-20 18:55                             ` Arnd Bergmann
2014-05-30 11:22   ` Dave Martin
2014-05-30 11:22     ` Dave Martin
2014-05-30 11:22     ` Dave Martin
     [not found]     ` <20140530112226.GA3949-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-30 19:01       ` Arnd Bergmann
2014-05-30 19:01         ` Arnd Bergmann
2014-05-30 19:01         ` Arnd Bergmann
2014-06-02 11:44         ` Dave Martin
2014-06-02 11:44           ` Dave Martin
2014-06-02 11:44           ` Dave Martin
2014-06-04 21:32         ` Thierry Reding
2014-06-04 21:32           ` Thierry Reding
2014-06-04 21:32           ` Thierry Reding
2014-06-05  9:42           ` Arnd Bergmann
2014-06-05  9:42             ` Arnd Bergmann
2014-06-05  9:42             ` Arnd Bergmann
  -- strict thread matches above, loose matches on Subject: below --
2014-06-06 22:45 Thierry Reding
2014-06-06 22:45 ` Thierry Reding
2014-06-07 13:22 ` Arnd Bergmann
2014-06-07 13:22   ` Arnd Bergmann
2014-06-07 13:22   ` Arnd Bergmann
2014-06-09 10:49   ` Thierry Reding
2014-06-09 10:49     ` Thierry Reding
2014-06-09 10:49     ` Thierry Reding
2014-05-23 20:33 Thierry Reding
     [not found] ` <1400877218-4113-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-30 13:16   ` Rob Herring
2014-05-30 13:16     ` Rob Herring
2014-05-30 13:16     ` Rob Herring
     [not found]     ` <CAL_JsqKumG1PSFoVfeGpLLG+MjXFeF4aUjun=vv1BJpaxk0Byg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-30 19:06       ` Arnd Bergmann
2014-05-30 19:06         ` Arnd Bergmann
2014-05-30 19:06         ` Arnd Bergmann
2014-05-30 19:29         ` Hiroshi Doyu
2014-05-30 19:29           ` Hiroshi Doyu
2014-05-30 19:29           ` Hiroshi Doyu
2014-05-30 19:54           ` Arnd Bergmann
2014-05-30 19:54             ` Arnd Bergmann
2014-05-30 19:54             ` Arnd Bergmann
2014-06-01  9:55             ` Will Deacon
2014-06-01  9:55               ` Will Deacon
2014-06-01  9:55               ` Will Deacon
     [not found]               ` <20140601095546.GA8625-5wv7dgnIgG8@public.gmane.org>
2014-06-04 13:39                 ` Thierry Reding
2014-06-04 13:39                   ` Thierry Reding
2014-06-04 13:39                   ` Thierry Reding
2014-06-04 13:44             ` Thierry Reding
2014-06-04 13:44               ` Thierry Reding
2014-06-04 13:44               ` Thierry Reding
2014-06-04 13:53               ` Arnd Bergmann
2014-06-04 13:53                 ` Arnd Bergmann
2014-06-04 13:53                 ` Arnd Bergmann
2014-06-04 13:56               ` Will Deacon
2014-06-04 13:56                 ` Will Deacon
2014-06-04 13:56                 ` Will Deacon
     [not found]                 ` <20140604135600.GD6644-5wv7dgnIgG8@public.gmane.org>
2014-06-04 14:01                   ` Arnd Bergmann
2014-06-04 14:01                     ` Arnd Bergmann
2014-06-04 14:01                     ` Arnd Bergmann
2014-06-04 16:39                     ` Will Deacon
2014-06-04 16:39                       ` Will Deacon
2014-06-04 16:39                       ` Will Deacon
2014-05-30 19:31         ` Rob Herring
2014-05-30 19:31           ` Rob Herring
2014-05-30 19:31           ` Rob Herring
     [not found]           ` <CAL_Jsq+tkFNpjSEZboT+o69B_Z3a8e-ZVKaYDmLwtkyYoPy6VQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-30 19:49             ` Arnd Bergmann
2014-05-30 19:49               ` Arnd Bergmann
2014-05-30 19:49               ` Arnd Bergmann
2014-06-02 10:41               ` Dave Martin
2014-06-02 10:41                 ` Dave Martin
2014-06-02 10:41                 ` Dave Martin
     [not found]                 ` <20140602104104.GD3855-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-06-04 14:35                   ` Thierry Reding
2014-06-04 14:35                     ` Thierry Reding
2014-06-04 14:35                     ` Thierry Reding
2014-06-04 16:41                     ` Will Deacon
2014-06-04 16:41                       ` Will Deacon
2014-06-04 16:41                       ` Will Deacon
     [not found]                       ` <20140604164132.GF6644-5wv7dgnIgG8@public.gmane.org>
2014-06-04 21:00                         ` Thierry Reding
2014-06-04 21:00                           ` Thierry Reding
2014-06-04 21:00                           ` Thierry Reding
2014-06-05 19:10                       ` Varun Sethi
2014-06-05 19:10                         ` Varun Sethi
2014-06-05 19:10                         ` Varun Sethi
2014-06-16 15:27                         ` Will Deacon
2014-06-16 15:27                           ` Will Deacon
2014-06-16 15:27                           ` Will Deacon
     [not found]                           ` <20140616152739.GS16758-5wv7dgnIgG8@public.gmane.org>
2014-06-16 16:56                             ` Stuart Yoder
2014-06-16 16:56                               ` Stuart Yoder
2014-06-16 16:56                               ` Stuart Yoder
     [not found]                               ` <8b0492b4697943a0b1f276ef42cc8223-ufbTtyGzTTT8GZusEWM6WuO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-16 17:04                                 ` Will Deacon
2014-06-16 17:04                                   ` Will Deacon
2014-06-16 17:04                                   ` Will Deacon
     [not found]                                   ` <20140616170416.GA16758-5wv7dgnIgG8@public.gmane.org>
2014-06-16 17:30                                     ` Arnd Bergmann
2014-06-16 17:30                                       ` Arnd Bergmann
2014-06-16 17:30                                       ` Arnd Bergmann
2014-06-16 18:53                                     ` Stuart Yoder
2014-06-16 18:53                                       ` Stuart Yoder
2014-06-16 18:53                                       ` Stuart Yoder
     [not found]                                       ` <419e67f783524d208ab3be16bcd94bd9-ufbTtyGzTTT8GZusEWM6WuO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-17 10:26                                         ` Varun Sethi
2014-06-17 10:26                                           ` Varun Sethi
2014-06-17 10:26                                           ` Varun Sethi
     [not found]                                           ` <0587e1f4894546398be0798d2bc2c84f-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-17 10:43                                             ` Will Deacon
2014-06-17 10:43                                               ` Will Deacon
2014-06-17 10:43                                               ` Will Deacon
     [not found]                                               ` <20140617104304.GD13808-5wv7dgnIgG8@public.gmane.org>
2014-06-17 11:21                                                 ` Varun Sethi
2014-06-17 11:21                                                   ` Varun Sethi
2014-06-17 11:21                                                   ` Varun Sethi
     [not found]                                                   ` <32165315f0b84be9948f489fd87bf6a9-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-17 14:50                                                     ` Stuart Yoder
2014-06-17 14:50                                                       ` Stuart Yoder
2014-06-17 14:50                                                       ` Stuart Yoder
2014-06-18  9:29                                                       ` Will Deacon
2014-06-18  9:29                                                         ` Will Deacon
2014-06-18  9:29                                                         ` Will Deacon
2014-06-17 14:39                                           ` Stuart Yoder
2014-06-17 14:39                                             ` Stuart Yoder
2014-06-17 14:39                                             ` Stuart Yoder
2014-06-20 23:16         ` Olav Haugan
2014-06-20 23:16           ` Olav Haugan
2014-06-20 23:16           ` Olav Haugan
2014-06-24  9:18           ` Will Deacon
2014-06-24  9:18             ` Will Deacon
2014-06-24  9:18             ` Will Deacon
     [not found]             ` <20140624091808.GC26013-5wv7dgnIgG8@public.gmane.org>
2014-06-24 17:57               ` Olav Haugan
2014-06-24 17:57                 ` Olav Haugan
2014-06-24 17:57                 ` Olav Haugan
2014-06-24 18:11                 ` Will Deacon
2014-06-24 18:11                   ` Will Deacon
2014-06-24 18:11                   ` Will Deacon
     [not found]                   ` <20140624181150.GB4067-5wv7dgnIgG8@public.gmane.org>
2014-06-24 18:20                     ` Arnd Bergmann
2014-06-24 18:20                       ` Arnd Bergmann
2014-06-24 18:20                       ` Arnd Bergmann
2014-06-25  9:17                       ` Will Deacon
2014-06-25  9:17                         ` Will Deacon
2014-06-25  9:17                         ` Will Deacon
2014-06-25  9:27                         ` Arnd Bergmann
2014-06-25  9:27                           ` Arnd Bergmann
2014-06-25  9:27                           ` Arnd Bergmann
2014-06-25  9:38                           ` Will Deacon
2014-06-25  9:38                             ` Will Deacon
2014-06-25  9:38                             ` Will Deacon
2014-06-25  9:48                             ` Arnd Bergmann
2014-06-25  9:48                               ` Arnd Bergmann
2014-06-25  9:48                               ` Arnd Bergmann
2014-06-25  9:57                               ` Will Deacon
2014-06-25  9:57                                 ` Will Deacon
2014-06-25  9:57                                 ` Will Deacon
     [not found]                                 ` <20140625095735.GI6153-5wv7dgnIgG8@public.gmane.org>
2014-06-25 10:12                                   ` Arnd Bergmann
2014-06-25 10:12                                     ` Arnd Bergmann
2014-06-25 10:12                                     ` Arnd Bergmann
2014-06-25 10:14                                     ` Will Deacon
2014-06-25 10:14                                       ` Will Deacon
2014-06-25 10:14                                       ` Will Deacon
2014-06-24 21:35                     ` Olav Haugan
2014-06-24 21:35                       ` Olav Haugan
2014-06-24 21:35                       ` Olav Haugan
     [not found]                       ` <53A9EF3A.2070704-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-06-25  9:18                         ` Will Deacon
2014-06-25  9:18                           ` Will Deacon
2014-06-25  9:18                           ` Will Deacon
     [not found]                           ` <20140625091858.GG6153-5wv7dgnIgG8@public.gmane.org>
2014-06-27 22:23                             ` Olav Haugan
2014-06-27 22:23                               ` Olav Haugan
2014-06-27 22:23                               ` Olav Haugan
     [not found]                               ` <53ADEEDF.7060902-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-06-30  9:52                                 ` Will Deacon
2014-06-30  9:52                                   ` Will Deacon
2014-06-30  9:52                                   ` Will Deacon
2014-07-09  1:07                                   ` Olav Haugan
2014-07-09  1:07                                     ` Olav Haugan
2014-07-09  1:07                                     ` Olav Haugan
     [not found]                                     ` <53BC95DA.1010500-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-07-09 10:54                                       ` Will Deacon
2014-07-09 10:54                                         ` Will Deacon
2014-07-09 10:54                                         ` Will Deacon
     [not found]                                         ` <20140709105441.GE9485-5wv7dgnIgG8@public.gmane.org>
2014-07-10 22:32                                           ` Olav Haugan
2014-07-10 22:32                                             ` Olav Haugan
2014-07-10 22:32                                             ` Olav Haugan
2014-07-11 12:24                                             ` Will Deacon
2014-07-11 12:24                                               ` Will Deacon
2014-07-11 12:24                                               ` Will Deacon

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=1400877395-4235-1-git-send-email-thierry.reding@gmail.com \
    --to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=Dave.Martin-5wv7dgnIgG8@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
    --cc=pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.