From: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
To: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"tirumalesh.chalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org"
<tirumalesh.chalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>,
"Richter,
Robert"
<Robert.Richter-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>,
"Chintakuntla,
Radha"
<Radha.Chintakuntla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Lorenzo Pieralisi
<Lorenzo.Pieralisi-5wv7dgnIgG8@public.gmane.org>,
"arnd-r2nGTMty4D4@public.gmane.org"
<arnd-r2nGTMty4D4@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org"
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
"thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org"
<thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
"treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org"
<treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"majun258-hv44wF8Li93QT0dZR+AlfA@public.gmane.org"
<majun258-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
Date: Fri, 4 Sep 2015 15:33:35 -0700 [thread overview]
Message-ID: <55EA1C3F.1030300@caviumnetworks.com> (raw)
In-Reply-To: <55B5E8C1.4030707-5wv7dgnIgG8@public.gmane.org>
Hi Mark,
First of all: Thanks for working on this.
I now have a prototype implementation for irq-gic-v3-its.c that is using
this binding on Cavium's ThunderX platform.
Q: Have you guys had any more thoughts on this that might require
changing the binding?
If not, I will be sending out my patches for your consideration.
Thanks,
David Daney
On 07/27/2015 01:16 AM, Marc Zyngier wrote:
> On 23/07/15 17:52, Mark Rutland wrote:
>> Currently msi-parent is used by a few bindings to describe the
>> relationship between a PCI root complex and a single MSI controller, but
>> this property does not have a generic binding document.
>>
>> Additionally, msi-parent is insufficient to describe more complex
>> relationships between MSI controllers and devices under a root complex,
>> where devices may be able to target multiple MSI controllers, or where
>> MSI controllers use (non-probeable) sideband information to distinguish
>> devices.
>>
>> This patch adds a generic binding for mapping PCI devices to MSI
>> controllers. This document covers msi-parent, and a new msi-map property
>> (specific to PCI*) which may be used to map devices (identified by their
>> Requester ID) to sideband data for each MSI controller that they may
>> target.
>>
>> Signed-off-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Acked-by: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++++++++++++++++++++++
>> 1 file changed, 220 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt b/Documentation/devicetree/bindings/pci/pci-msi.txt
>> new file mode 100644
>> index 0000000..9b3cc81
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/pci-msi.txt
>> @@ -0,0 +1,220 @@
>> +This document describes the generic device tree binding for describing the
>> +relationship between PCI devices and MSI controllers.
>> +
>> +Each PCI device under a root complex is uniquely identified by its Requester ID
>> +(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
>> +Function number.
>> +
>> +For the purpose of this document, when treated as a numeric value, a RID is
>> +formatted such that:
>> +
>> +* Bits [15:8] are the Bus number.
>> +* Bits [7:3] are the Device number.
>> +* Bits [2:0] are the Function number.
>> +* Any other bits required for padding must be zero.
>> +
>> +MSIs may be distinguished in part through the use of sideband data accompanying
>> +writes. In the case of PCI devices, this sideband data may be derived from the
>> +Requester ID. A mechanism is required to associate a device with both the MSI
>> +controllers it can address, and the sideband data that will be associated with
>> +its writes to those controllers.
>> +
>> +For generic MSI bindings, see
>> +Documentation/devicetree/bindings/interrupt-controller/msi.txt.
>> +
>> +
>> +PCI root complex
>> +================
>> +
>> +Optional properties
>> +-------------------
>> +
>> +- msi-map: Maps a Requester ID to an MSI controller and associated
>> + msi-specifier data. The property is an arbitrary number of tuples of
>> + (rid-base,msi-controller,msi-base,length), where:
>> +
>> + * rid-base is a single cell describing the first RID matched by the entry.
>> +
>> + * msi-controller is a single phandle to an MSI controller
>> +
>> + * msi-base is an msi-specifier describing the msi-specifier produced for the
>> + first RID matched by the entry.
>> +
>> + * length is a single cell describing how many consecutive RIDs are matched
>> + following the rid-base.
>> +
>> + Any RID r in the interval [rid-base, rid-base + length) is associated with
>> + the listed msi-controller, with the msi-specifier (r - rid-base + msi-base).
>> +
>> +- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped
>> + to an msi-specifier per the msi-map property.
>> +
>> +- msi-parent: Describes the MSI parent of the root complex itself. Where
>> + the root complex and MSI controller do not pass sideband data with MSI
>> + writes, this property may be used to describe the MSI controller(s)
>> + used by PCI devices under the root complex, if defined as such in the
>> + binding for the root complex.
>
> Right, this is where I'd expect some details about #msi-cells. Is it
> meant to be ignored? The lack of symmetry between the PCI and non-PCI
> use cases feels a bit inelegant (not to mention that it precludes having
> an unified parser for both cases).
>
> This otherwise looks good to me.
>
> Thanks,
>
> M.
>
WARNING: multiple messages have this Message-ID (diff)
From: ddaney@caviumnetworks.com (David Daney)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
Date: Fri, 4 Sep 2015 15:33:35 -0700 [thread overview]
Message-ID: <55EA1C3F.1030300@caviumnetworks.com> (raw)
In-Reply-To: <55B5E8C1.4030707@arm.com>
Hi Mark,
First of all: Thanks for working on this.
I now have a prototype implementation for irq-gic-v3-its.c that is using
this binding on Cavium's ThunderX platform.
Q: Have you guys had any more thoughts on this that might require
changing the binding?
If not, I will be sending out my patches for your consideration.
Thanks,
David Daney
On 07/27/2015 01:16 AM, Marc Zyngier wrote:
> On 23/07/15 17:52, Mark Rutland wrote:
>> Currently msi-parent is used by a few bindings to describe the
>> relationship between a PCI root complex and a single MSI controller, but
>> this property does not have a generic binding document.
>>
>> Additionally, msi-parent is insufficient to describe more complex
>> relationships between MSI controllers and devices under a root complex,
>> where devices may be able to target multiple MSI controllers, or where
>> MSI controllers use (non-probeable) sideband information to distinguish
>> devices.
>>
>> This patch adds a generic binding for mapping PCI devices to MSI
>> controllers. This document covers msi-parent, and a new msi-map property
>> (specific to PCI*) which may be used to map devices (identified by their
>> Requester ID) to sideband data for each MSI controller that they may
>> target.
>>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: David Daney <david.daney@cavium.com>
>> ---
>> Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++++++++++++++++++++++
>> 1 file changed, 220 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt b/Documentation/devicetree/bindings/pci/pci-msi.txt
>> new file mode 100644
>> index 0000000..9b3cc81
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/pci-msi.txt
>> @@ -0,0 +1,220 @@
>> +This document describes the generic device tree binding for describing the
>> +relationship between PCI devices and MSI controllers.
>> +
>> +Each PCI device under a root complex is uniquely identified by its Requester ID
>> +(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
>> +Function number.
>> +
>> +For the purpose of this document, when treated as a numeric value, a RID is
>> +formatted such that:
>> +
>> +* Bits [15:8] are the Bus number.
>> +* Bits [7:3] are the Device number.
>> +* Bits [2:0] are the Function number.
>> +* Any other bits required for padding must be zero.
>> +
>> +MSIs may be distinguished in part through the use of sideband data accompanying
>> +writes. In the case of PCI devices, this sideband data may be derived from the
>> +Requester ID. A mechanism is required to associate a device with both the MSI
>> +controllers it can address, and the sideband data that will be associated with
>> +its writes to those controllers.
>> +
>> +For generic MSI bindings, see
>> +Documentation/devicetree/bindings/interrupt-controller/msi.txt.
>> +
>> +
>> +PCI root complex
>> +================
>> +
>> +Optional properties
>> +-------------------
>> +
>> +- msi-map: Maps a Requester ID to an MSI controller and associated
>> + msi-specifier data. The property is an arbitrary number of tuples of
>> + (rid-base,msi-controller,msi-base,length), where:
>> +
>> + * rid-base is a single cell describing the first RID matched by the entry.
>> +
>> + * msi-controller is a single phandle to an MSI controller
>> +
>> + * msi-base is an msi-specifier describing the msi-specifier produced for the
>> + first RID matched by the entry.
>> +
>> + * length is a single cell describing how many consecutive RIDs are matched
>> + following the rid-base.
>> +
>> + Any RID r in the interval [rid-base, rid-base + length) is associated with
>> + the listed msi-controller, with the msi-specifier (r - rid-base + msi-base).
>> +
>> +- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped
>> + to an msi-specifier per the msi-map property.
>> +
>> +- msi-parent: Describes the MSI parent of the root complex itself. Where
>> + the root complex and MSI controller do not pass sideband data with MSI
>> + writes, this property may be used to describe the MSI controller(s)
>> + used by PCI devices under the root complex, if defined as such in the
>> + binding for the root complex.
>
> Right, this is where I'd expect some details about #msi-cells. Is it
> meant to be ignored? The lack of symmetry between the PCI and non-PCI
> use cases feels a bit inelegant (not to mention that it precludes having
> an unified parser for both cases).
>
> This otherwise looks good to me.
>
> Thanks,
>
> M.
>
WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
"tirumalesh.chalamarla@caviumnetworks.com"
<tirumalesh.chalamarla@caviumnetworks.com>,
"Richter, Robert" <Robert.Richter@caviumnetworks.com>,
"Chintakuntla, Radha" <Radha.Chintakuntla@caviumnetworks.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Will Deacon <Will.Deacon@arm.com>,
Robin Murphy <Robin.Murphy@arm.com>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"treding@nvidia.com" <treding@nvidia.com>,
"majun258@huawei.com" <majun258@huawei.com>,
"thunder.leizhen@huawei.com" <thunder.leizhen@huawei.com>,
"laurent.pinchart@ideasonboard.com"
<laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
Date: Fri, 4 Sep 2015 15:33:35 -0700 [thread overview]
Message-ID: <55EA1C3F.1030300@caviumnetworks.com> (raw)
In-Reply-To: <55B5E8C1.4030707@arm.com>
Hi Mark,
First of all: Thanks for working on this.
I now have a prototype implementation for irq-gic-v3-its.c that is using
this binding on Cavium's ThunderX platform.
Q: Have you guys had any more thoughts on this that might require
changing the binding?
If not, I will be sending out my patches for your consideration.
Thanks,
David Daney
On 07/27/2015 01:16 AM, Marc Zyngier wrote:
> On 23/07/15 17:52, Mark Rutland wrote:
>> Currently msi-parent is used by a few bindings to describe the
>> relationship between a PCI root complex and a single MSI controller, but
>> this property does not have a generic binding document.
>>
>> Additionally, msi-parent is insufficient to describe more complex
>> relationships between MSI controllers and devices under a root complex,
>> where devices may be able to target multiple MSI controllers, or where
>> MSI controllers use (non-probeable) sideband information to distinguish
>> devices.
>>
>> This patch adds a generic binding for mapping PCI devices to MSI
>> controllers. This document covers msi-parent, and a new msi-map property
>> (specific to PCI*) which may be used to map devices (identified by their
>> Requester ID) to sideband data for each MSI controller that they may
>> target.
>>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: David Daney <david.daney@cavium.com>
>> ---
>> Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++++++++++++++++++++++
>> 1 file changed, 220 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt b/Documentation/devicetree/bindings/pci/pci-msi.txt
>> new file mode 100644
>> index 0000000..9b3cc81
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/pci-msi.txt
>> @@ -0,0 +1,220 @@
>> +This document describes the generic device tree binding for describing the
>> +relationship between PCI devices and MSI controllers.
>> +
>> +Each PCI device under a root complex is uniquely identified by its Requester ID
>> +(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
>> +Function number.
>> +
>> +For the purpose of this document, when treated as a numeric value, a RID is
>> +formatted such that:
>> +
>> +* Bits [15:8] are the Bus number.
>> +* Bits [7:3] are the Device number.
>> +* Bits [2:0] are the Function number.
>> +* Any other bits required for padding must be zero.
>> +
>> +MSIs may be distinguished in part through the use of sideband data accompanying
>> +writes. In the case of PCI devices, this sideband data may be derived from the
>> +Requester ID. A mechanism is required to associate a device with both the MSI
>> +controllers it can address, and the sideband data that will be associated with
>> +its writes to those controllers.
>> +
>> +For generic MSI bindings, see
>> +Documentation/devicetree/bindings/interrupt-controller/msi.txt.
>> +
>> +
>> +PCI root complex
>> +================
>> +
>> +Optional properties
>> +-------------------
>> +
>> +- msi-map: Maps a Requester ID to an MSI controller and associated
>> + msi-specifier data. The property is an arbitrary number of tuples of
>> + (rid-base,msi-controller,msi-base,length), where:
>> +
>> + * rid-base is a single cell describing the first RID matched by the entry.
>> +
>> + * msi-controller is a single phandle to an MSI controller
>> +
>> + * msi-base is an msi-specifier describing the msi-specifier produced for the
>> + first RID matched by the entry.
>> +
>> + * length is a single cell describing how many consecutive RIDs are matched
>> + following the rid-base.
>> +
>> + Any RID r in the interval [rid-base, rid-base + length) is associated with
>> + the listed msi-controller, with the msi-specifier (r - rid-base + msi-base).
>> +
>> +- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped
>> + to an msi-specifier per the msi-map property.
>> +
>> +- msi-parent: Describes the MSI parent of the root complex itself. Where
>> + the root complex and MSI controller do not pass sideband data with MSI
>> + writes, this property may be used to describe the MSI controller(s)
>> + used by PCI devices under the root complex, if defined as such in the
>> + binding for the root complex.
>
> Right, this is where I'd expect some details about #msi-cells. Is it
> meant to be ignored? The lack of symmetry between the PCI and non-PCI
> use cases feels a bit inelegant (not to mention that it precludes having
> an unified parser for both cases).
>
> This otherwise looks good to me.
>
> Thanks,
>
> M.
>
next prev parent reply other threads:[~2015-09-04 22:33 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-23 16:52 [PATCH 0/3] Generic PCI MSI + IOMMU topology bindings Mark Rutland
2015-07-23 16:52 ` Mark Rutland
2015-07-23 16:52 ` Mark Rutland
[not found] ` <1437670365-20704-1-git-send-email-mark.rutland-5wv7dgnIgG8@public.gmane.org>
2015-07-23 16:52 ` [PATCH 1/3] Docs: dt: add generic MSI bindings Mark Rutland
2015-07-23 16:52 ` Mark Rutland
2015-07-23 16:52 ` Mark Rutland
2015-07-27 8:02 ` Marc Zyngier
2015-07-27 8:02 ` Marc Zyngier
[not found] ` <55B5E5A6.2030509-5wv7dgnIgG8@public.gmane.org>
2015-07-27 9:46 ` Mark Rutland
2015-07-27 9:46 ` Mark Rutland
2015-07-27 9:46 ` Mark Rutland
2015-08-03 10:44 ` Marc Zyngier
2015-08-03 10:44 ` Marc Zyngier
2015-08-03 10:44 ` Marc Zyngier
[not found] ` <1437670365-20704-2-git-send-email-mark.rutland-5wv7dgnIgG8@public.gmane.org>
2015-07-23 18:26 ` David Daney
2015-07-23 18:26 ` David Daney
2015-07-23 18:26 ` David Daney
2015-07-24 7:04 ` Marc Zyngier
2015-07-24 7:04 ` Marc Zyngier
2015-08-05 16:51 ` Mark Rutland
2015-08-05 16:51 ` Mark Rutland
2015-08-05 16:51 ` Mark Rutland
2015-08-06 7:56 ` Marc Zyngier
2015-08-06 7:56 ` Marc Zyngier
2015-08-06 7:56 ` Marc Zyngier
2015-08-24 10:17 ` Mark Rutland
2015-08-24 10:17 ` Mark Rutland
2015-08-24 10:17 ` Mark Rutland
2015-08-24 13:37 ` Rob Herring
2015-08-24 13:37 ` Rob Herring
2015-08-24 13:37 ` Rob Herring
[not found] ` <CAL_Jsq+-xKsfBwqjHnSKPxtO1muu-NLEHZTTLpSqw=sBuU1Gjw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-24 13:47 ` Mark Rutland
2015-08-24 13:47 ` Mark Rutland
2015-08-24 13:47 ` Mark Rutland
2015-07-23 16:52 ` [PATCH 2/3] Docs: dt: Add PCI MSI map bindings Mark Rutland
2015-07-23 16:52 ` Mark Rutland
2015-07-23 16:52 ` Mark Rutland
[not found] ` <1437670365-20704-3-git-send-email-mark.rutland-5wv7dgnIgG8@public.gmane.org>
2015-07-24 23:27 ` Chalamarla, Tirumalesh
2015-07-24 23:27 ` Chalamarla, Tirumalesh
2015-07-24 23:27 ` Chalamarla, Tirumalesh
[not found] ` <FD9C4916-6BDC-40F2-A273-91BFBD3B0075-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2015-07-27 9:16 ` Mark Rutland
2015-07-27 9:16 ` Mark Rutland
2015-07-27 9:16 ` Mark Rutland
2015-07-27 8:16 ` Marc Zyngier
2015-07-27 8:16 ` Marc Zyngier
2015-07-27 8:16 ` Marc Zyngier
[not found] ` <55B5E8C1.4030707-5wv7dgnIgG8@public.gmane.org>
2015-09-04 22:33 ` David Daney [this message]
2015-09-04 22:33 ` David Daney
2015-09-04 22:33 ` David Daney
[not found] ` <55EA1C3F.1030300-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2015-09-07 18:05 ` Mark Rutland
2015-09-07 18:05 ` Mark Rutland
2015-09-07 18:05 ` Mark Rutland
2015-09-08 15:53 ` Stuart Yoder
2015-09-08 15:53 ` Stuart Yoder
2015-09-08 15:53 ` Stuart Yoder
2015-09-07 17:56 ` Mark Rutland
2015-09-07 17:56 ` Mark Rutland
2015-09-07 17:56 ` Mark Rutland
2015-08-05 16:39 ` Varun Sethi
2015-08-05 16:39 ` Varun Sethi
2015-08-05 16:39 ` Varun Sethi
[not found] ` <BN1PR0301MB06277FDA6EB34E77B557CA75EA750-RQSpjbwlmjSD1ymB6+i1+JwN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2015-08-06 17:38 ` Mark Rutland
2015-08-06 17:38 ` Mark Rutland
2015-08-06 17:38 ` Mark Rutland
2015-08-08 15:06 ` Varun Sethi
2015-08-08 15:06 ` Varun Sethi
2015-08-08 15:06 ` Varun Sethi
[not found] ` <CALRxmdA32xiSX7DDKAJPLR8=bh_9j-6MN124u4KjYGRT8bAKNg@mail.gmail.com>
[not found] ` <CALRxmdA32xiSX7DDKAJPLR8=bh_9j-6MN124u4KjYGRT8bAKNg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-05 19:53 ` Stuart Yoder
2015-08-05 19:53 ` Stuart Yoder
2015-08-05 19:53 ` Stuart Yoder
[not found] ` <CY1PR0301MB07486794749E499F71BDFCD287750-YrwGdl+PljkyhdUd3pz1uJwN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2015-08-06 18:14 ` Mark Rutland
2015-08-06 18:14 ` Mark Rutland
2015-08-06 18:14 ` Mark Rutland
2015-08-06 19:46 ` Stuart Yoder
2015-08-06 19:46 ` Stuart Yoder
2015-08-06 19:46 ` Stuart Yoder
2015-07-23 16:52 ` [PATCH 3/3] Docs: dt: add PCI IOMMU " Mark Rutland
2015-07-23 16:52 ` Mark Rutland
2015-07-23 16:52 ` Mark Rutland
[not found] ` <1437670365-20704-4-git-send-email-mark.rutland-5wv7dgnIgG8@public.gmane.org>
2015-07-24 12:23 ` Robin Murphy
2015-07-24 12:23 ` Robin Murphy
2015-07-24 12:23 ` Robin Murphy
[not found] ` <55B22E5B.7080208-5wv7dgnIgG8@public.gmane.org>
2015-07-24 13:26 ` Mark Rutland
2015-07-24 13:26 ` Mark Rutland
2015-07-24 13:26 ` Mark Rutland
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=55EA1C3F.1030300@caviumnetworks.com \
--to=ddaney-m3mlkvoiwjvv6pq1l3v1odbpr1lh4cv8@public.gmane.org \
--cc=Lorenzo.Pieralisi-5wv7dgnIgG8@public.gmane.org \
--cc=Radha.Chintakuntla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \
--cc=Robert.Richter-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \
--cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=majun258-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=tirumalesh.chalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \
--cc=treding-DDmLM1+adcrQT0dZR+AlfA@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.