subject:"\[PATCH 2\/3\] Docs\: dt\: Add PCI MSI map bindings"

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-09-08 Thread Stuart Yoder

> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Monday, September 07, 2015 1:05 PM
> To: David Daney
> Cc: Marc Zyngier; tirumalesh.chalama...@caviumnetworks.com; Richter, Robert; 
> Chintakuntla, Radha;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> io...@lists.linux-foundation.org; linux-arm-
> ker...@lists.infradead.org; Will Deacon; Robin Murphy; Lorenzo Pieralisi; 
> a...@arndb.de; tred...@nvidia.com;
> majun...@huawei.com; thunder.leiz...@huawei.com; 
> laurent.pinch...@ideasonboard.com; Yoder Stuart-B08248
> Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
> 
> On Fri, Sep 04, 2015 at 11:33:35PM +0100, David Daney wrote:
> > Hi Mark,
> 
> Hi David,
> 
> > 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?
> 
> Having discussed this with Stuart and others at Linux Plumbers, I think
> that the binding is sufficient, and unlikely to change greatly unless
> there is a strong objection (Stuart, please correct me if I am wrong).
> 
> Per Marc's comments there are probably some edge cases and/or wording
> details to sort out, but I think the common/simple case is sorted. I'll
> send a v2 once those have been settled.

I think the binding as-is, is sufficient for the static description
of RID to SID.

I think the binding can be extended in a backwards compatible way
to support dynamic RID->SID mappings if we need that in the future.

The case that we (Freescale) are concerned with are where someone
plugs an SRIOV card into an SoC and enables, say 64 VFs.  It's
like hot-plugging 64 new PCI devices at once.  If all those devices
that show up belong to the host they belong to one 'isolation context' and
could share the same streamID, same SMMU mappings, and the same
ITT in the GIC ITS.  So a static mapping could work.

But, as soon as I want to assign VF#5 to a virtual machine I need
a new RID->SID mapping for VF#5.  To require firmware to do that mapping
ahead of time is a _real_ pain.  I think longer term we need some
mechanism to allow lazy, dynamic RID->SID mappings by Linux.

We can start with the static approach, but we need to keep in the
back of our minds that there may be cases in the near future
where a static mapping is too inflexible.

Thanks,
Stuart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-09-08 Thread Stuart Yoder

> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Monday, September 07, 2015 1:05 PM
> To: David Daney
> Cc: Marc Zyngier; tirumalesh.chalama...@caviumnetworks.com; Richter, Robert; 
> Chintakuntla, Radha;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> io...@lists.linux-foundation.org; linux-arm-
> ker...@lists.infradead.org; Will Deacon; Robin Murphy; Lorenzo Pieralisi; 
> a...@arndb.de; tred...@nvidia.com;
> majun...@huawei.com; thunder.leiz...@huawei.com; 
> laurent.pinch...@ideasonboard.com; Yoder Stuart-B08248
> Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
> 
> On Fri, Sep 04, 2015 at 11:33:35PM +0100, David Daney wrote:
> > Hi Mark,
> 
> Hi David,
> 
> > 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?
> 
> Having discussed this with Stuart and others at Linux Plumbers, I think
> that the binding is sufficient, and unlikely to change greatly unless
> there is a strong objection (Stuart, please correct me if I am wrong).
> 
> Per Marc's comments there are probably some edge cases and/or wording
> details to sort out, but I think the common/simple case is sorted. I'll
> send a v2 once those have been settled.

I think the binding as-is, is sufficient for the static description
of RID to SID.

I think the binding can be extended in a backwards compatible way
to support dynamic RID->SID mappings if we need that in the future.

The case that we (Freescale) are concerned with are where someone
plugs an SRIOV card into an SoC and enables, say 64 VFs.  It's
like hot-plugging 64 new PCI devices at once.  If all those devices
that show up belong to the host they belong to one 'isolation context' and
could share the same streamID, same SMMU mappings, and the same
ITT in the GIC ITS.  So a static mapping could work.

But, as soon as I want to assign VF#5 to a virtual machine I need
a new RID->SID mapping for VF#5.  To require firmware to do that mapping
ahead of time is a _real_ pain.  I think longer term we need some
mechanism to allow lazy, dynamic RID->SID mappings by Linux.

We can start with the static approach, but we need to keep in the
back of our minds that there may be cases in the near future
where a static mapping is too inflexible.

Thanks,
Stuart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-09-07 Thread Mark Rutland

On Fri, Sep 04, 2015 at 11:33:35PM +0100, David Daney wrote:
> Hi Mark,

Hi David,

> 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?

