This patch adds iommu-map property for PCIe, which enables
SMMU for these devices on LS208xA devices.
Signed-off-by: Bharat Bhushan <redacted>
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 ++++
1 file changed, 4 insertions(+)
@@ -606,6 +606,7 @@num-lanes=<4>;bus-range=<0x00xff>;msi-parent=<&its>;+iommu-map=<0&smmu01>;/* This is fixed-up by u-boot */#interrupt-cells=<1>;interrupt-map-mask=<0007>;interrupt-map=<0000001&gic0001094>,
@@ -627,6 +628,7 @@num-lanes=<4>;bus-range=<0x00xff>;msi-parent=<&its>;+iommu-map=<0&smmu01>;/* This is fixed-up by u-boot */#interrupt-cells=<1>;interrupt-map-mask=<0007>;interrupt-map=<0000001&gic0001144>,
@@ -648,6 +650,7 @@num-lanes=<8>;bus-range=<0x00xff>;msi-parent=<&its>;+iommu-map=<0&smmu01>;/* This is fixed-up by u-boot */#interrupt-cells=<1>;interrupt-map-mask=<0007>;interrupt-map=<0000001&gic0001194>,
@@ -669,6 +672,7 @@num-lanes=<4>;bus-range=<0x00xff>;msi-parent=<&its>;+iommu-map=<0&smmu01>;/* This is fixed-up by u-boot */#interrupt-cells=<1>;interrupt-map-mask=<0007>;interrupt-map=<0000001&gic0001244>,
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Marc Zyngier <hidden> Date: 2017-08-31 09:32:14
On 31/08/17 10:23, Bharat Bhushan wrote:
quoted hunk
This patch adds iommu-map property for PCIe, which enables
SMMU for these devices on LS208xA devices.
Signed-off-by: Bharat Bhushan <redacted>
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 ++++
1 file changed, 4 insertions(+)
-----Original Message-----
From: Marc Zyngier [mailto:marc.zyngier@arm.com]
Sent: Thursday, August 31, 2017 3:02 PM
To: Bharat Bhushan <redacted>; robh+dt@kernel.org;
ark.rutland@arm.com; will.deacon@arm.com; oss@buserror.net; Gang Liu
[off-list ref]; devicetree@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
catalin.marinas@arm.com
Subject: Re: [PATCH] RM64: dts: ls208xa: Add iommu-map property for pci
On 31/08/17 10:23, Bharat Bhushan wrote:
quoted
This patch adds iommu-map property for PCIe, which enables SMMU for
these devices on LS208xA devices.
Signed-off-by: Bharat Bhushan <redacted>
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 ++++
1 file changed, 4 insertions(+)
@@ -606,6 +606,7 @@num-lanes=<4>;bus-range=<0x00xff>;msi-parent=<&its>;+iommu-map=<0&smmu01>;/* This is fixed-up by
u-boot */
What does this do when your version of u-boot doesn't fill this in for you?
Good question, frankly I have not thought of this case before.
But if we pass length = 0 in above property then no fixup happen with happen with older u-boot. In this case of_iommu_configure() will return NULL iommu-ops and it switch to swio-tlb. Will that work?
Thanks
-Bharat
Thanks,
M.
--
Jazz is not dead. It just smells funny...
From: Marc Zyngier <hidden> Date: 2017-08-31 10:49:42
[Fixing Mark's address...]
On 31/08/17 11:41, Bharat Bhushan wrote:
quoted
-----Original Message-----
From: Marc Zyngier [mailto:marc.zyngier-5wv7dgnIgG8@public.gmane.org]
Sent: Thursday, August 31, 2017 3:02 PM
To: Bharat Bhushan <redacted>; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org;
ark.rutland-5wv7dgnIgG8@public.gmane.org; will.deacon-5wv7dgnIgG8@public.gmane.org; oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org; Gang Liu
[off-list ref]; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
catalin.marinas-5wv7dgnIgG8@public.gmane.org
Subject: Re: [PATCH] RM64: dts: ls208xa: Add iommu-map property for pci
On 31/08/17 10:23, Bharat Bhushan wrote:
quoted
This patch adds iommu-map property for PCIe, which enables SMMU for
these devices on LS208xA devices.
Signed-off-by: Bharat Bhushan <redacted>
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 ++++
1 file changed, 4 insertions(+)
@@ -606,6 +606,7 @@num-lanes=<4>;bus-range=<0x00xff>;msi-parent=<&its>;+iommu-map=<0&smmu01>;/* This is fixed-up by
u-boot */
What does this do when your version of u-boot doesn't fill this in for you?
Good question, frankly I have not thought of this case before.
But if we pass length = 0 in above property then no fixup happen with
happen with older u-boot. In this case of_iommu_configure() will
return NULL iommu-ops and it switch to swio-tlb. Will that work?
I really don't like this. You rely on having invalid data in the DT, and
that seems just wrong.
Why can't u-boot just generate that property, and we leave the DT alone?
Or even better, you provide the right information for the few boards
that are based on this SoC, not relying on u-boot for anything that is
in the kernel tree?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This patch adds iommu-map property for PCIe, which enables SMMU for
these devices on LS208xA devices.
Signed-off-by: Bharat Bhushan <redacted>
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 ++++
1 file changed, 4 insertions(+)
@@ -606,6 +606,7 @@num-lanes=<4>;bus-range=<0x00xff>;msi-parent=<&its>;+iommu-map=<0&smmu01>;/* This is fixed-up by
u-boot */
What does this do when your version of u-boot doesn't fill this in for you?
Good question, frankly I have not thought of this case before.
But if we pass length = 0 in above property then no fixup happen with
happen with older u-boot. In this case of_iommu_configure() will
return NULL iommu-ops and it switch to swio-tlb. Will that work?
I really don't like this. You rely on having invalid data in the DT, and that
seems just wrong.
Why can't u-boot just generate that property, and we leave the DT alone?
We do not have smmu phandle allowing uboot to generate this.
Or even better, you provide the right information for the few boards that are
based on this SoC, not relying on u-boot for anything that is in the kernel
tree?
On our platforms we have a h/w table which converts RID->Device-Id. I will check what will happen if that table is not initialized, can RID be equal to device-id is that case.
If that will be allowed than we can give right information that will work with u-boot not updating this property.
Will revert after confirming this.
Thanks
-Bharat
Thanks,
M.
--
Jazz is not dead. It just smells funny...
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGludXgta2VybmVsLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LWtlcm5lbC0NCj4gb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgQmhhcmF0IEJodXNoYW4NCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAzMSwgMjAxNyA0OjUzIFBNDQo+IFRvOiBNYXJjIFp5bmdpZXIgPG1hcmMuenluZ2llckBhcm0uY29tPjsgcm9iaCtkdEBrZXJuZWwub3JnOyBNYXJrDQo+IFJ1dGxhbmQgPG1hcmsucnV0bGFuZEBhcm0uY29tPjsgd2lsbC5kZWFjb25AYXJtLmNvbTsNCj4gb3NzQGJ1c2Vycm9yLm5ldDsgR2FuZyBMaXUgPGdhbmcubGl1QG54cC5jb20+Ow0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eC0NCj4ga2VybmVsQHZnZXIua2VybmVsLm9yZzsgY2F0YWxpbi5tYXJpbmFzQGFybS5jb20NCj4gU3ViamVjdDogUkU6IFtQQVRDSF0gUk02NDogZHRzOiBsczIwOHhhOiBBZGQgaW9tbXUtbWFwIHByb3BlcnR5IGZvciBwY2kNCj4gDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1hcmMgWnluZ2llciBbbWFpbHRvOm1hcmMuenluZ2llckBhcm0uY29tXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMzEsIDIwMTcgNDoyMCBQTQ0KPiA+IFRvOiBCaGFyYXQgQmh1c2hhbiA8YmhhcmF0LmJodXNoYW5AbnhwLmNvbT47IHJvYmgrZHRAa2VybmVsLm9yZzsNCj4gTWFyaw0KPiA+IFJ1dGxhbmQgPG1hcmsucnV0bGFuZEBhcm0uY29tPjsgd2lsbC5kZWFjb25AYXJtLmNvbTsNCj4gb3NzQGJ1c2Vycm9yLm5ldDsNCj4gPiBHYW5nIExpdSA8Z2FuZy5saXVAbnhwLmNvbT47IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOw0KPiA+IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsgbGludXgtIGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7DQo+ID4gY2F0YWxpbi5tYXJpbmFzQGFybS5jb20NCj4gPiBTdWJqZWN0OiBSZTogW1BBVENIXSBSTTY0OiBkdHM6IGxzMjA4eGE6IEFkZCBpb21tdS1tYXAgcHJvcGVydHkgZm9yDQo+ID4gcGNpDQo+ID4NCj4gPiBbRml4aW5nIE1hcmsncyBhZGRyZXNzLi4uXQ0KPiA+DQo+ID4gT24gMzEvMDgvMTcgMTE6NDEsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IE1hcmMgWnluZ2llciBbbWFpbHRvOm1hcmMuenluZ2llckBhcm0uY29tXQ0KPiA+ID4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMzEsIDIwMTcgMzowMiBQTQ0KPiA+ID4+IFRvOiBCaGFyYXQgQmh1c2hhbiA8YmhhcmF0LmJodXNoYW5AbnhwLmNvbT47IHJvYmgrZHRAa2VybmVsLm9yZzsNCj4gPiA+PiBhcmsucnV0bGFuZEBhcm0uY29tOyB3aWxsLmRlYWNvbkBhcm0uY29tOyBvc3NAYnVzZXJyb3IubmV0OyBHYW5nDQo+ID4gTGl1DQo+ID4gPj4gPGdhbmcubGl1QG54cC5jb20+OyBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsgbGludXgtYXJtLQ0KPiA+ID4+IGtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOw0KPiA+ID4+IGNhdGFsaW4ubWFyaW5hc0Bhcm0uY29tDQo+ID4gPj4gU3ViamVjdDogUmU6IFtQQVRDSF0gUk02NDogZHRzOiBsczIwOHhhOiBBZGQgaW9tbXUtbWFwIHByb3BlcnR5IGZvcg0KPiA+ID4+IHBjaQ0KPiA+ID4+DQo+ID4gPj4gT24gMzEvMDgvMTcgMTA6MjMsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4+PiBUaGlzIHBhdGNoIGFkZHMgaW9tbXUtbWFwIHByb3BlcnR5IGZvciBQQ0llLCB3aGljaCBlbmFibGVzIFNNTVUNCj4gPiA+Pj4gZm9yIHRoZXNlIGRldmljZXMgb24gTFMyMDh4QSBkZXZpY2VzLg0KPiA+ID4+Pg0KPiA+ID4+PiBTaWduZWQtb2ZmLWJ5OiBCaGFyYXQgQmh1c2hhbiA8QmhhcmF0LkJodXNoYW5AbnhwLmNvbT4NCj4gPiA+Pj4gLS0tDQo+ID4gPj4+ICBhcmNoL2FybTY0L2Jvb3QvZHRzL2ZyZWVzY2FsZS9mc2wtbHMyMDh4YS5kdHNpIHwgNCArKysrDQo+ID4gPj4+ICAxIGZpbGUgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspDQo+ID4gPj4+DQo+ID4gPj4+IGRpZmYgLS1naXQgYS9hcmNoL2FybTY0L2Jvb3QvZHRzL2ZyZWVzY2FsZS9mc2wtbHMyMDh4YS5kdHNpDQo+ID4gPj4+IGIvYXJjaC9hcm02NC9ib290L2R0cy9mcmVlc2NhbGUvZnNsLWxzMjA4eGEuZHRzaQ0KPiA+ID4+PiBpbmRleCA5NGNkZDMwLi42N2NmNjA1IDEwMDY0NA0KPiA+ID4+PiAtLS0gYS9hcmNoL2FybTY0L2Jvb3QvZHRzL2ZyZWVzY2FsZS9mc2wtbHMyMDh4YS5kdHNpDQo+ID4gPj4+ICsrKyBiL2FyY2gvYXJtNjQvYm9vdC9kdHMvZnJlZXNjYWxlL2ZzbC1sczIwOHhhLmR0c2kNCj4gPiA+Pj4gQEAgLTYwNiw2ICs2MDYsNyBAQA0KPiA+ID4+PiAgCQkJbnVtLWxhbmVzID0gPDQ+Ow0KPiA+ID4+PiAgCQkJYnVzLXJhbmdlID0gPDB4MCAweGZmPjsNCj4gPiA+Pj4gIAkJCW1zaS1wYXJlbnQgPSA8Jml0cz47DQo+ID4gPj4+ICsJCQlpb21tdS1tYXAgPSA8MCAmc21tdSAwIDE+OwkvKiBUaGlzIGlzIGZpeGVkLXVwIGJ5DQo+ID4gPj4gdS1ib290ICovDQo+ID4gPj4NCj4gPiA+PiBXaGF0IGRvZXMgdGhpcyBkbyB3aGVuIHlvdXIgdmVyc2lvbiBvZiB1LWJvb3QgZG9lc24ndCBmaWxsIHRoaXMgaW4gZm9yDQo+IHlvdT8NCj4gPiA+DQo+ID4gPiBHb29kIHF1ZXN0aW9uLCBmcmFua2x5IEkgaGF2ZSBub3QgdGhvdWdodCBvZiB0aGlzIGNhc2UgYmVmb3JlLg0KPiA+ID4gQnV0IGlmIHdlIHBhc3MgbGVuZ3RoID0gMCBpbiBhYm92ZSBwcm9wZXJ0eSB0aGVuIG5vIGZpeHVwIGhhcHBlbg0KPiA+ID4gd2l0aCBoYXBwZW4gd2l0aCBvbGRlciB1LWJvb3QuIEluIHRoaXMgY2FzZSBvZl9pb21tdV9jb25maWd1cmUoKQ0KPiA+ID4gd2lsbCByZXR1cm4gTlVMTCBpb21tdS1vcHMgYW5kIGl0IHN3aXRjaCB0byBzd2lvLXRsYi4gV2lsbCB0aGF0IHdvcms/DQo+ID4gSSByZWFsbHkgZG9uJ3QgbGlrZSB0aGlzLiBZb3UgcmVseSBvbiBoYXZpbmcgaW52YWxpZCBkYXRhIGluIHRoZSBEVCwNCj4gPiBhbmQgdGhhdCBzZWVtcyBqdXN0IHdyb25nLg0KPiA+DQo+ID4gV2h5IGNhbid0IHUtYm9vdCBqdXN0IGdlbmVyYXRlIHRoYXQgcHJvcGVydHksIGFuZCB3ZSBsZWF2ZSB0aGUgRFQgYWxvbmU/DQo+IA0KPiBXZSBkbyBub3QgaGF2ZSBzbW11IHBoYW5kbGUgYWxsb3dpbmcgdWJvb3QgdG8gZ2VuZXJhdGUgdGhpcy4NCj4gDQo+ID4gT3IgZXZlbiBiZXR0ZXIsIHlvdSBwcm92aWRlIHRoZSByaWdodCBpbmZvcm1hdGlvbiBmb3IgdGhlIGZldyBib2FyZHMNCj4gPiB0aGF0IGFyZSBiYXNlZCBvbiB0aGlzIFNvQywgbm90IHJlbHlpbmcgb24gdS1ib290IGZvciBhbnl0aGluZyB0aGF0IGlzDQo+ID4gaW4gdGhlIGtlcm5lbCB0cmVlPw0KPiANCj4gT24gb3VyIHBsYXRmb3JtcyB3ZSBoYXZlIGEgaC93IHRhYmxlIHdoaWNoIGNvbnZlcnRzIFJJRC0+RGV2aWNlLUlkLiBJIHdpbGwNCj4gY2hlY2sgd2hhdCB3aWxsIGhhcHBlbiBpZiB0aGF0IHRhYmxlIGlzIG5vdCBpbml0aWFsaXplZCwgY2FuIFJJRCBiZSBlcXVhbCB0bw0KPiBkZXZpY2UtaWQgaXMgdGhhdCBjYXNlLg0KPiBJZiB0aGF0IHdpbGwgYmUgYWxsb3dlZCB0aGFuIHdlIGNhbiBnaXZlIHJpZ2h0IGluZm9ybWF0aW9uIHRoYXQgd2lsbCB3b3JrIHdpdGgNCj4gdS1ib290IG5vdCB1cGRhdGluZyB0aGlzIHByb3BlcnR5Lg0KDQpVLWJvb3QgdXNlcyBhIHN0cmVhbS1pZCBhbGxvY2F0b3IgYW5kIHByb2dyYW1zIHRoZSBoL3cgbWFwcGluZyB0YWJsZSAocmlkIHRvIHNpZCBtYXBwaW5nIHRhYmxlKS4gQWxzbyBpdCB1cGRhdGVzIGlvbW11LW1hcCBwcm9wZXJ0eSBhY2NvcmRpbmdseS4NCkJ1dCBJZiB1LWJvb3QgZG9lcyBub3QgdXBkYXRlIGlvbW11LW1hcCB0aGFuIHdlIGNhbm5vdCBoYXZlIGEgdmFsaWQgZnVsbCBwcm9vZiBzb2x1dGlvbiBhcyBzdHJlYW0taWQgYWxsb2NhdGlvbiBjYW4gY2hhbmdlIGluIHUtYm9vdC4gDQoNClNvIHRoZSBvdGhlciBvcHRpb24gb2YgdS1ib290IGdlbmVyYXRpbmcgdGhpcyBlbnRyeSBzZWVtcyBjb3JyZWN0IHNvbHV0aW9uLiBUaGlzIHJlcXVpcmVzIHUtYm9vdCB0byBrbm93IGlvbW11LXBoYW5kbGUsIHNvbWV0aGluZyBzaW1pbGFyIHRvICJtc2ktcGFyZW50IiB1c2VkIGZvciAibXNpLW1hcCINCkRldmljZS10cmVlIGJpbmRpbmcgbmVlZCBjaGFuZ2UgdG8gYWRkIGlvbW11LXBoYW5kbGUvaW9tbXUtcGFyZW50IGZvciB0aGlzLiANCg0KVGhhbmtzDQotQmhhcmF0DQoNCj4gDQo+IFdpbGwgcmV2ZXJ0IGFmdGVyIGNvbmZpcm1pbmcgdGhpcy4NCj4gDQo+IFRoYW5rcw0KPiAtQmhhcmF0DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4NCj4gPiBNLg0KPiA+IC0tDQo+ID4gSmF6eiBpcyBub3QgZGVhZC4gSXQganVzdCBzbWVsbHMgZnVubnkuLi4NCg==--To unsubscribe from this list: send the line "unsubscribe devicetree" inthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.orgMore majordomo info at http://vger.kernel.org/majordomo-info.html
This patch adds iommu-map property for PCIe, which enables
SMMU for these devices on LS208xA devices.
Signed-off-by: Bharat Bhushan <redacted> ---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 ++++ 1
file changed, 4 insertions(+)
diff --git
a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi index
94cdd30..67cf605 100644 ---
a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi +++
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi @@ -606,6
+606,7 @@ num-lanes = <4>; bus-range = <0x0 0xff>;
msi-parent = <&its>; + iommu-map = <0 &smmu 0 1>; /* This
is fixed-up by
u-boot */
What does this do when your version of u-boot doesn't fill
this in for
you?
quoted
quoted
Good question, frankly I have not thought of this case before.
But if we pass length = 0 in above property then no fixup
happen with happen with older u-boot. In this case
of_iommu_configure() will return NULL iommu-ops and it switch
to swio-tlb. Will that work?
I really don't like this. You rely on having invalid data in the
DT, and that seems just wrong.
Why can't u-boot just generate that property, and we leave the DT
alone?
We do not have smmu phandle allowing uboot to generate this.
quoted
Or even better, you provide the right information for the few
boards that are based on this SoC, not relying on u-boot for
anything that is in the kernel tree?
On our platforms we have a h/w table which converts RID->Device-Id.
I will check what will happen if that table is not initialized, can
RID be equal to device-id is that case. If that will be allowed
than we can give right information that will work with u-boot not
updating this property.
U-boot uses a stream-id allocator and programs the h/w mapping table
(rid to sid mapping table). Also it updates iommu-map property
accordingly. But If u-boot does not update iommu-map than we cannot
have a valid full proof solution as stream-id allocation can change
in u-boot.
So the other option of u-boot generating this entry seems correct
solution. This requires u-boot to know iommu-phandle, something
similar to "msi-parent" used for "msi-map" Device-tree binding need
change to add iommu-phandle/iommu-parent for this.
From what I know of this hardware, it's going to be rather difficult to
concoct a DT which reflects the initial hardware state accurately *and*
works correctly without updating u-boot in lockstep. IIRC, I believe the
accurate description for an unprogrammed LUT would be "everything comes
out on the default ID, which defaults to 0", i.e.:
iommu-map-mask = <0x0>;
iommu-map = <0x0 &smmu 0x0 0x1>;
(assuming the SMMU has stream-id-mask set appropriately too)
That's OK except if u-boot updates the map without removing the mask,
whereupon things will go wrong, and I guess that would be the case with
current u-boot :(
However, the existing MSI description is already bogus - if u-boot
didn't program the LUT, the ITS driver would treat the invalid
"msi-parent" property as this:
msi-map = <0x0 &its 0x0 0xffff>;
which means that nobody other than 0:0.0 has working MSIs anyway.
If you want an obviously-invalid placeholder equivalent to the use of
"msi-parent" then I'd suggest just:
iommus = <&smmu>;
which would be ignored by Linux for PCI devices, so provided you didn't
disable bypass at the SMMU things might in theory still work in the
"u-boot does nothing" case. Otherwise, the implied identity map is
probably slightly preferable to the unit-length map, i.e.:
iommu-map = <0x0 &smmu 0x0 0xffff>;
which is at least equally broken as MSIs in the same situation.
Robin.
-----Original Message-----
From: Robin Murphy [mailto:robin.murphy@arm.com]
Sent: Friday, September 01, 2017 4:29 PM
To: Bharat Bhushan <redacted>; Marc Zyngier
[off-list ref]; robh+dt@kernel.org; Mark Rutland
[off-list ref]; will.deacon@arm.com; oss@buserror.net; Gang
Liu [off-list ref]; devicetree@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
catalin.marinas@arm.com
Subject: Re: [PATCH] RM64: dts: ls208xa: Add iommu-map property for pci
On 01/09/17 11:13, Bharat Bhushan wrote:
quoted
quoted
-----Original Message----- From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel- owner@vger.kernel.org] On Behalf Of Bharat
Bhushan Sent: Thursday, August 31, 2017 4:53 PM To: Marc Zyngier
[off-list ref]; robh+dt@kernel.org; Mark Rutland
[off-list ref]; will.deacon@arm.com; oss@buserror.net;
Gang
quoted
quoted
Liu [off-list ref]; devicetree@vger.kernel.org;
linux-arm-kernel@lists.infradead.org; linux- kernel@vger.kernel.org;
catalin.marinas@arm.com Subject: RE:
[PATCH] RM64: dts: ls208xa: Add iommu-map property for pci
quoted
-----Original Message----- From: Marc Zyngier
[mailto:marc.zyngier@arm.com] Sent: Thursday, August 31, 2017
4:20 PM To: Bharat Bhushan [off-list ref];
robh+dt@kernel.org;
Mark
quoted
Rutland [off-list ref]; will.deacon@arm.com;
oss@buserror.net;
quoted
Gang Liu [off-list ref]; devicetree@vger.kernel.org;
linux-arm-kernel@lists.infradead.org; linux- kernel@vger.kernel.org;
catalin.marinas@arm.com Subject: Re:
[PATCH] RM64: dts: ls208xa: Add iommu-map property for pci
[Fixing Mark's address...]
On 31/08/17 11:41, Bharat Bhushan wrote:
quoted
quoted
-----Original Message----- From: Marc Zyngier
[mailto:marc.zyngier@arm.com] Sent: Thursday, August 31, 2017
3:02 PM To: Bharat Bhushan [off-list ref];
robh+dt@kernel.org; ark.rutland@arm.com; will.deacon@arm.com;
oss@buserror.net; Gang
u-boot */
What does this do when your version of u-boot doesn't fill this in
for
you?
quoted
quoted
Good question, frankly I have not thought of this case before.
But if we pass length = 0 in above property then no fixup happen
with happen with older u-boot. In this case
of_iommu_configure() will return NULL iommu-ops and it switch to
swio-tlb. Will that work?
I really don't like this. You rely on having invalid data in the DT,
and that seems just wrong.
Why can't u-boot just generate that property, and we leave the DT
alone?
We do not have smmu phandle allowing uboot to generate this.
quoted
Or even better, you provide the right information for the few boards
that are based on this SoC, not relying on u-boot for anything that
is in the kernel tree?
On our platforms we have a h/w table which converts RID->Device-Id.
I will check what will happen if that table is not initialized, can
RID be equal to device-id is that case. If that will be allowed than
we can give right information that will work with u-boot not updating
this property.
U-boot uses a stream-id allocator and programs the h/w mapping table
(rid to sid mapping table). Also it updates iommu-map property
accordingly. But If u-boot does not update iommu-map than we cannot
have a valid full proof solution as stream-id allocation can change in
u-boot.
So the other option of u-boot generating this entry seems correct
solution. This requires u-boot to know iommu-phandle, something
similar to "msi-parent" used for "msi-map" Device-tree binding need
change to add iommu-phandle/iommu-parent for this.
From what I know of this hardware, it's going to be rather difficult to concoct
a DT which reflects the initial hardware state accurately *and* works
correctly without updating u-boot in lockstep. IIRC, I believe the accurate
description for an unprogrammed LUT would be "everything comes out on
the default ID, which defaults to 0", i.e.:
iommu-map-mask = <0x0>;
iommu-map = <0x0 &smmu 0x0 0x1>;
These changes are not enough to make PCI devise working with LUT disabled, also needed msi-map maps all requester-id to "0", using "msi-map-mask = 0x0".
Why we assume that no "msi-map" property means untranslated requested-id, why not consider that translated to "0".
(assuming the SMMU has stream-id-mask set appropriately too)
That's OK except if u-boot updates the map without removing the mask,
whereupon things will go wrong, and I guess that would be the case with
current u-boot :(
However, the existing MSI description is already bogus - if u-boot didn't
program the LUT, the ITS driver would treat the invalid "msi-parent" property
as this:
msi-map = <0x0 &its 0x0 0xffff>;
which means that nobody other than 0:0.0 has working MSIs anyway.
We can have following version of u-boot:
1) No LUT setup, does not generate msi-map and does not update/generate iommu-map (older u-boot)
For this case the working device tree changes can be:
iommu-map-mask = <0>;
iommu-map = <0x0 &smmu 0 0x1>;
msi-map-mask = <0x0>;
msi-map = <0x0 &its 0 0x1>;
But these changes will not work with current version of u-boot (below (2))
2) LUT setup and msi-map generated but no iommu-map generated (current case)
I do not see we can have a working device tree for this.
Probably generating iommu-map in u-boot is better, with that msi-map and iommu-map will be consistent (below (4))
3) LUT setup, "msi-map" generated and iommu-map updated
We can have below change is device tree.
iommu-map = <0x0 &smmu 0 0x1>;
But this change will not work with (1) and (2) above.
4) LUT setup, "msi-map" generated and iommu-map also generated by u-boot.
There is no iommu-map entry needed in device tree but u-boot need to know iommu phandle.
While iommus is supposed to be used in iommu-node and not in pci node.
Looking for suggestion
Thanks
-Bharat
If you want an obviously-invalid placeholder equivalent to the use of "msi-
parent" then I'd suggest just:
iommus = <&smmu>;
which would be ignored by Linux for PCI devices, so provided you didn't
disable bypass at the SMMU things might in theory still work in the "u-boot
does nothing" case. Otherwise, the implied identity map is probably slightly
preferable to the unit-length map, i.e.:
iommu-map = <0x0 &smmu 0x0 0xffff>;
which is at least equally broken as MSIs in the same situation.
Robin.
SGkgUm9iaW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGludXgta2VybmVsLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LWtlcm5lbC0NCj4gb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgQmhhcmF0IEJodXNoYW4NCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTcgMTI6NDcgUE0NCj4gVG86IFJvYmluIE11cnBoeSA8cm9iaW4ubXVycGh5QGFybS5jb20+OyBNYXJjIFp5bmdpZXINCj4gPG1hcmMuenluZ2llckBhcm0uY29tPjsgcm9iaCtkdEBrZXJuZWwub3JnOyBNYXJrIFJ1dGxhbmQNCj4gPG1hcmsucnV0bGFuZEBhcm0uY29tPjsgd2lsbC5kZWFjb25AYXJtLmNvbTsgb3NzQGJ1c2Vycm9yLm5ldDsgR2FuZw0KPiBMaXUgPGdhbmcubGl1QG54cC5jb20+OyBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsgbGludXgtYXJtLQ0KPiBrZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsNCj4gY2F0YWxpbi5tYXJpbmFzQGFybS5jb20NCj4gU3ViamVjdDogUkU6IFtQQVRDSF0gUk02NDogZHRzOiBsczIwOHhhOiBBZGQgaW9tbXUtbWFwIHByb3BlcnR5IGZvciBwY2kNCj4gDQo+IEhpIFJvYmluLA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFJvYmluIE11cnBoeSBbbWFpbHRvOnJvYmluLm11cnBoeUBhcm0uY29tXQ0KPiA+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDAxLCAyMDE3IDQ6MjkgUE0NCj4gPiBUbzogQmhhcmF0IEJodXNoYW4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+OyBNYXJjIFp5bmdpZXINCj4gPiA8bWFyYy56eW5naWVyQGFybS5jb20+OyByb2JoK2R0QGtlcm5lbC5vcmc7IE1hcmsgUnV0bGFuZA0KPiA+IDxtYXJrLnJ1dGxhbmRAYXJtLmNvbT47IHdpbGwuZGVhY29uQGFybS5jb207IG9zc0BidXNlcnJvci5uZXQ7DQo+IEdhbmcNCj4gPiBMaXUgPGdhbmcubGl1QG54cC5jb20+OyBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsgbGludXgtYXJtLQ0KPiA+IGtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOw0KPiA+IGNhdGFsaW4ubWFyaW5hc0Bhcm0uY29tDQo+ID4gU3ViamVjdDogUmU6IFtQQVRDSF0gUk02NDogZHRzOiBsczIwOHhhOiBBZGQgaW9tbXUtbWFwIHByb3BlcnR5IGZvcg0KPiA+IHBjaQ0KPiA+DQo+ID4gT24gMDEvMDkvMTcgMTE6MTMsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4NCj4gPiA+DQo+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogbGludXgta2VybmVsLW93bmVyQHZnZXIua2VybmVsLm9yZw0KPiA+ID4+IFttYWlsdG86bGludXgta2VybmVsLSBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBCaGFyYXQNCj4gPiA+PiBCaHVzaGFuIFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMzEsIDIwMTcgNDo1MyBQTSBUbzogTWFyYyBaeW5naWVyDQo+ID4gPj4gPG1hcmMuenluZ2llckBhcm0uY29tPjsgcm9iaCtkdEBrZXJuZWwub3JnOyBNYXJrIFJ1dGxhbmQNCj4gPiA+PiA8bWFyay5ydXRsYW5kQGFybS5jb20+OyB3aWxsLmRlYWNvbkBhcm0uY29tOyBvc3NAYnVzZXJyb3IubmV0Ow0KPiA+IEdhbmcNCj4gPiA+PiBMaXUgPGdhbmcubGl1QG54cC5jb20+OyBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsNCj4gPiA+PiBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7IGxpbnV4LQ0KPiA+ID4+IGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGNhdGFsaW4ubWFyaW5hc0Bhcm0uY29tIFN1YmplY3Q6IFJFOg0KPiA+ID4+IFtQQVRDSF0gUk02NDogZHRzOiBsczIwOHhhOiBBZGQgaW9tbXUtbWFwIHByb3BlcnR5IGZvciBwY2kNCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogTWFyYyBaeW5naWVyDQo+ID4gPj4+IFttYWlsdG86bWFyYy56eW5naWVyQGFybS5jb21dIFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMzEsIDIwMTcNCj4gPiA+Pj4gNDoyMCBQTSBUbzogQmhhcmF0IEJodXNoYW4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+Ow0KPiA+ID4+PiByb2JoK2R0QGtlcm5lbC5vcmc7DQo+ID4gPj4gTWFyaw0KPiA+ID4+PiBSdXRsYW5kIDxtYXJrLnJ1dGxhbmRAYXJtLmNvbT47IHdpbGwuZGVhY29uQGFybS5jb207DQo+ID4gPj4gb3NzQGJ1c2Vycm9yLm5ldDsNCj4gPiA+Pj4gR2FuZyBMaXUgPGdhbmcubGl1QG54cC5jb20+OyBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsNCj4gPiA+Pj4gbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eC0NCj4gPiA+Pj4ga2VybmVsQHZnZXIua2VybmVsLm9yZzsgY2F0YWxpbi5tYXJpbmFzQGFybS5jb20gU3ViamVjdDogUmU6DQo+ID4gPj4+IFtQQVRDSF0gUk02NDogZHRzOiBsczIwOHhhOiBBZGQgaW9tbXUtbWFwIHByb3BlcnR5IGZvciBwY2kNCj4gPiA+Pj4NCj4gPiA+Pj4gW0ZpeGluZyBNYXJrJ3MgYWRkcmVzcy4uLl0NCj4gPiA+Pj4NCj4gPiA+Pj4gT24gMzEvMDgvMTcgMTE6NDEsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4+Pj4NCj4gPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBNYXJjIFp5bmdpZXINCj4gPiA+Pj4+PiBbbWFpbHRvOm1hcmMuenluZ2llckBhcm0uY29tXSBTZW50OiBUaHVyc2RheSwgQXVndXN0IDMxLCAyMDE3DQo+ID4gPj4+Pj4gMzowMiBQTSBUbzogQmhhcmF0IEJodXNoYW4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+Ow0KPiA+ID4+Pj4+IHJvYmgrZHRAa2VybmVsLm9yZzsgYXJrLnJ1dGxhbmRAYXJtLmNvbTsgd2lsbC5kZWFjb25AYXJtLmNvbTsNCj4gPiA+Pj4+PiBvc3NAYnVzZXJyb3IubmV0OyBHYW5nDQo+ID4gPj4+IExpdQ0KPiA+ID4+Pj4+IDxnYW5nLmxpdUBueHAuY29tPjsgZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWFybS0NCj4gPiA+Pj4+PiBrZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsNCj4gPiA+Pj4+PiBjYXRhbGluLm1hcmluYXNAYXJtLmNvbSBTdWJqZWN0OiBSZTogW1BBVENIXSBSTTY0OiBkdHM6DQo+ID4gPj4+Pj4gbHMyMDh4YTogQWRkIGlvbW11LW1hcCBwcm9wZXJ0eSBmb3IgcGNpDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBPbiAzMS8wOC8xNyAxMDoyMywgQmhhcmF0IEJodXNoYW4gd3JvdGU6DQo+ID4gPj4+Pj4+IFRoaXMgcGF0Y2ggYWRkcyBpb21tdS1tYXAgcHJvcGVydHkgZm9yIFBDSWUsIHdoaWNoIGVuYWJsZXMNCj4gPiBTTU1VDQo+ID4gPj4+Pj4+IGZvciB0aGVzZSBkZXZpY2VzIG9uIExTMjA4eEEgZGV2aWNlcy4NCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogQmhhcmF0IEJodXNoYW4gPEJoYXJhdC5CaHVzaGFuQG54cC5jb20+IC0tLQ0KPiA+ID4+Pj4+PiBhcmNoL2FybTY0L2Jvb3QvZHRzL2ZyZWVzY2FsZS9mc2wtbHMyMDh4YS5kdHNpIHwgNCArKysrIDEgZmlsZQ0KPiA+ID4+Pj4+PiBjaGFuZ2VkLCA0IGluc2VydGlvbnMoKykNCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gZGlmZiAtLWdpdA0KPiA+ID4+Pj4+PiBhL2FyY2gvYXJtNjQvYm9vdC9kdHMvZnJlZXNjYWxlL2ZzbC1sczIwOHhhLmR0c2kNCj4gPiA+Pj4+Pj4gYi9hcmNoL2FybTY0L2Jvb3QvZHRzL2ZyZWVzY2FsZS9mc2wtbHMyMDh4YS5kdHNpIGluZGV4DQo+ID4gPj4+Pj4+IDk0Y2RkMzAuLjY3Y2Y2MDUgMTAwNjQ0IC0tLQ0KPiA+ID4+Pj4+PiBhL2FyY2gvYXJtNjQvYm9vdC9kdHMvZnJlZXNjYWxlL2ZzbC1sczIwOHhhLmR0c2kgKysrDQo+ID4gPj4+Pj4+IGIvYXJjaC9hcm02NC9ib290L2R0cy9mcmVlc2NhbGUvZnNsLWxzMjA4eGEuZHRzaSBAQCAtNjA2LDYNCj4gPiA+Pj4+Pj4gKzYwNiw3IEBAIG51bS1sYW5lcyA9IDw0PjsgYnVzLXJhbmdlID0gPDB4MCAweGZmPjsNCj4gPiA+Pj4+Pj4gbXNpLXBhcmVudCA9IDwmaXRzPjsgKwkJCWlvbW11LW1hcCA9IDwwDQo+ICZzbW11IDANCj4gPiAxPjsJLyogVGhpcw0KPiA+ID4+Pj4+PiBpcyBmaXhlZC11cCBieQ0KPiA+ID4+Pj4+IHUtYm9vdCAqLw0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gV2hhdCBkb2VzIHRoaXMgZG8gd2hlbiB5b3VyIHZlcnNpb24gb2YgdS1ib290IGRvZXNuJ3QgZmlsbCB0aGlzDQo+ID4gPj4+Pj4gaW4gZm9yDQo+ID4gPj4geW91Pw0KPiA+ID4+Pj4NCj4gPiA+Pj4+IEdvb2QgcXVlc3Rpb24sIGZyYW5rbHkgSSBoYXZlIG5vdCB0aG91Z2h0IG9mIHRoaXMgY2FzZSBiZWZvcmUuDQo+ID4gPj4+PiBCdXQgaWYgd2UgcGFzcyBsZW5ndGggPSAwIGluIGFib3ZlIHByb3BlcnR5IHRoZW4gbm8gZml4dXAgaGFwcGVuDQo+ID4gPj4+PiB3aXRoIGhhcHBlbiB3aXRoIG9sZGVyIHUtYm9vdC4gSW4gdGhpcyBjYXNlDQo+ID4gPj4+PiBvZl9pb21tdV9jb25maWd1cmUoKSB3aWxsIHJldHVybiBOVUxMIGlvbW11LW9wcyBhbmQgaXQgc3dpdGNoIHRvDQo+ID4gPj4+PiBzd2lvLXRsYi4gV2lsbCB0aGF0IHdvcms/DQo+ID4gPj4+IEkgcmVhbGx5IGRvbid0IGxpa2UgdGhpcy4gWW91IHJlbHkgb24gaGF2aW5nIGludmFsaWQgZGF0YSBpbiB0aGUNCj4gPiA+Pj4gRFQsIGFuZCB0aGF0IHNlZW1zIGp1c3Qgd3JvbmcuDQo+ID4gPj4+DQo+ID4gPj4+IFdoeSBjYW4ndCB1LWJvb3QganVzdCBnZW5lcmF0ZSB0aGF0IHByb3BlcnR5LCBhbmQgd2UgbGVhdmUgdGhlIERUDQo+ID4gPj4+IGFsb25lPw0KPiA+ID4+DQo+ID4gPj4gV2UgZG8gbm90IGhhdmUgc21tdSBwaGFuZGxlIGFsbG93aW5nIHVib290IHRvIGdlbmVyYXRlIHRoaXMuDQo+ID4gPj4NCj4gPiA+Pj4gT3IgZXZlbiBiZXR0ZXIsIHlvdSBwcm92aWRlIHRoZSByaWdodCBpbmZvcm1hdGlvbiBmb3IgdGhlIGZldw0KPiA+ID4+PiBib2FyZHMgdGhhdCBhcmUgYmFzZWQgb24gdGhpcyBTb0MsIG5vdCByZWx5aW5nIG9uIHUtYm9vdCBmb3INCj4gPiA+Pj4gYW55dGhpbmcgdGhhdCBpcyBpbiB0aGUga2VybmVsIHRyZWU/DQo+ID4gPj4NCj4gPiA+PiBPbiBvdXIgcGxhdGZvcm1zIHdlIGhhdmUgYSBoL3cgdGFibGUgd2hpY2ggY29udmVydHMgUklELT5EZXZpY2UtSWQuDQo+ID4gPj4gSSB3aWxsIGNoZWNrIHdoYXQgd2lsbCBoYXBwZW4gaWYgdGhhdCB0YWJsZSBpcyBub3QgaW5pdGlhbGl6ZWQsIGNhbg0KPiA+ID4+IFJJRCBiZSBlcXVhbCB0byBkZXZpY2UtaWQgaXMgdGhhdCBjYXNlLiBJZiB0aGF0IHdpbGwgYmUgYWxsb3dlZA0KPiA+ID4+IHRoYW4gd2UgY2FuIGdpdmUgcmlnaHQgaW5mb3JtYXRpb24gdGhhdCB3aWxsIHdvcmsgd2l0aCB1LWJvb3Qgbm90DQo+ID4gPj4gdXBkYXRpbmcgdGhpcyBwcm9wZXJ0eS4NCj4gPiA+DQo+ID4gPiBVLWJvb3QgdXNlcyBhIHN0cmVhbS1pZCBhbGxvY2F0b3IgYW5kIHByb2dyYW1zIHRoZSBoL3cgbWFwcGluZyB0YWJsZQ0KPiA+ID4gKHJpZCB0byBzaWQgbWFwcGluZyB0YWJsZSkuIEFsc28gaXQgdXBkYXRlcyBpb21tdS1tYXAgcHJvcGVydHkNCj4gPiA+IGFjY29yZGluZ2x5LiBCdXQgSWYgdS1ib290IGRvZXMgbm90IHVwZGF0ZSBpb21tdS1tYXAgdGhhbiB3ZSBjYW5ub3QNCj4gPiA+IGhhdmUgYSB2YWxpZCBmdWxsIHByb29mIHNvbHV0aW9uIGFzIHN0cmVhbS1pZCBhbGxvY2F0aW9uIGNhbiBjaGFuZ2UNCj4gPiA+IGluIHUtYm9vdC4NCj4gPiA+DQo+ID4gPiBTbyB0aGUgb3RoZXIgb3B0aW9uIG9mIHUtYm9vdCBnZW5lcmF0aW5nIHRoaXMgZW50cnkgc2VlbXMgY29ycmVjdA0KPiA+ID4gc29sdXRpb24uIFRoaXMgcmVxdWlyZXMgdS1ib290IHRvIGtub3cgaW9tbXUtcGhhbmRsZSwgc29tZXRoaW5nDQo+ID4gPiBzaW1pbGFyIHRvICJtc2ktcGFyZW50IiB1c2VkIGZvciAibXNpLW1hcCIgRGV2aWNlLXRyZWUgYmluZGluZyBuZWVkDQo+ID4gPiBjaGFuZ2UgdG8gYWRkIGlvbW11LXBoYW5kbGUvaW9tbXUtcGFyZW50IGZvciB0aGlzLg0KPiA+DQo+ID4gRnJvbSB3aGF0IEkga25vdyBvZiB0aGlzIGhhcmR3YXJlLCBpdCdzIGdvaW5nIHRvIGJlIHJhdGhlciBkaWZmaWN1bHQNCj4gPiB0byBjb25jb2N0IGEgRFQgd2hpY2ggcmVmbGVjdHMgdGhlIGluaXRpYWwgaGFyZHdhcmUgc3RhdGUgYWNjdXJhdGVseQ0KPiA+ICphbmQqIHdvcmtzIGNvcnJlY3RseSB3aXRob3V0IHVwZGF0aW5nIHUtYm9vdCBpbiBsb2Nrc3RlcC4gSUlSQywgSQ0KPiA+IGJlbGlldmUgdGhlIGFjY3VyYXRlIGRlc2NyaXB0aW9uIGZvciBhbiB1bnByb2dyYW1tZWQgTFVUIHdvdWxkIGJlDQo+ID4gImV2ZXJ5dGhpbmcgY29tZXMgb3V0IG9uIHRoZSBkZWZhdWx0IElELCB3aGljaCBkZWZhdWx0cyB0byAwIiwgaS5lLjoNCj4gPg0KPiA+IAlpb21tdS1tYXAtbWFzayA9IDwweDA+Ow0KPiA+IAlpb21tdS1tYXAgPSA8MHgwICZzbW11IDB4MCAweDE+Ow0KPiANCj4gVGhlc2UgY2hhbmdlcyBhcmUgbm90IGVub3VnaCB0byBtYWtlIFBDSSBkZXZpc2Ugd29ya2luZyB3aXRoIExVVA0KPiBkaXNhYmxlZCwgYWxzbyBuZWVkZWQgbXNpLW1hcCBtYXBzIGFsbCByZXF1ZXN0ZXItaWQgdG8gIjAiLCB1c2luZyAibXNpLW1hcC0NCj4gbWFzayA9IDB4MCIuDQo+IA0KPiBXaHkgd2UgYXNzdW1lIHRoYXQgbm8gIm1zaS1tYXAiIHByb3BlcnR5IG1lYW5zIHVudHJhbnNsYXRlZCByZXF1ZXN0ZWQtDQo+IGlkLCB3aHkgbm90IGNvbnNpZGVyIHRoYXQgdHJhbnNsYXRlZCB0byAiMCIuDQo+IA0KPiA+DQo+ID4gKGFzc3VtaW5nIHRoZSBTTU1VIGhhcyBzdHJlYW0taWQtbWFzayBzZXQgYXBwcm9wcmlhdGVseSB0b28pDQo+ID4NCj4gPiBUaGF0J3MgT0sgZXhjZXB0IGlmIHUtYm9vdCB1cGRhdGVzIHRoZSBtYXAgd2l0aG91dCByZW1vdmluZyB0aGUgbWFzaywNCj4gPiB3aGVyZXVwb24gdGhpbmdzIHdpbGwgZ28gd3JvbmcsIGFuZCBJIGd1ZXNzIHRoYXQgd291bGQgYmUgdGhlIGNhc2UNCj4gPiB3aXRoIGN1cnJlbnQgdS1ib290IDooDQo+ID4NCj4gPiBIb3dldmVyLCB0aGUgZXhpc3RpbmcgTVNJIGRlc2NyaXB0aW9uIGlzIGFscmVhZHkgYm9ndXMgLSBpZiB1LWJvb3QNCj4gPiBkaWRuJ3QgcHJvZ3JhbSB0aGUgTFVULCB0aGUgSVRTIGRyaXZlciB3b3VsZCB0cmVhdCB0aGUgaW52YWxpZA0KPiA+ICJtc2ktcGFyZW50IiBwcm9wZXJ0eSBhcyB0aGlzOg0KPiA+DQo+ID4gCW1zaS1tYXAgPSA8MHgwICZpdHMgMHgwIDB4ZmZmZj47DQo+ID4NCj4gPiB3aGljaCBtZWFucyB0aGF0IG5vYm9keSBvdGhlciB0aGFuIDA6MC4wIGhhcyB3b3JraW5nIE1TSXMgYW55d2F5Lg0KPiANCj4gV2UgY2FuIGhhdmUgZm9sbG93aW5nIHZlcnNpb24gb2YgdS1ib290Og0KPiAgMSkgTm8gTFVUIHNldHVwLCBkb2VzIG5vdCBnZW5lcmF0ZSBtc2ktbWFwIGFuZCBkb2VzIG5vdCB1cGRhdGUvZ2VuZXJhdGUNCj4gaW9tbXUtbWFwIChvbGRlciB1LWJvb3QpDQo+IA0KPiAgICAgIEZvciB0aGlzIGNhc2UgdGhlIHdvcmtpbmcgZGV2aWNlIHRyZWUgY2hhbmdlcyBjYW4gYmU6DQo+ICAgICAgICAgICAgICAgICAgICAgICAgaW9tbXUtbWFwLW1hc2sgPSA8MD47DQo+ICAgICAgICAgICAgICAgICAgICAgICAgaW9tbXUtbWFwID0gPDB4MCAmc21tdSAwIDB4MT47DQo+ICAgICAgICAgICAgICAgICAgICAgICAgbXNpLW1hcC1tYXNrID0gPDB4MD47DQo+ICAgICAgICAgICAgICAgICAgICAgICAgbXNpLW1hcCA9IDwweDAgJml0cyAwIDB4MT47DQo+IA0KPiAgICAgIEJ1dCB0aGVzZSBjaGFuZ2VzIHdpbGwgbm90IHdvcmsgd2l0aCBjdXJyZW50IHZlcnNpb24gb2YgdS1ib290IChiZWxvdyAoMikpDQo+IA0KPiAyKSBMVVQgc2V0dXAgYW5kIG1zaS1tYXAgZ2VuZXJhdGVkIGJ1dCBubyBpb21tdS1tYXAgZ2VuZXJhdGVkIChjdXJyZW50DQo+IGNhc2UpDQo+IA0KPiAgICAgSSBkbyBub3Qgc2VlIHdlIGNhbiBoYXZlIGEgd29ya2luZyBkZXZpY2UgdHJlZSBmb3IgdGhpcy4NCj4gICAgIFByb2JhYmx5IGdlbmVyYXRpbmcgaW9tbXUtbWFwIGluIHUtYm9vdCBpcyBiZXR0ZXIsIHdpdGggdGhhdCBtc2ktbWFwIGFuZA0KPiBpb21tdS1tYXAgd2lsbCBiZSBjb25zaXN0ZW50IChiZWxvdyAoNCkpDQo+IA0KPiAzKSBMVVQgc2V0dXAsICJtc2ktbWFwIiBnZW5lcmF0ZWQgYW5kIGlvbW11LW1hcCB1cGRhdGVkDQo+IA0KPiAgICAgICBXZSBjYW4gaGF2ZSBiZWxvdyBjaGFuZ2UgaXMgZGV2aWNlIHRyZWUuDQo+ICAgICAgICAJICAgICAgICAgaW9tbXUtbWFwID0gPDB4MCAmc21tdSAwIDB4MT47DQo+IA0KPiAgICAgICAgQnV0IHRoaXMgY2hhbmdlIHdpbGwgbm90IHdvcmsgd2l0aCAoMSkgYW5kICgyKSBhYm92ZS4NCj4gDQo+IDQpIExVVCBzZXR1cCwgIm1zaS1tYXAiIGdlbmVyYXRlZCBhbmQgaW9tbXUtbWFwIGFsc28gZ2VuZXJhdGVkIGJ5IHUtDQo+IGJvb3QuDQo+ICAgICBUaGVyZSBpcyBubyBpb21tdS1tYXAgZW50cnkgbmVlZGVkIGluIGRldmljZSB0cmVlIGJ1dCB1LWJvb3QgbmVlZCB0bw0KPiBrbm93IGlvbW11IHBoYW5kbGUuDQo+ICAgICBXaGlsZSBpb21tdXMgaXMgc3VwcG9zZWQgdG8gYmUgdXNlZCBpbiBpb21tdS1ub2RlIGFuZCBub3QgaW4gcGNpIG5vZGUuDQo+IA0KPiBMb29raW5nIGZvciBzdWdnZXN0aW9uDQoNCkJlbG93IHByb3BlcnRpZXMgYXMgc3VnZ2VzdGVkIGJ5IHlvdSBhcmUgY29ycmVjdCBmcm9tIGgvdyBiZWhhdmlvciBwZXJzcGVjdGl2ZQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBpb21tdS1tYXAtbWFzayA9IDwwPjsNCiAgICAgICAgICAgICAgICAgICAgICAgIGlvbW11LW1hcCA9IDwweDAgJnNtbXUgMCAweDE+Ow0KDQpBcmUgeW91IG9rIHdpdGggdGhlc2UgY2hhbmdlcz8NCg0KVGhhbmtzDQotQmhhcmF0DQoNCj4gDQo+IFRoYW5rcw0KPiAtQmhhcmF0DQo+IA0KPiA+DQo+ID4gSWYgeW91IHdhbnQgYW4gb2J2aW91c2x5LWludmFsaWQgcGxhY2Vob2xkZXIgZXF1aXZhbGVudCB0byB0aGUgdXNlIG9mDQo+ID4gIm1zaS0gcGFyZW50IiB0aGVuIEknZCBzdWdnZXN0IGp1c3Q6DQo+ID4NCj4gPiAJaW9tbXVzID0gPCZzbW11PjsNCj4gPg0KPiA+IHdoaWNoIHdvdWxkIGJlIGlnbm9yZWQgYnkgTGludXggZm9yIFBDSSBkZXZpY2VzLCBzbyBwcm92aWRlZCB5b3UNCj4gPiBkaWRuJ3QgZGlzYWJsZSBieXBhc3MgYXQgdGhlIFNNTVUgdGhpbmdzIG1pZ2h0IGluIHRoZW9yeSBzdGlsbCB3b3JrIGluDQo+ID4gdGhlICJ1LWJvb3QgZG9lcyBub3RoaW5nIiBjYXNlLiBPdGhlcndpc2UsIHRoZSBpbXBsaWVkIGlkZW50aXR5IG1hcCBpcw0KPiA+IHByb2JhYmx5IHNsaWdodGx5IHByZWZlcmFibGUgdG8gdGhlIHVuaXQtbGVuZ3RoIG1hcCwgaS5lLjoNCj4gPg0KPiA+IAlpb21tdS1tYXAgPSA8MHgwICZzbW11IDB4MCAweGZmZmY+Ow0KPiA+DQo+ID4gd2hpY2ggaXMgYXQgbGVhc3QgZXF1YWxseSBicm9rZW4gYXMgTVNJcyBpbiB0aGUgc2FtZSBzaXR1YXRpb24uDQo+ID4NCj4gPiBSb2Jpbi4NCg==--To unsubscribe from this list: send the line "unsubscribe devicetree" inthe body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.orgMore majordomo info at http://vger.kernel.org/majordomo-info.html
From: Mark Rutland <mark.rutland@arm.com> Date: 2017-08-31 11:31:59
On Thu, Aug 31, 2017 at 11:49:37AM +0100, Marc Zyngier wrote:
[Fixing Mark's address...]
Thanks!
On 31/08/17 11:41, Bharat Bhushan wrote:
quoted
quoted
-----Original Message-----
From: Marc Zyngier [mailto:marc.zyngier-5wv7dgnIgG8@public.gmane.org]
Sent: Thursday, August 31, 2017 3:02 PM
To: Bharat Bhushan <redacted>; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org;
ark.rutland-5wv7dgnIgG8@public.gmane.org; will.deacon-5wv7dgnIgG8@public.gmane.org; oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org; Gang Liu
[off-list ref]; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
catalin.marinas-5wv7dgnIgG8@public.gmane.org
Subject: Re: [PATCH] RM64: dts: ls208xa: Add iommu-map property for pci
On 31/08/17 10:23, Bharat Bhushan wrote:
quoted
This patch adds iommu-map property for PCIe, which enables SMMU for
these devices on LS208xA devices.
Signed-off-by: Bharat Bhushan <redacted>
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 ++++
1 file changed, 4 insertions(+)
@@ -606,6 +606,7 @@num-lanes=<4>;bus-range=<0x00xff>;msi-parent=<&its>;+iommu-map=<0&smmu01>;/* This is fixed-up by
u-boot */
What does this do when your version of u-boot doesn't fill this in for you?
Good question, frankly I have not thought of this case before.
But if we pass length = 0 in above property then no fixup happen with
happen with older u-boot. In this case of_iommu_configure() will
return NULL iommu-ops and it switch to swio-tlb. Will that work?
I really don't like this. You rely on having invalid data in the DT, and
that seems just wrong.
Indeed.
Either the property should be valid (and correctly representing the HW),
or it shouldn't be present. Relying on kernel implementation details is
*not* OK.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html