Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1201155 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings Stuart Yoder <stuart.yoder@freescale.com> - 2015-08-05 23:30 +0200
    Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings Mark Rutland <mark.rutland@arm.com> - 2015-08-06 20:20 +0200
      RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings Stuart Yoder <stuart.yoder@freescale.com> - 2015-08-06 21:50 +0200

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

PiBGcm9tOiBNYXJrIFJ1dGxhbmQgPG1hcmsucnV0bGFuZEBhcm0uY29tPg0KPiBEYXRlOiBUaHUs
IEp1bCAyMywgMjAxNSBhdCAxMTo1MiBBTQ0KDQpbY3V0XQ0KDQo+IGRpZmYgLS1naXQgYS9Eb2N1
bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcGNpL3BjaS1tc2kudHh0DQo+IGIvRG9jdW1l
bnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3BjaS9wY2ktbXNpLnR4dA0KPiBuZXcgZmlsZSBt
b2RlIDEwMDY0NA0KPiBpbmRleCAwMDAwMDAwLi45YjNjYzgxDQo+IC0tLSAvZGV2L251bGwNCj4g
KysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3BjaS9wY2ktbXNpLnR4dA0K
PiBAQCAtMCwwICsxLDIyMCBAQA0KPiArVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGdlbmVy
aWMgZGV2aWNlIHRyZWUgYmluZGluZyBmb3IgZGVzY3JpYmluZyB0aGUNCj4gK3JlbGF0aW9uc2hp
cCBiZXR3ZWVuIFBDSSBkZXZpY2VzIGFuZCBNU0kgY29udHJvbGxlcnMuDQo+ICsNCj4gK0VhY2gg
UENJIGRldmljZSB1bmRlciBhIHJvb3QgY29tcGxleCBpcyB1bmlxdWVseSBpZGVudGlmaWVkIGJ5
IGl0cyBSZXF1ZXN0ZXIgSUQNCj4gKyhBS0EgUklEKS4gQSBSZXF1ZXN0ZXIgSUQgaXMgYSB0cmlw
bGV0IG9mIGEgQnVzIG51bWJlciwgRGV2aWNlIG51bWJlciwgYW5kDQo+ICtGdW5jdGlvbiBudW1i
ZXIuDQo+ICsNCj4gK0ZvciB0aGUgcHVycG9zZSBvZiB0aGlzIGRvY3VtZW50LCB3aGVuIHRyZWF0
ZWQgYXMgYSBudW1lcmljIHZhbHVlLCBhIFJJRCBpcw0KPiArZm9ybWF0dGVkIHN1Y2ggdGhhdDoN
Cj4gKw0KPiArKiBCaXRzIFsxNTo4XSBhcmUgdGhlIEJ1cyBudW1iZXIuDQo+ICsqIEJpdHMgWzc6
M10gYXJlIHRoZSBEZXZpY2UgbnVtYmVyLg0KPiArKiBCaXRzIFsyOjBdIGFyZSB0aGUgRnVuY3Rp
b24gbnVtYmVyLg0KPiArKiBBbnkgb3RoZXIgYml0cyByZXF1aXJlZCBmb3IgcGFkZGluZyBtdXN0
IGJlIHplcm8uDQo+ICsNCj4gK01TSXMgbWF5IGJlIGRpc3Rpbmd1aXNoZWQgaW4gcGFydCB0aHJv
dWdoIHRoZSB1c2Ugb2Ygc2lkZWJhbmQgZGF0YSBhY2NvbXBhbnlpbmcNCj4gK3dyaXRlcy4gSW4g
dGhlIGNhc2Ugb2YgUENJIGRldmljZXMsIHRoaXMgc2lkZWJhbmQgZGF0YSBtYXkgYmUgZGVyaXZl
ZCBmcm9tIHRoZQ0KPiArUmVxdWVzdGVyIElELiBBIG1lY2hhbmlzbSBpcyByZXF1aXJlZCB0byBh
c3NvY2lhdGUgYSBkZXZpY2Ugd2l0aCBib3RoIHRoZSBNU0kNCj4gK2NvbnRyb2xsZXJzIGl0IGNh
biBhZGRyZXNzLCBhbmQgdGhlIHNpZGViYW5kIGRhdGEgdGhhdCB3aWxsIGJlIGFzc29jaWF0ZWQg
d2l0aA0KPiAraXRzIHdyaXRlcyB0byB0aG9zZSBjb250cm9sbGVycy4NCj4gKw0KPiArRm9yIGdl
bmVyaWMgTVNJIGJpbmRpbmdzLCBzZWUNCj4gK0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5k
aW5ncy9pbnRlcnJ1cHQtY29udHJvbGxlci9tc2kudHh0Lg0KPiArDQo+ICsNCj4gK1BDSSByb290
IGNvbXBsZXgNCj4gKz09PT09PT09PT09PT09PT0NCj4gKw0KPiArT3B0aW9uYWwgcHJvcGVydGll
cw0KPiArLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiArDQo+ICstIG1zaS1tYXA6IE1hcHMgYSBSZXF1
ZXN0ZXIgSUQgdG8gYW4gTVNJIGNvbnRyb2xsZXIgYW5kIGFzc29jaWF0ZWQNCj4gKyAgbXNpLXNw
ZWNpZmllciBkYXRhLiBUaGUgcHJvcGVydHkgaXMgYW4gYXJiaXRyYXJ5IG51bWJlciBvZiB0dXBs
ZXMgb2YNCj4gKyAgKHJpZC1iYXNlLG1zaS1jb250cm9sbGVyLG1zaS1iYXNlLGxlbmd0aCksIHdo
ZXJlOg0KPiArDQo+ICsgICogcmlkLWJhc2UgaXMgYSBzaW5nbGUgY2VsbCBkZXNjcmliaW5nIHRo
ZSBmaXJzdCBSSUQgbWF0Y2hlZCBieSB0aGUgZW50cnkuDQo+ICsNCj4gKyAgKiBtc2ktY29udHJv
bGxlciBpcyBhIHNpbmdsZSBwaGFuZGxlIHRvIGFuIE1TSSBjb250cm9sbGVyDQo+ICsNCj4gKyAg
KiBtc2ktYmFzZSBpcyBhbiBtc2ktc3BlY2lmaWVyIGRlc2NyaWJpbmcgdGhlIG1zaS1zcGVjaWZp
ZXIgcHJvZHVjZWQgZm9yIHRoZQ0KPiArICAgIGZpcnN0IFJJRCBtYXRjaGVkIGJ5IHRoZSBlbnRy
eS4NCj4gKw0KPiArICAqIGxlbmd0aCBpcyBhIHNpbmdsZSBjZWxsIGRlc2NyaWJpbmcgaG93IG1h
bnkgY29uc2VjdXRpdmUgUklEcyBhcmUgbWF0Y2hlZA0KPiArICAgIGZvbGxvd2luZyB0aGUgcmlk
LWJhc2UuDQo+ICsNCj4gKyAgQW55IFJJRCByIGluIHRoZSBpbnRlcnZhbCBbcmlkLWJhc2UsIHJp
ZC1iYXNlICsgbGVuZ3RoKSBpcyBhc3NvY2lhdGVkIHdpdGgNCj4gKyAgdGhlIGxpc3RlZCBtc2kt
Y29udHJvbGxlciwgd2l0aCB0aGUgbXNpLXNwZWNpZmllciAociAtIHJpZC1iYXNlICsgbXNpLWJh
c2UpLg0KPiArDQo+ICstIG1zaS1tYXAtbWFzazogQSBtYXNrIHRvIGJlIGFwcGxpZWQgdG8gZWFj
aCBSZXF1ZXN0ZXIgSUQgcHJpb3IgdG8gYmVpbmcgbWFwcGVkDQo+ICsgIHRvIGFuIG1zaS1zcGVj
aWZpZXIgcGVyIHRoZSBtc2ktbWFwIHByb3BlcnR5Lg0KDQpDYW4gd2UgZXh0ZW5kIHRoZSBtc2kt
bWFwLW1hc2sgZGVmaW5pdGlvbiB0byBzYXk6ICAiQSBtYXNrIHZhbHVlIG9mIDB4MCBpcyB2YWxp
ZA0KYW5kIGluZGljYXRlcyB0aGF0IG5vIFJJRHMgYXJlIF9jdXJyZW50bHlfIG1hcHBlZCB0byBh
bnkgbXNpLXNwZWNpZmllci4iDQoNCldlIGhhdmUgYW4gU29DIHdpdGggYSBwcm9ncmFtbWFibGUg
aGFyZHdhcmUgdGFibGUgaW4gdGhlIFBDSSBjb250cm9sbGVyIHRoYXQgbWFwcw0KcmVxdWVzdGVy
IElEIHRvIHN0cmVhbSBJRCwgc28gdGhlIG92ZXJhbGwgbXNpLW1hcCAoYW5kIGlvbW11LW1hcCkg
ZGVmaW5pdGlvbiBmaXQNCmludG8gdGhhdCBzY2hlbWUuICBCdXQsIHdlIHdvdWxkIGxpa2UgdG8g
YmUgYWJsZSBtYWtlIHRoZSBSSUQtPnN0cmVhbS1JRCBtYXBwaW5nDQpkZWNpc2lvbiBfbGF6aWx5
XywgaW4gTGludXgsIGJhc2VkIG9uIGFjdHVhbCB1c2FnZSBvZiBQQ0kgZGV2aWNlcy4NCg0KICAg
ICAgcGNpZUAzNjAwMDAwIHsNCiAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJmc2wsbHMyMDg1
YS1wY2llIiwgInNucHMsZHctcGNpZSI7DQogICAgICAgICAgICAgIGRldmljZV90eXBlID0gInBj
aSI7DQogICAgICAgICAgICAgIC4uLg0KICAgICAgICAgICAgICBtc2ktbWFwID0gPDB4MCAmbXNp
X2EgMHg3IDQ+LA0KICAgICAgICAgICAgICBtc2ktbWFwLW1hc2sgPSA8MHgwPg0KICAgICAgfTsN
Cg0KVGhhdCBzcGVjaWZpZXMgdGhlIHRoZXJlIGFyZSA0IHN0cmVhbSBJRHMgc3RhcnRpbmcgYXQg
c3RyZWFtIElEIDB4NywgDQpidXQgdGhlIHJlcXVlc3RlciBJRCdzIGFyZSBub3QgbWFwcGVkIChi
ZWNhdXNlIHRoZSBtYXNrIGlzIDB4MCkuDQpUaGlzIHRlbGxzIHRoZSBQQ0kgY29udHJvbGxlciBk
cml2ZXIgdGhhdCB0aGVyZSBhcmUgNCBtc2ktc3BlY2lmaWVycw0KKGUuZy4gc3RyZWFtIElEcykg
YXZhaWxhYmxlIGFuZCB3aGF0IHRoZXkgYXJlLg0KDQooc2FtZSBkZWZpbml0aW9uIHdvdWxkIGFw
cGx5IHRvIHRoZSBpb21tdS1tYXAtbWFzaykNCg0KVGhhbmtzLA0KU3R1YXJ0DQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1201957

[...]

> > +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 = <0x0000>;
msi-map = <0x0000 &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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1201992

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland@arm.com]
> Sent: Thursday, August 06, 2015 1:15 PM
> To: Yoder Stuart-B08248; Marc Zyngier; Will Deacon
> Cc: devicetree@vger.kernel.org; Lorenzo Pieralisi; arnd@arndb.de; linux-kernel@vger.kernel.org;
> ddaney@caviumnetworks.com; iommu@lists.linux-foundation.org; tirumalesh.chalamarla@caviumnetworks.com;
> laurent.pinchart@ideasonboard.com; thunder.leizhen@huawei.com; treding@nvidia.com; linux-arm-
> kernel@lists.infradead.org; majun258@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 = <0x0000>;
> msi-map = <0x0000 &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 = <0x0000>;
  msi-map = <0x0000 &msi 7 1>;  // map all RIDs to msi-spec 7

Or, my example:

  msi-map-mask = <0x0000>;
  msi-map = <0x0000 &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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web