Having discussed this with Stuart and others at Linux Plumbers, I think
that the binding is sufficient, and unlikely to change greatly unless
there is a strong objection (Stuart, please correct me if I am wrong).

Per Marc's comments there are probably some edge cases and/or wording
details to sort out, but I think the common/simple case is sorted. I'll
send a v2 once those have been settled.

> If not, I will be sending out my patches for your consideration.

Please do!

> 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 
> 
> Acked-by: David Daney 

Thanks!

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-09-07 Thread Mark Rutland

> > +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).

I would expect that the msi-parent's #msi-cells could be non-zero.

As I see it, there are three possible interpretations (and the choice
between these would be specific to a PCI root complex):

(1) Devices under the root complex generate MSIs via the MSI parent,
using common sideband data described in the msi cells (and therefore
cannot be distingushed from each other).

(2) The root complex itself generates MSIs via the MSI parent, with any
sideband data described in the msi cells.

(3) Both the root complex and devices underneath it generate MSIs via
the MSI parent, using common sideband data described in the msi
cells (and therefore cannot be distinguished from each other).

Of these, (1) is the common case today, though (2) would be more in
keeping with how this style of property usually works.

I'm not sure how to capture that.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-09-07 Thread Mark Rutland

> > +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).

I would expect that the msi-parent's #msi-cells could be non-zero.

As I see it, there are three possible interpretations (and the choice
between these would be specific to a PCI root complex):

(1) Devices under the root complex generate MSIs via the MSI parent,
using common sideband data described in the msi cells (and therefore
cannot be distingushed from each other).

(2) The root complex itself generates MSIs via the MSI parent, with any
sideband data described in the msi cells.

(3) Both the root complex and devices underneath it generate MSIs via
the MSI parent, using common sideband data described in the msi
cells (and therefore cannot be distinguished from each other).

Of these, (1) is the common case today, though (2) would be more in
keeping with how this style of property usually works.

I'm not sure how to capture that.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-09-07 Thread Mark Rutland

On Fri, Sep 04, 2015 at 11:33:35PM +0100, David Daney wrote:
> Hi Mark,

Hi David,

> 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?

Having discussed this with Stuart and others at Linux Plumbers, I think
that the binding is sufficient, and unlikely to change greatly unless
there is a strong objection (Stuart, please correct me if I am wrong).

Per Marc's comments there are probably some edge cases and/or wording
details to sort out, but I think the common/simple case is sorted. I'll
send a v2 once those have been settled.

> If not, I will be sending out my patches for your consideration.

Please do!

> 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 
> 
> Acked-by: David Daney 

Thanks!

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-09-04 Thread David Daney


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 


Acked-by: David Daney 



---
  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 000..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.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-09-04 Thread David Daney


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 


Acked-by: David Daney 



---
  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 000..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.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-08 Thread Varun Sethi

Hi Mark,
Thanks for the response. Please find my comments inline.

Regards
Varun

> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Thursday, August 06, 2015 11:09 PM
> To: Sethi Varun-B16395
> Cc: devicet...@vger.kernel.org; Lorenzo Pieralisi; a...@arndb.de; Marc
> Zyngier; Will Deacon; linux-kernel@vger.kernel.org;
> dda...@caviumnetworks.com; io...@lists.linux-foundation.org;
> tirumalesh.chalama...@caviumnetworks.com;
> laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com;
> tred...@nvidia.com; linux-arm-ker...@lists.infradead.org;
> majun...@huawei.com; Yoder Stuart-B08248
> Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
> 
> On Wed, Aug 05, 2015 at 05:39:33PM +0100, Varun Sethi wrote:
> > Hi Mark
> > Thanks for the patch. Please find my comment inline.
> >
> > Regards
> > Varun
> >
> > > -Original Message-
> > > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> > > boun...@lists.linux-foundation.org] On Behalf Of Mark Rutland
> > > Sent: Thursday, July 23, 2015 10:23 PM
> > > To: devicet...@vger.kernel.org
> > > Cc: Mark Rutland; lorenzo.pieral...@arm.com; a...@arndb.de;
> > > marc.zyng...@arm.com; will.dea...@arm.com; linux-
> > > ker...@vger.kernel.org; dda...@caviumnetworks.com;
> > > iommu@lists.linux- foundation.org;
> > > tirumalesh.chalama...@caviumnetworks.com;
> > > laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com;
> > > tred...@nvidia.com; linux-arm-ker...@lists.infradead.org;
> > > majun...@huawei.com
> > > Subject: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
> > >
> > > 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 
> > > ---
> > >  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 000..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
> > > +

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-08 Thread Varun Sethi

Hi Mark,
Thanks for the response. Please find my comments inline.

Regards
Varun

 -Original Message-
 From: Mark Rutland [mailto:mark.rutl...@arm.com]
 Sent: Thursday, August 06, 2015 11:09 PM
 To: Sethi Varun-B16395
 Cc: devicet...@vger.kernel.org; Lorenzo Pieralisi; a...@arndb.de; Marc
 Zyngier; Will Deacon; linux-kernel@vger.kernel.org;
 dda...@caviumnetworks.com; io...@lists.linux-foundation.org;
 tirumalesh.chalama...@caviumnetworks.com;
 laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com;
 tred...@nvidia.com; linux-arm-ker...@lists.infradead.org;
 majun...@huawei.com; Yoder Stuart-B08248
 Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
 
 On Wed, Aug 05, 2015 at 05:39:33PM +0100, Varun Sethi wrote:
  Hi Mark
  Thanks for the patch. Please find my comment inline.
 
  Regards
  Varun
 
   -Original Message-
   From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
   boun...@lists.linux-foundation.org] On Behalf Of Mark Rutland
   Sent: Thursday, July 23, 2015 10:23 PM
   To: devicet...@vger.kernel.org
   Cc: Mark Rutland; lorenzo.pieral...@arm.com; a...@arndb.de;
   marc.zyng...@arm.com; will.dea...@arm.com; linux-
   ker...@vger.kernel.org; dda...@caviumnetworks.com;
   iommu@lists.linux- foundation.org;
   tirumalesh.chalama...@caviumnetworks.com;
   laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com;
   tred...@nvidia.com; linux-arm-ker...@lists.infradead.org;
   majun...@huawei.com
   Subject: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
  
   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.rutl...@arm.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 000..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:
  [varun] How would we account for hot plug PCI devices and SR-IOV use
 cases, with the rid base and length?
 
 For hotplug, you simply need the mapping from RID to msi-specifier to be
 defined in advance in the DT, for the set of RIDs that could possibly occur.
 
 For SR-IOV, are you asking about ARI? I should update the description of the
 RID to describe that for ARI it has the format:
 
 * Bits [15:8] are the Bus number
 * Bits [7:0] are the Identifier
 
 Other than that, the handling would be identical to the non-ARI case.
 
 What else am I missing?
 
  How do we take in to account for a PCIe bridge, while setting up the
 requestor ID base and length?
 
 I'm not sure I follow

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-06 Thread Stuart Yoder



> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Thursday, August 06, 2015 1:15 PM
> To: Yoder Stuart-B08248; Marc Zyngier; Will Deacon
> Cc: devicet...@vger.kernel.org; Lorenzo Pieralisi; a...@arndb.de; 
> linux-kernel@vger.kernel.org;
> dda...@caviumnetworks.com; io...@lists.linux-foundation.org; 
> tirumalesh.chalama...@caviumnetworks.com;
> laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com; 
> tred...@nvidia.com; linux-arm-
> ker...@lists.infradead.org; majun...@huawei.com
> Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
> 
> [...]
> 
> > > +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.
> >
> > Can we extend the msi-map-mask definition to say:  "A mask value of 0x0 is 
> > valid
> > and indicates that no RIDs are _currently_ mapped to any msi-specifier."
> 
> That would break a valid case of the mask being all zeroes.
> 
> Consider the case that all RIDs get mapped to a single msi-specifier;
> the obvious way to write that is:
> 
> msi-map-mask = <0x>;
> msi-map = <0x  (msi-specifier) 1>;
> 
> In this case all RIDS are always mapped to the single msi-specifier.

Does it really break that case?

We could have this (your example):

  msi-map-mask = <0x>;
  msi-map = <0x  7 1>;  // map all RIDs to msi-spec 7

Or, my example:

  msi-map-mask = <0x>;
  msi-map = <0x  7 4>;  // all RIDs map to any of msi-spec 7,8,9,10

> > We have an SoC with a programmable hardware table in the PCI controller 
> > that maps
> > requester ID to stream ID, so the overall msi-map (and iommu-map) 
> > definition fit
> > into that scheme.  But, we would like to be able make the RID->stream-ID 
> > mapping
> > decision _lazily_, in Linux, based on actual usage of PCI devices.
> 
> Dynamically programming the mapping is at odds to this binding. I don't
> see how that can fit.

My example above obviously doesn't make sense for a static
binding, but can't we allow both a mask value of 0x0 and
a length > 1 at the same time.
 
> Why can the RID->SID mapping not be statically configured prior to
> entering the OS?

The problem for us is the limited number of SIDs available on our SoC.  We
have an SMMU-500 with 128 SIDs / 64-contexts total.  An SR-IOV card could
enable VFs dynamically and suddenly there are 64 new RIDs on a PCI
bus.  There are 4 PCI controllers and firmware doesn't know what
might be enabled on which bus.  We run out of available SIDs.

In that example we want all RIDs mapped to one SID by default, but want
the option of setting our dynamic RID->SID table for a situation where
say someone assigns a VF to a KVM VM and thus needs an SID to use
for SMMU mappings.

I think the binding can work for the dynamic case as long as we allow
the example I showed above.  So, I would propose changing
my proposed text to:

   "A mask value of 0x0 is valid and indicates that all RIDS map to
the specified msi-specifier(s).  If the mask is 0x0 and length > 1
it indicates that all RIDs map to any of the msi-specifiers with
the actual mapping left unspecified by the msi-map property."

Thanks,
Stuart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-06 Thread Mark Rutland

[...]

> > +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.
> 
> Can we extend the msi-map-mask definition to say:  "A mask value of 0x0 is 
> valid
> and indicates that no RIDs are _currently_ mapped to any msi-specifier."

That would break a valid case of the mask being all zeroes.

Consider the case that all RIDs get mapped to a single msi-specifier;
the obvious way to write that is:

msi-map-mask = <0x>;
msi-map = <0x  (msi-specifier) 1>;

In this case all RIDS are always mapped to the single msi-specifier.

> We have an SoC with a programmable hardware table in the PCI controller that 
> maps
> requester ID to stream ID, so the overall msi-map (and iommu-map) definition 
> fit
> into that scheme.  But, we would like to be able make the RID->stream-ID 
> mapping
> decision _lazily_, in Linux, based on actual usage of PCI devices.

Dynamically programming the mapping is at odds to this binding. I don't
see how that can fit.

Why can the RID->SID mapping not be statically configured prior to
entering the OS?

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-06 Thread Mark Rutland

On Wed, Aug 05, 2015 at 05:39:33PM +0100, Varun Sethi wrote:
> Hi Mark
> Thanks for the patch. Please find my comment inline.
> 
> Regards
> Varun
> 
> > -Original Message-
> > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> > boun...@lists.linux-foundation.org] On Behalf Of Mark Rutland
> > Sent: Thursday, July 23, 2015 10:23 PM
> > To: devicet...@vger.kernel.org
> > Cc: Mark Rutland; lorenzo.pieral...@arm.com; a...@arndb.de;
> > marc.zyng...@arm.com; will.dea...@arm.com; linux-
> > ker...@vger.kernel.org; dda...@caviumnetworks.com; iommu@lists.linux-
> > foundation.org; tirumalesh.chalama...@caviumnetworks.com;
> > laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com;
> > tred...@nvidia.com; linux-arm-ker...@lists.infradead.org;
> > majun...@huawei.com
> > Subject: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
> >
> > 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 
> > ---
> >  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 000..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:
> [varun] How would we account for hot plug PCI devices and SR-IOV use cases, 
> with the rid base and length?

For hotplug, you simply need the mapping from RID to msi-specifier to be
defined in advance in the DT, for the set of RIDs that could possibly
occur.

For SR-IOV, are you asking about ARI? I should update the description of
the RID to describe that for ARI it has the format:

* Bits [15:8] are the Bus number
* Bits [7:0] are the Identifier

Other than that, the handling would be identical to the non-ARI case.

What else am I missing?

> How do we take in to account for a PCIe bridge, while setting up the 
> requestor ID base and length?

I'm not sure I follow the question. I don't see why this is any
different to any other requester ID.

What do you see as being the problem for this case?

> > +
>

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-06 Thread Stuart Yoder

 -Original Message-
 From: Mark Rutland [mailto:mark.rutl...@arm.com]
 Sent: Thursday, August 06, 2015 1:15 PM
 To: Yoder Stuart-B08248; Marc Zyngier; Will Deacon
 Cc: devicet...@vger.kernel.org; Lorenzo Pieralisi; a...@arndb.de; 
 linux-kernel@vger.kernel.org;
 dda...@caviumnetworks.com; io...@lists.linux-foundation.org; 
 tirumalesh.chalama...@caviumnetworks.com;
 laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com; 
 tred...@nvidia.com; linux-arm-
 ker...@lists.infradead.org; majun...@huawei.com
 Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

 [...]

   +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.

  Can we extend the msi-map-mask definition to say:  A mask value of 0x0 is 
  valid
  and indicates that no RIDs are _currently_ mapped to any msi-specifier.

 That would break a valid case of the mask being all zeroes.

 Consider the case that all RIDs get mapped to a single msi-specifier;
 the obvious way to write that is:

 msi-map-mask = 0x;
 msi-map = 0x msi (msi-specifier) 1;

 In this case all RIDS are always mapped to the single msi-specifier.

Does it really break that case?

We could have this (your example):

  msi-map-mask = 0x;
  msi-map = 0x msi 7 1;  // map all RIDs to msi-spec 7

Or, my example:

  msi-map-mask = 0x;
  msi-map = 0x msi 7 4;  // all RIDs map to any of msi-spec 7,8,9,10

  We have an SoC with a programmable hardware table in the PCI controller 
  that maps
  requester ID to stream ID, so the overall msi-map (and iommu-map) 
  definition fit
  into that scheme.  But, we would like to be able make the RID-stream-ID 
  mapping
  decision _lazily_, in Linux, based on actual usage of PCI devices.

 Dynamically programming the mapping is at odds to this binding. I don't
 see how that can fit.

My example above obviously doesn't make sense for a static
binding, but can't we allow both a mask value of 0x0 and
a length  1 at the same time.

 Why can the RID-SID mapping not be statically configured prior to
 entering the OS?

The problem for us is the limited number of SIDs available on our SoC.  We
have an SMMU-500 with 128 SIDs / 64-contexts total.  An SR-IOV card could
enable VFs dynamically and suddenly there are 64 new RIDs on a PCI
bus.  There are 4 PCI controllers and firmware doesn't know what
might be enabled on which bus.  We run out of available SIDs.

In that example we want all RIDs mapped to one SID by default, but want
the option of setting our dynamic RID-SID table for a situation where
say someone assigns a VF to a KVM VM and thus needs an SID to use
for SMMU mappings.

I think the binding can work for the dynamic case as long as we allow
the example I showed above.  So, I would propose changing
my proposed text to:

   A mask value of 0x0 is valid and indicates that all RIDS map to
the specified msi-specifier(s).  If the mask is 0x0 and length  1
it indicates that all RIDs map to any of the msi-specifiers with
the actual mapping left unspecified by the msi-map property.

Thanks,
Stuart
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-06 Thread Mark Rutland

On Wed, Aug 05, 2015 at 05:39:33PM +0100, Varun Sethi wrote:
 Hi Mark
 Thanks for the patch. Please find my comment inline.
 
 Regards
 Varun
 
  -Original Message-
  From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
  boun...@lists.linux-foundation.org] On Behalf Of Mark Rutland
  Sent: Thursday, July 23, 2015 10:23 PM
  To: devicet...@vger.kernel.org
  Cc: Mark Rutland; lorenzo.pieral...@arm.com; a...@arndb.de;
  marc.zyng...@arm.com; will.dea...@arm.com; linux-
  ker...@vger.kernel.org; dda...@caviumnetworks.com; iommu@lists.linux-
  foundation.org; tirumalesh.chalama...@caviumnetworks.com;
  laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com;
  tred...@nvidia.com; linux-arm-ker...@lists.infradead.org;
  majun...@huawei.com
  Subject: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
 
  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.rutl...@arm.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 000..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:
 [varun] How would we account for hot plug PCI devices and SR-IOV use cases, 
 with the rid base and length?

For hotplug, you simply need the mapping from RID to msi-specifier to be
defined in advance in the DT, for the set of RIDs that could possibly
occur.

For SR-IOV, are you asking about ARI? I should update the description of
the RID to describe that for ARI it has the format:

* Bits [15:8] are the Bus number
* Bits [7:0] are the Identifier

Other than that, the handling would be identical to the non-ARI case.

What else am I missing?

 How do we take in to account for a PCIe bridge, while setting up the 
 requestor ID base and length?

I'm not sure I follow the question. I don't see why this is any
different to any other requester ID.

What do you see as being the problem for this case?

  +
  +  * 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

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-06 Thread Mark Rutland

[...]

  +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.
 
 Can we extend the msi-map-mask definition to say:  A mask value of 0x0 is 
 valid
 and indicates that no RIDs are _currently_ mapped to any msi-specifier.

That would break a valid case of the mask being all zeroes.

Consider the case that all RIDs get mapped to a single msi-specifier;
the obvious way to write that is:

msi-map-mask = 0x;
msi-map = 0x msi (msi-specifier) 1;

In this case all RIDS are always mapped to the single msi-specifier.

 We have an SoC with a programmable hardware table in the PCI controller that 
 maps
 requester ID to stream ID, so the overall msi-map (and iommu-map) definition 
 fit
 into that scheme.  But, we would like to be able make the RID-stream-ID 
 mapping
 decision _lazily_, in Linux, based on actual usage of PCI devices.

Dynamically programming the mapping is at odds to this binding. I don't
see how that can fit.

Why can the RID-SID mapping not be statically configured prior to
entering the OS?

Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-05 Thread Stuart Yoder

> From: Mark Rutland 
> Date: Thu, Jul 23, 2015 at 11:52 AM

[cut]

> diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt
> b/Documentation/devicetree/bindings/pci/pci-msi.txt
> new file mode 100644
> index 000..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.

Can we extend the msi-map-mask definition to say:  "A mask value of 0x0 is valid
and indicates that no RIDs are _currently_ mapped to any msi-specifier."

We have an SoC with a programmable hardware table in the PCI controller that 
maps
requester ID to stream ID, so the overall msi-map (and iommu-map) definition fit
into that scheme.  But, we would like to be able make the RID->stream-ID mapping
decision _lazily_, in Linux, based on actual usage of PCI devices.

  pcie@360 {
  compatible = "fsl,ls2085a-pcie", "snps,dw-pcie";
  device_type = "pci";
  ...
  msi-map = <0x0 _a 0x7 4>,
  msi-map-mask = <0x0>
  };

That specifies the there are 4 stream IDs starting at stream ID 0x7, 
but the requester ID's are not mapped (because the mask is 0x0).
This tells the PCI controller driver that there are 4 msi-specifiers
(e.g. stream IDs) available and what they are.

(same definition would apply to the iommu-map-mask)

Thanks,
Stuart

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-05 Thread Varun Sethi

Hi Mark
Thanks for the patch. Please find my comment inline.

Regards
Varun

> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Mark Rutland
> Sent: Thursday, July 23, 2015 10:23 PM
> To: devicet...@vger.kernel.org
> Cc: Mark Rutland; lorenzo.pieral...@arm.com; a...@arndb.de;
> marc.zyng...@arm.com; will.dea...@arm.com; linux-
> ker...@vger.kernel.org; dda...@caviumnetworks.com; iommu@lists.linux-
> foundation.org; tirumalesh.chalama...@caviumnetworks.com;
> laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com;
> tred...@nvidia.com; linux-arm-ker...@lists.infradead.org;
> majun...@huawei.com
> Subject: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
> 
> 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 
> ---
>  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 000..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:
[varun] How would we account for hot plug PCI devices and SR-IOV use cases, 
with the rid base and length?  How do we take in to account for a PCIe bridge, 
while setting up the requestor ID base and length?

> +
> +  * 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.
> +
[varun] Can you please elaborate on a use case, where this would help. 



> +- 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

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-05 Thread Varun Sethi

Hi Mark
Thanks for the patch. Please find my comment inline.

Regards
Varun

 -Original Message-
 From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
 boun...@lists.linux-foundation.org] On Behalf Of Mark Rutland
 Sent: Thursday, July 23, 2015 10:23 PM
 To: devicet...@vger.kernel.org
 Cc: Mark Rutland; lorenzo.pieral...@arm.com; a...@arndb.de;
 marc.zyng...@arm.com; will.dea...@arm.com; linux-
 ker...@vger.kernel.org; dda...@caviumnetworks.com; iommu@lists.linux-
 foundation.org; tirumalesh.chalama...@caviumnetworks.com;
 laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com;
 tred...@nvidia.com; linux-arm-ker...@lists.infradead.org;
 majun...@huawei.com
 Subject: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
 
 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.rutl...@arm.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 000..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:
[varun] How would we account for hot plug PCI devices and SR-IOV use cases, 
with the rid base and length?  How do we take in to account for a PCIe bridge, 
while setting up the requestor ID base and length?

 +
 +  * 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.
 +
[varun] Can you please elaborate on a use case, where this would help. 



 +- 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.
 +
 +
 +Example (1)
 +===
 +
 +/ {
 + #address-cells = 1;
 + #size-cells = 1;
 +
 + msi: msi-controller@a {
 + reg = 0xa 0x1;
 + compatible = vendor,some-controller;
 + msi-controller;
 + #msi-cells = 1;
 + };
 +
 + pci: pci@f

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-08-05 Thread Stuart Yoder

 From: Mark Rutland mark.rutl...@arm.com
 Date: Thu, Jul 23, 2015 at 11:52 AM

[cut]

 diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt
 b/Documentation/devicetree/bindings/pci/pci-msi.txt
 new file mode 100644
 index 000..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.

Can we extend the msi-map-mask definition to say:  A mask value of 0x0 is valid
and indicates that no RIDs are _currently_ mapped to any msi-specifier.

We have an SoC with a programmable hardware table in the PCI controller that 
maps
requester ID to stream ID, so the overall msi-map (and iommu-map) definition fit
into that scheme.  But, we would like to be able make the RID-stream-ID mapping
decision _lazily_, in Linux, based on actual usage of PCI devices.

  pcie@360 {
  compatible = fsl,ls2085a-pcie, snps,dw-pcie;
  device_type = pci;
  ...
  msi-map = 0x0 msi_a 0x7 4,
  msi-map-mask = 0x0
  };

That specifies the there are 4 stream IDs starting at stream ID 0x7, 
but the requester ID's are not mapped (because the mask is 0x0).
This tells the PCI controller driver that there are 4 msi-specifiers
(e.g. stream IDs) available and what they are.

(same definition would apply to the iommu-map-mask)

Thanks,
Stuart

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-07-27 Thread Mark Rutland

> > +Example (5)
> > +===
> > +
> > +/ {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   msi_a: msi-controller@a {
> > +   reg = <0xa 0x1>;
> > +   compatible = "vendor,some-controller";
> > +   msi-controller;
> > +   #msi-cells = <1>;
> > +   };
> > +
> > +   msi_b: msi-controller@b {
> > +   reg = <0xb 0x1>;
> > +   compatible = "vendor,some-controller";
> > +   msi-controller;
> > +   #msi-cells = <1>;
> > +   };
> > +
> > +   msi_c: msi-controller@c {
> > +   reg = <0xc 0x1>;
> > +   compatible = "vendor,some-controller";
> > +   msi-controller;
> > +   #msi-cells = <1>;
> > +   };
> > +
> > +   pci: pci@c {
> > +   reg = <0xf 0x1>;
> > +   compatible = "vendor,pcie-root-complex";
> > +   device_type = "pci";
> > +
> > +   /*
> > +* The sideband data provided to MSI controller a is the
> > +* RID, but the high bit of the bus number is negated.
> > +* The sideband data provided to MSI controller b is the
> > +* RID, identity-mapped.
> > +* MSI controller c is not addressable.
> > +*/
> > +   msi-map = <0x _a 0x8000 0x08000>,
> > + <0x8000 _a 0x 0x08000>,
> > + <0x _b 0x 0x1>;
> > +   };
> 
> they can be identical right? like
>   <0x8000 _a 0x 0x08000>,
>   <0x8000 _b 0x 0x08000>;

In general that would be valid, yes.

In this case two entries are required for MSI controller a because the
high bit passed to it is negated. This does not occur for MSI controller
b, so it only requires a single entry to describe the transformation.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-07-27 Thread Marc Zyngier

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 
> ---
>  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 000..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.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-07-27 Thread Marc Zyngier

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.rutl...@arm.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 000..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.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-07-27 Thread Mark Rutland

  +Example (5)
  +===
  +
  +/ {
  +   #address-cells = 1;
  +   #size-cells = 1;
  +
  +   msi_a: msi-controller@a {
  +   reg = 0xa 0x1;
  +   compatible = vendor,some-controller;
  +   msi-controller;
  +   #msi-cells = 1;
  +   };
  +
  +   msi_b: msi-controller@b {
  +   reg = 0xb 0x1;
  +   compatible = vendor,some-controller;
  +   msi-controller;
  +   #msi-cells = 1;
  +   };
  +
  +   msi_c: msi-controller@c {
  +   reg = 0xc 0x1;
  +   compatible = vendor,some-controller;
  +   msi-controller;
  +   #msi-cells = 1;
  +   };
  +
  +   pci: pci@c {
  +   reg = 0xf 0x1;
  +   compatible = vendor,pcie-root-complex;
  +   device_type = pci;
  +
  +   /*
  +* The sideband data provided to MSI controller a is the
  +* RID, but the high bit of the bus number is negated.
  +* The sideband data provided to MSI controller b is the
  +* RID, identity-mapped.
  +* MSI controller c is not addressable.
  +*/
  +   msi-map = 0x msi_a 0x8000 0x08000,
  + 0x8000 msi_a 0x 0x08000,
  + 0x msi_b 0x 0x1;
  +   };
 
 they can be identical right? like
   0x8000 msi_a 0x 0x08000,
   0x8000 msi_b 0x 0x08000;

In general that would be valid, yes.

In this case two entries are required for MSI controller a because the
high bit passed to it is negated. This does not occur for MSI controller
b, so it only requires a single entry to describe the transformation.

Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-07-24 Thread Chalamarla, Tirumalesh

looks good. possible to describe the chip we have.
> On Jul 23, 2015, at 9:52 AM, 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 
> ---
> 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 000..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.
> +
> +
> +Example (1)
> +===
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + msi: msi-controller@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-controller";
> + msi-controller;
> + #msi-cells = <1>;
> + };
> +
> + pci: pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + /*
> +  * The sideband data provided to the MSI controller is
> +  * the RID, identity-mapped.
> +  */
> + msi-map = <0x0 _a 0x0 0x1>,
> + };
> +};
> +
> +
> +Example (2)
> +===
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + msi: msi-controller@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-controller";
> + msi-controller;
> + #msi-cells = <1>;
> + };
> +
> + pci: pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + /*
>

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-07-24 Thread Chalamarla, Tirumalesh

looks good. possible to describe the chip we have.
 On Jul 23, 2015, at 9:52 AM, Mark Rutland mark.rutl...@arm.com 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.rutl...@arm.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 000..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.
 +
 +
 +Example (1)
 +===
 +
 +/ {
 + #address-cells = 1;
 + #size-cells = 1;
 +
 + msi: msi-controller@a {
 + reg = 0xa 0x1;
 + compatible = vendor,some-controller;
 + msi-controller;
 + #msi-cells = 1;
 + };
 +
 + pci: pci@f {
 + reg = 0xf 0x1;
 + compatible = vendor,pcie-root-complex;
 + device_type = pci;
 +
 + /*
 +  * The sideband data provided to the MSI controller is
 +  * the RID, identity-mapped.
 +  */
 + msi-map = 0x0 msi_a 0x0 0x1,
 + };
 +};
 +
 +
 +Example (2)
 +===
 +
 +/ {
 + #address-cells = 1;
 + #size-cells = 1;
 +
 + msi: msi-controller@a {
 + reg = 0xa 0x1;
 + compatible = vendor,some-controller;
 + msi-controller;
 + #msi-cells = 1;
 + };
 +
 + pci: pci@f {
 + reg = 0xf 0x1;
 + compatible = vendor,pcie-root-complex;
 + device_type = pci;
 +
 + /*
 +  * The sideband data provided to the MSI controller is
 +  * the RID, masked to only the device and function

[PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-07-23 Thread Mark Rutland

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 
---
 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 000..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.
+
+
+Example (1)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   msi: msi-controller@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-controller";
+   msi-controller;
+   #msi-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the MSI controller is
+* the RID, identity-mapped.
+*/
+   msi-map = <0x0 _a 0x0 0x1>,
+   };
+};
+
+
+Example (2)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   msi: msi-controller@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-controller";
+   msi-controller;
+   #msi-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the MSI controller is
+* the RID, masked to only the device and function bits.
+*/
+   msi-map = <0x0 _a 0x0 0x100>,
+   msi-map-mask = <0xff>
+   };
+};
+
+
+Example (3)
+===
+
+/ {
+   #address-cells = <1>;
+

[PATCH 2/3] Docs: dt: Add PCI MSI map bindings

2015-07-23 Thread Mark Rutland

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.rutl...@arm.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 000..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.
+
+
+Example (1)
+===
+
+/ {
+   #address-cells = 1;
+   #size-cells = 1;
+
+   msi: msi-controller@a {
+   reg = 0xa 0x1;
+   compatible = vendor,some-controller;
+   msi-controller;
+   #msi-cells = 1;
+   };
+
+   pci: pci@f {
+   reg = 0xf 0x1;
+   compatible = vendor,pcie-root-complex;
+   device_type = pci;
+
+   /*
+* The sideband data provided to the MSI controller is
+* the RID, identity-mapped.
+*/
+   msi-map = 0x0 msi_a 0x0 0x1,
+   };
+};
+
+
+Example (2)
+===
+
+/ {
+   #address-cells = 1;
+   #size-cells = 1;
+
+   msi: msi-controller@a {
+   reg = 0xa 0x1;
+   compatible = vendor,some-controller;
+   msi-controller;
+   #msi-cells = 1;
+   };
+
+   pci: pci@f {
+   reg = 0xf 0x1;
+   compatible = vendor,pcie-root-complex;
+   device_type = pci;
+
+   /*
+* The sideband data provided to the MSI controller is
+* the RID, masked to only the device and function bits.
+*/
+   msi-map = 0x0 msi_a 0x0 0x100,
+   msi-map-mask = 0xff
+   };
+};
+
+
+Example (3)
+===
+
+/ {
+   #address-cells = 1;
+

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

[PATCH 2/3] Docs: dt: Add PCI MSI map bindings

[PATCH 2/3] Docs: dt: Add PCI MSI map bindings

28 matches

Site Navigation

Mail list logo

Footer information