* Question about a quirky (DesignWare) PCIe RC in Allwinner H6 @ 2018-03-05 14:50 Icenowy Zheng 2018-03-05 21:47 ` Bjorn Helgaas 0 siblings, 1 reply; 9+ messages in thread From: Icenowy Zheng @ 2018-03-05 14:50 UTC (permalink / raw) To: Bjorn Helgaas, Lorenzo Pieralisi, Maxime Ripard, Chen-Yu Tsai, Joao Pinto, Jingoo Han Cc: linux-pci, linux-sunxi, linux-arm-kernel Hi everyone, I'm trying to implement a driver for the quirky (DW) PCIe RC in the Allwinner H6 SoC. The quirk is that only the "dbi" space is always mapped, but at the same time only 64KiB of other spaces (config, downstream IO and non- prefetchable memory) are accessible. To access a certain address the high 16-bit of the address (all bus addresses in H6 SoC are 32-bit despite the CPU is 64-bit) needs to be written into the PCIE_ADDR_PAGE_CFG register (a vendor-defined register in DBI space). So the access to these spaces cannot be processed correctly with just readl/writel, as the existing code does. Is it possible to workaround this in the PCI subsystem of Linux? (I have thought a workaround that only maps the current accessible 64KiB with the MMU, and when accessing the non-accessible part, catch the page fault and re-setup the map to the new 64KiB page. But surely it will kill the performance.) Thanks, Icenowy _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6 2018-03-05 14:50 Question about a quirky (DesignWare) PCIe RC in Allwinner H6 Icenowy Zheng @ 2018-03-05 21:47 ` Bjorn Helgaas 2018-03-06 3:57 ` Icenowy Zheng 0 siblings, 1 reply; 9+ messages in thread From: Bjorn Helgaas @ 2018-03-05 21:47 UTC (permalink / raw) To: Icenowy Zheng Cc: Lorenzo Pieralisi, Maxime Ripard, Jingoo Han, linux-sunxi, Chen-Yu Tsai, Joao Pinto, linux-pci, Bjorn Helgaas, linux-arm-kernel On Mon, Mar 05, 2018 at 10:50:58PM +0800, Icenowy Zheng wrote: > Hi everyone, > > I'm trying to implement a driver for the quirky (DW) PCIe RC in the > Allwinner H6 SoC. > > The quirk is that only the "dbi" space is always mapped, but at the > same time only 64KiB of other spaces (config, downstream IO and non- > prefetchable memory) are accessible. To access a certain address the > high 16-bit of the address (all bus addresses in H6 SoC are 32-bit > despite the CPU is 64-bit) needs to be written into the > PCIE_ADDR_PAGE_CFG register (a vendor-defined register in DBI space). > So the access to these spaces cannot be processed correctly with just > readl/writel, as the existing code does. > > Is it possible to workaround this in the PCI subsystem of Linux? > > (I have thought a workaround that only maps the current accessible > 64KiB with the MMU, and when accessing the non-accessible part, catch > the page fault and re-setup the map to the new 64KiB page. But surely > it will kill the performance.) If you only need to write to PCIE_ADDR_PAGE_CFG for *config* accesses, this should be easy. All config accesses go through wrappers (pci_read_config_word(), etc) and several host bridge drivers have to update a register with parts of the config address, e.g., advk_pcie_rd_conf(), mvebu_pcie_hw_rd_conf(). It sounds like you also need to update PCIE_ADDR_PAGE_CFG for I/O port accesses. I/O port accesses do go through a wrapper (inb(), etc), so it might be possible in principle to intercept these, although much more difficult than config accesses, because the config accesses are already set up with per-host bridge hooks, while the I/O port accessors are mostly per-arch. But if you have to update PCIE_ADDR_PAGE_CFG for memory accesses, that's really a problem because drivers are allowed to essentially read a memory BAR, convert that bus address to a CPU physical memory address, ioremap() it, then directly access the PCIe memory with loads and stores. Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6 2018-03-05 21:47 ` Bjorn Helgaas @ 2018-03-06 3:57 ` Icenowy Zheng 2018-03-06 23:38 ` Bjorn Helgaas 0 siblings, 1 reply; 9+ messages in thread From: Icenowy Zheng @ 2018-03-06 3:57 UTC (permalink / raw) To: Bjorn Helgaas Cc: Joao Pinto, Maxime Ripard, linux-pci, linux-sunxi, Chen-Yu Tsai, Lorenzo Pieralisi, Jingoo Han, linux-arm-kernel 5ZyoIDIwMTgtMDMtMDXkuIDnmoQgMTU6NDcgLTA2MDDvvIxCam9ybiBIZWxnYWFz5YaZ6YGT77ya Cj4gT24gTW9uLCBNYXIgMDUsIDIwMTggYXQgMTA6NTA6NThQTSArMDgwMCwgSWNlbm93eSBaaGVu ZyB3cm90ZToKPiA+IEhpIGV2ZXJ5b25lLAo+ID4gCj4gPiBJJ20gdHJ5aW5nIHRvIGltcGxlbWVu dCBhIGRyaXZlciBmb3IgdGhlIHF1aXJreSAoRFcpIFBDSWUgUkMgaW4gdGhlCj4gPiBBbGx3aW5u ZXIgSDYgU29DLgo+ID4gCj4gPiBUaGUgcXVpcmsgaXMgdGhhdCBvbmx5IHRoZSAiZGJpIiBzcGFj ZSBpcyBhbHdheXMgbWFwcGVkLCBidXQgYXQgdGhlCj4gPiBzYW1lIHRpbWUgb25seSA2NEtpQiBv ZiBvdGhlciBzcGFjZXMgKGNvbmZpZywgZG93bnN0cmVhbSBJTyBhbmQKPiA+IG5vbi0KPiA+IHBy ZWZldGNoYWJsZSBtZW1vcnkpIGFyZSBhY2Nlc3NpYmxlLiBUbyBhY2Nlc3MgYSBjZXJ0YWluIGFk ZHJlc3MKPiA+IHRoZQo+ID4gaGlnaCAxNi1iaXQgb2YgdGhlIGFkZHJlc3MgKGFsbCBidXMgYWRk cmVzc2VzIGluIEg2IFNvQyBhcmUgMzItYml0Cj4gPiBkZXNwaXRlIHRoZSBDUFUgaXMgNjQtYml0 KSBuZWVkcyB0byBiZSB3cml0dGVuIGludG8gdGhlCj4gPiBQQ0lFX0FERFJfUEFHRV9DRkcgcmVn aXN0ZXIgKGEgdmVuZG9yLWRlZmluZWQgcmVnaXN0ZXIgaW4gREJJCj4gPiBzcGFjZSkuCj4gPiBT byB0aGUgYWNjZXNzIHRvIHRoZXNlIHNwYWNlcyBjYW5ub3QgYmUgcHJvY2Vzc2VkIGNvcnJlY3Rs eSB3aXRoCj4gPiBqdXN0Cj4gPiByZWFkbC93cml0ZWwsIGFzIHRoZSBleGlzdGluZyBjb2RlIGRv ZXMuCj4gPiAKPiA+IElzIGl0IHBvc3NpYmxlIHRvIHdvcmthcm91bmQgdGhpcyBpbiB0aGUgUENJ IHN1YnN5c3RlbSBvZiBMaW51eD8KPiA+IAo+ID4gKEkgaGF2ZSB0aG91Z2h0IGEgd29ya2Fyb3Vu ZCB0aGF0IG9ubHkgbWFwcyB0aGUgY3VycmVudCBhY2Nlc3NpYmxlCj4gPiA2NEtpQiB3aXRoIHRo ZSBNTVUsIGFuZCB3aGVuIGFjY2Vzc2luZyB0aGUgbm9uLWFjY2Vzc2libGUgcGFydCwKPiA+IGNh dGNoCj4gPiB0aGUgcGFnZSBmYXVsdCBhbmQgcmUtc2V0dXAgdGhlIG1hcCB0byB0aGUgbmV3IDY0 S2lCIHBhZ2UuIEJ1dAo+ID4gc3VyZWx5Cj4gPiBpdCB3aWxsIGtpbGwgdGhlIHBlcmZvcm1hbmNl LikKPiAKPiBJZiB5b3Ugb25seSBuZWVkIHRvIHdyaXRlIHRvIFBDSUVfQUREUl9QQUdFX0NGRyBm b3IgKmNvbmZpZyoKPiBhY2Nlc3NlcywKPiB0aGlzIHNob3VsZCBiZSBlYXN5LiAgQWxsIGNvbmZp ZyBhY2Nlc3NlcyBnbyB0aHJvdWdoIHdyYXBwZXJzCj4gKHBjaV9yZWFkX2NvbmZpZ193b3JkKCks IGV0YykgYW5kIHNldmVyYWwgaG9zdCBicmlkZ2UgZHJpdmVycyBoYXZlIHRvCj4gdXBkYXRlIGEg cmVnaXN0ZXIgd2l0aCBwYXJ0cyBvZiB0aGUgY29uZmlnIGFkZHJlc3MsIGUuZy4sCj4gYWR2a19w Y2llX3JkX2NvbmYoKSwgbXZlYnVfcGNpZV9od19yZF9jb25mKCkuCj4gCj4gSXQgc291bmRzIGxp a2UgeW91IGFsc28gbmVlZCB0byB1cGRhdGUgUENJRV9BRERSX1BBR0VfQ0ZHIGZvciBJL08KPiBw b3J0Cj4gYWNjZXNzZXMuICBJL08gcG9ydCBhY2Nlc3NlcyBkbyBnbyB0aHJvdWdoIGEgd3JhcHBl ciAoaW5iKCksIGV0YyksIHNvCj4gaXQgbWlnaHQgYmUgcG9zc2libGUgaW4gcHJpbmNpcGxlIHRv IGludGVyY2VwdCB0aGVzZSwgYWx0aG91Z2ggbXVjaAo+IG1vcmUgZGlmZmljdWx0IHRoYW4gY29u ZmlnIGFjY2Vzc2VzLCBiZWNhdXNlIHRoZSBjb25maWcgYWNjZXNzZXMgYXJlCj4gYWxyZWFkeSBz ZXQgdXAgd2l0aCBwZXItaG9zdCBicmlkZ2UgaG9va3MsIHdoaWxlIHRoZSBJL08gcG9ydAo+IGFj Y2Vzc29ycyBhcmUgbW9zdGx5IHBlci1hcmNoLgo+IAo+IEJ1dCBpZiB5b3UgaGF2ZSB0byB1cGRh dGUgUENJRV9BRERSX1BBR0VfQ0ZHIGZvciBtZW1vcnkgYWNjZXNzZXMsCj4gdGhhdCdzIHJlYWxs eSBhIHByb2JsZW0gYmVjYXVzZSBkcml2ZXJzIGFyZSBhbGxvd2VkIHRvIGVzc2VudGlhbGx5Cj4g cmVhZCBhIG1lbW9yeSBCQVIsIGNvbnZlcnQgdGhhdCBidXMgYWRkcmVzcyB0byBhIENQVSBwaHlz aWNhbCBtZW1vcnkKPiBhZGRyZXNzLCBpb3JlbWFwKCkgaXQsIHRoZW4gZGlyZWN0bHkgYWNjZXNz IHRoZSBQQ0llIG1lbW9yeSB3aXRoCj4gbG9hZHMKPiBhbmQgc3RvcmVzLgoKVW5mb3J0dW5hdGVs eSB0aGlzIGlzIHRoZSBjYXNlLiBBbGwgYWJvdmUgKGNvbmZpZywgSU8sIG1lbW9yeSkgbmVlZHMK UENJRV9BRERSX1BBR0VfQ0ZHIHVwZGF0ZS4KCj4gCj4gQmpvcm4KCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBs aXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5m cmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6 2018-03-06 3:57 ` Icenowy Zheng @ 2018-03-06 23:38 ` Bjorn Helgaas 2018-03-08 5:48 ` Icenowy Zheng 2018-03-08 12:10 ` Marc Gonzalez 0 siblings, 2 replies; 9+ messages in thread From: Bjorn Helgaas @ 2018-03-06 23:38 UTC (permalink / raw) To: Icenowy Zheng Cc: Joao Pinto, Maxime Ripard, linux-pci, Chen-Yu Tsai, linux-sunxi, Lorenzo Pieralisi, Jingoo Han, linux-arm-kernel, Marc Gonzalez WytjYyBNYXJjXQoKT24gVHVlLCBNYXIgMDYsIDIwMTggYXQgMTE6NTc6MDNBTSArMDgwMCwgSWNl bm93eSBaaGVuZyB3cm90ZToKPiDlnKggMjAxOC0wMy0wNeS4gOeahCAxNTo0NyAtMDYwMO+8jEJq b3JuIEhlbGdhYXPlhpnpgZPvvJoKPiA+IE9uIE1vbiwgTWFyIDA1LCAyMDE4IGF0IDEwOjUwOjU4 UE0gKzA4MDAsIEljZW5vd3kgWmhlbmcgd3JvdGU6Cj4gPiA+IEhpIGV2ZXJ5b25lLAo+ID4gPiAK PiA+ID4gSSdtIHRyeWluZyB0byBpbXBsZW1lbnQgYSBkcml2ZXIgZm9yIHRoZSBxdWlya3kgKERX KSBQQ0llIFJDIGluIHRoZQo+ID4gPiBBbGx3aW5uZXIgSDYgU29DLgo+ID4gPiAKPiA+ID4gVGhl IHF1aXJrIGlzIHRoYXQgb25seSB0aGUgImRiaSIgc3BhY2UgaXMgYWx3YXlzIG1hcHBlZCwgYnV0 IGF0IHRoZQo+ID4gPiBzYW1lIHRpbWUgb25seSA2NEtpQiBvZiBvdGhlciBzcGFjZXMgKGNvbmZp ZywgZG93bnN0cmVhbSBJTyBhbmQKPiA+ID4gbm9uLQo+ID4gPiBwcmVmZXRjaGFibGUgbWVtb3J5 KSBhcmUgYWNjZXNzaWJsZS4gVG8gYWNjZXNzIGEgY2VydGFpbiBhZGRyZXNzCj4gPiA+IHRoZQo+ ID4gPiBoaWdoIDE2LWJpdCBvZiB0aGUgYWRkcmVzcyAoYWxsIGJ1cyBhZGRyZXNzZXMgaW4gSDYg U29DIGFyZSAzMi1iaXQKPiA+ID4gZGVzcGl0ZSB0aGUgQ1BVIGlzIDY0LWJpdCkgbmVlZHMgdG8g YmUgd3JpdHRlbiBpbnRvIHRoZQo+ID4gPiBQQ0lFX0FERFJfUEFHRV9DRkcgcmVnaXN0ZXIgKGEg dmVuZG9yLWRlZmluZWQgcmVnaXN0ZXIgaW4gREJJCj4gPiA+IHNwYWNlKS4KPiA+ID4gU28gdGhl IGFjY2VzcyB0byB0aGVzZSBzcGFjZXMgY2Fubm90IGJlIHByb2Nlc3NlZCBjb3JyZWN0bHkgd2l0 aAo+ID4gPiBqdXN0Cj4gPiA+IHJlYWRsL3dyaXRlbCwgYXMgdGhlIGV4aXN0aW5nIGNvZGUgZG9l cy4KPiA+ID4gCj4gPiA+IElzIGl0IHBvc3NpYmxlIHRvIHdvcmthcm91bmQgdGhpcyBpbiB0aGUg UENJIHN1YnN5c3RlbSBvZiBMaW51eD8KPiA+ID4gCj4gPiA+IChJIGhhdmUgdGhvdWdodCBhIHdv cmthcm91bmQgdGhhdCBvbmx5IG1hcHMgdGhlIGN1cnJlbnQgYWNjZXNzaWJsZQo+ID4gPiA2NEtp QiB3aXRoIHRoZSBNTVUsIGFuZCB3aGVuIGFjY2Vzc2luZyB0aGUgbm9uLWFjY2Vzc2libGUgcGFy dCwKPiA+ID4gY2F0Y2gKPiA+ID4gdGhlIHBhZ2UgZmF1bHQgYW5kIHJlLXNldHVwIHRoZSBtYXAg dG8gdGhlIG5ldyA2NEtpQiBwYWdlLiBCdXQKPiA+ID4gc3VyZWx5Cj4gPiA+IGl0IHdpbGwga2ls bCB0aGUgcGVyZm9ybWFuY2UuKQo+ID4gCj4gPiBJZiB5b3Ugb25seSBuZWVkIHRvIHdyaXRlIHRv IFBDSUVfQUREUl9QQUdFX0NGRyBmb3IgKmNvbmZpZyoKPiA+IGFjY2Vzc2VzLAo+ID4gdGhpcyBz aG91bGQgYmUgZWFzeS4gIEFsbCBjb25maWcgYWNjZXNzZXMgZ28gdGhyb3VnaCB3cmFwcGVycwo+ ID4gKHBjaV9yZWFkX2NvbmZpZ193b3JkKCksIGV0YykgYW5kIHNldmVyYWwgaG9zdCBicmlkZ2Ug ZHJpdmVycyBoYXZlIHRvCj4gPiB1cGRhdGUgYSByZWdpc3RlciB3aXRoIHBhcnRzIG9mIHRoZSBj b25maWcgYWRkcmVzcywgZS5nLiwKPiA+IGFkdmtfcGNpZV9yZF9jb25mKCksIG12ZWJ1X3BjaWVf aHdfcmRfY29uZigpLgo+ID4gCj4gPiBJdCBzb3VuZHMgbGlrZSB5b3UgYWxzbyBuZWVkIHRvIHVw ZGF0ZSBQQ0lFX0FERFJfUEFHRV9DRkcgZm9yIEkvTwo+ID4gcG9ydAo+ID4gYWNjZXNzZXMuICBJ L08gcG9ydCBhY2Nlc3NlcyBkbyBnbyB0aHJvdWdoIGEgd3JhcHBlciAoaW5iKCksIGV0YyksIHNv Cj4gPiBpdCBtaWdodCBiZSBwb3NzaWJsZSBpbiBwcmluY2lwbGUgdG8gaW50ZXJjZXB0IHRoZXNl LCBhbHRob3VnaCBtdWNoCj4gPiBtb3JlIGRpZmZpY3VsdCB0aGFuIGNvbmZpZyBhY2Nlc3Nlcywg YmVjYXVzZSB0aGUgY29uZmlnIGFjY2Vzc2VzIGFyZQo+ID4gYWxyZWFkeSBzZXQgdXAgd2l0aCBw ZXItaG9zdCBicmlkZ2UgaG9va3MsIHdoaWxlIHRoZSBJL08gcG9ydAo+ID4gYWNjZXNzb3JzIGFy ZSBtb3N0bHkgcGVyLWFyY2guCj4gPiAKPiA+IEJ1dCBpZiB5b3UgaGF2ZSB0byB1cGRhdGUgUENJ RV9BRERSX1BBR0VfQ0ZHIGZvciBtZW1vcnkgYWNjZXNzZXMsCj4gPiB0aGF0J3MgcmVhbGx5IGEg cHJvYmxlbSBiZWNhdXNlIGRyaXZlcnMgYXJlIGFsbG93ZWQgdG8gZXNzZW50aWFsbHkKPiA+IHJl YWQgYSBtZW1vcnkgQkFSLCBjb252ZXJ0IHRoYXQgYnVzIGFkZHJlc3MgdG8gYSBDUFUgcGh5c2lj YWwgbWVtb3J5Cj4gPiBhZGRyZXNzLCBpb3JlbWFwKCkgaXQsIHRoZW4gZGlyZWN0bHkgYWNjZXNz IHRoZSBQQ0llIG1lbW9yeSB3aXRoCj4gPiBsb2Fkcwo+ID4gYW5kIHN0b3Jlcy4KPiAKPiBVbmZv cnR1bmF0ZWx5IHRoaXMgaXMgdGhlIGNhc2UuIEFsbCBhYm92ZSAoY29uZmlnLCBJTywgbWVtb3J5 KSBuZWVkcwo+IFBDSUVfQUREUl9QQUdFX0NGRyB1cGRhdGUuCgp0YW5nb19wY2llX3Byb2JlKCkg aGFzIGEgc2ltaWxhciBpc3N1ZS4gIFdlIGRvbid0IGhhdmUgYSBnb29kIHNvbHV0aW9uCnRoZXJl LCBzbyB3ZSBqdXN0IGxpdmUgd2l0aCB0aGUgZmFjdCB0aGF0IHRoZSBwbGF0Zm9ybSB3aWxsIGJl CnVucmVsaWFibGUuCgpCam9ybgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5l bEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4v bGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6 2018-03-06 23:38 ` Bjorn Helgaas @ 2018-03-08 5:48 ` Icenowy Zheng 2018-03-08 11:55 ` Marc Gonzalez 2018-03-08 12:10 ` Marc Gonzalez 1 sibling, 1 reply; 9+ messages in thread From: Icenowy Zheng @ 2018-03-08 5:48 UTC (permalink / raw) To: Bjorn Helgaas Cc: Joao Pinto, Maxime Ripard, linux-pci, linux-sunxi, Chen-Yu Tsai, Lorenzo Pieralisi, Jingoo Han, linux-arm-kernel, Marc Gonzalez 在 2018-03-06二的 17:38 -0600，Bjorn Helgaas写道： > [+cc Marc] > > On Tue, Mar 06, 2018 at 11:57:03AM +0800, Icenowy Zheng wrote: > > 在 2018-03-05一的 15:47 -0600，Bjorn Helgaas写道： > > > On Mon, Mar 05, 2018 at 10:50:58PM +0800, Icenowy Zheng wrote: > > > > Hi everyone, > > > > > > > > I'm trying to implement a driver for the quirky (DW) PCIe RC in > > > > the > > > > Allwinner H6 SoC. > > > > > > > > The quirk is that only the "dbi" space is always mapped, but at > > > > the > > > > same time only 64KiB of other spaces (config, downstream IO and > > > > non- > > > > prefetchable memory) are accessible. To access a certain > > > > address > > > > the > > > > high 16-bit of the address (all bus addresses in H6 SoC are 32- > > > > bit > > > > despite the CPU is 64-bit) needs to be written into the > > > > PCIE_ADDR_PAGE_CFG register (a vendor-defined register in DBI > > > > space). > > > > So the access to these spaces cannot be processed correctly > > > > with > > > > just > > > > readl/writel, as the existing code does. > > > > > > > > Is it possible to workaround this in the PCI subsystem of > > > > Linux? > > > > > > > > (I have thought a workaround that only maps the current > > > > accessible > > > > 64KiB with the MMU, and when accessing the non-accessible part, > > > > catch > > > > the page fault and re-setup the map to the new 64KiB page. But > > > > surely > > > > it will kill the performance.) > > > > > > If you only need to write to PCIE_ADDR_PAGE_CFG for *config* > > > accesses, > > > this should be easy. All config accesses go through wrappers > > > (pci_read_config_word(), etc) and several host bridge drivers > > > have to > > > update a register with parts of the config address, e.g., > > > advk_pcie_rd_conf(), mvebu_pcie_hw_rd_conf(). > > > > > > It sounds like you also need to update PCIE_ADDR_PAGE_CFG for I/O > > > port > > > accesses. I/O port accesses do go through a wrapper (inb(), > > > etc), so > > > it might be possible in principle to intercept these, although > > > much > > > more difficult than config accesses, because the config accesses > > > are > > > already set up with per-host bridge hooks, while the I/O port > > > accessors are mostly per-arch. > > > > > > But if you have to update PCIE_ADDR_PAGE_CFG for memory accesses, > > > that's really a problem because drivers are allowed to > > > essentially > > > read a memory BAR, convert that bus address to a CPU physical > > > memory > > > address, ioremap() it, then directly access the PCIe memory with > > > loads > > > and stores. > > > > Unfortunately this is the case. All above (config, IO, memory) > > needs > > PCIE_ADDR_PAGE_CFG update. > > tango_pcie_probe() has a similar issue. We don't have a good > solution > there, so we just live with the fact that the platform will be > unreliable. It's still less quirky than Allwinner H6 PCIe. It's only a config/MMIO mux on tango; however on H6 PCIe both config space and MMIO space are splitted to many pages. So on H6 if no solution is worked out, it will not be unreliable -- it will be unusable instead. > > Bjorn ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6 2018-03-08 5:48 ` Icenowy Zheng @ 2018-03-08 11:55 ` Marc Gonzalez 2018-03-08 13:18 ` Icenowy Zheng 0 siblings, 1 reply; 9+ messages in thread From: Marc Gonzalez @ 2018-03-08 11:55 UTC (permalink / raw) To: Icenowy Zheng, Bjorn Helgaas Cc: Joao Pinto, Marc Gonzalez, Maxime Ripard, linux-pci, Chen-Yu Tsai, linux-sunxi, Lorenzo Pieralisi, Jingoo Han, Linux ARM On 08/03/2018 06:48, Icenowy Zheng wrote: > I'm trying to implement a driver for the quirky (DW) PCIe RC in the > Allwinner H6 SoC. > > The quirk is that only the "dbi" space is always mapped, but at the > same time only 64KiB of other spaces (config, downstream IO and non- > prefetchable memory) are accessible. To access a certain address the > high 16-bit of the address (all bus addresses in H6 SoC are 32- bit > despite the CPU is 64-bit) needs to be written into the > PCIE_ADDR_PAGE_CFG register (a vendor-defined register in DBI > space). So the access to these spaces cannot be processed correctly > with just readl/writel, as the existing code does. > > Is it possible to workaround this in the PCI subsystem of Linux? I didn't think anyone would come up with something more broken than tango's PCIe host bridge... It's hard to understand what's going on inside the minds of these HW devs. I mean, if the steps required are WRITE MAGIC CONFIG REG READ/WRITE ADDRESS REG then the whole operation is clearly not atomic, and bad things happen when 2+ operations race. Do they think in terms of single core systems with non-multitasking OS? Probably not. Maybe they think it is not a problem to wrap the operation using a mutex? I'll confess I have no idea how bad that is for performance. However, that is not an option in Linux, because mem space accesses are just plain mmio accesses, and it's not possible to rewrite the drivers, even as an out-of-tree patch. I suppose it could be possible to make the first write "magic" in the sense that it could "lock" the bus until the second access is performed? Sort of like an implicit HW mutex. Actually, tango has explicit HW mutexes that work along these lines. > (I have thought a workaround that only maps the current accessible > 64KiB with the MMU, and when accessing the non-accessible part, > catch the page fault and re-setup the map to the new 64KiB page. But > surely it will kill the performance.) The implementation might be non-trivial, as well. > [tango is] still less quirky than Allwinner H6 PCIe. It's only a > config/MMIO mux on tango; however on H6 PCIe both config space and > MMIO space are splitted to many pages. So on H6 if no solution is > worked out, it will not be unreliable -- it will be unusable > instead. I have only limited experience, but it seems that many useful PCIe adapters require only very little mem address space. For example, the USB3 PCIe adapter I tested my implementation with requires only 8 KB. 01:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI]) Flags: fast devsel Memory at 50400000 (64-bit, non-prefetchable) [size=8K] Capabilities: [50] Power Management version 3 Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ Capabilities: [90] MSI-X: Enable- Count=8 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [150] Latency Tolerance Reporting Same thing for the following WiFi adapter. 01:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb) Subsystem: Intel Corporation Dual Band Wireless-AC 7260 Flags: fast devsel, IRQ 22 Memory at 50400000 (64-bit, non-prefetchable) [disabled] [size=8K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 48-51-b7-ff-ff-84-69-26 Capabilities: [14c] Latency Tolerance Reporting Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1 Len=014 <?> Maybe you can decide that you will support only 64 KB? Regards. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6 2018-03-08 11:55 ` Marc Gonzalez @ 2018-03-08 13:18 ` Icenowy Zheng 2018-03-08 14:11 ` Icenowy Zheng 0 siblings, 1 reply; 9+ messages in thread From: Icenowy Zheng @ 2018-03-08 13:18 UTC (permalink / raw) To: Marc Gonzalez, Bjorn Helgaas Cc: Joao Pinto, Marc Gonzalez, Maxime Ripard, linux-pci, Chen-Yu Tsai, linux-sunxi, Lorenzo Pieralisi, Jingoo Han, Linux ARM 5ZyoIDIwMTgtMDMtMDjlm5vnmoQgMTI6NTUgKzAxMDDvvIxNYXJjIEdvbnphbGV65YaZ6YGT77ya Cj4gT24gMDgvMDMvMjAxOCAwNjo0OCwgSWNlbm93eSBaaGVuZyB3cm90ZToKPiAKPiA+IEknbSB0 cnlpbmcgdG8gaW1wbGVtZW50IGEgZHJpdmVyIGZvciB0aGUgcXVpcmt5IChEVykgUENJZSBSQyBp biB0aGUKPiA+IEFsbHdpbm5lciBINiBTb0MuCj4gPiAKPiA+IFRoZSBxdWlyayBpcyB0aGF0IG9u bHkgdGhlICJkYmkiIHNwYWNlIGlzIGFsd2F5cyBtYXBwZWQsIGJ1dCBhdAo+ID4gdGhlIAo+ID4g c2FtZSB0aW1lIG9ubHkgNjRLaUIgb2Ygb3RoZXIgc3BhY2VzIChjb25maWcsIGRvd25zdHJlYW0g SU8gYW5kCj4gPiBub24tIAo+ID4gcHJlZmV0Y2hhYmxlIG1lbW9yeSkgYXJlIGFjY2Vzc2libGUu IFRvIGFjY2VzcyBhIGNlcnRhaW4gYWRkcmVzcwo+ID4gdGhlIAo+ID4gaGlnaCAxNi1iaXQgb2Yg dGhlIGFkZHJlc3MgKGFsbCBidXMgYWRkcmVzc2VzIGluIEg2IFNvQyBhcmUgMzItCj4gPiBiaXQg Cj4gPiBkZXNwaXRlIHRoZSBDUFUgaXMgNjQtYml0KSBuZWVkcyB0byBiZSB3cml0dGVuIGludG8g dGhlIAo+ID4gUENJRV9BRERSX1BBR0VfQ0ZHIHJlZ2lzdGVyIChhIHZlbmRvci1kZWZpbmVkIHJl Z2lzdGVyIGluIERCSSAKPiA+IHNwYWNlKS4gU28gdGhlIGFjY2VzcyB0byB0aGVzZSBzcGFjZXMg Y2Fubm90IGJlIHByb2Nlc3NlZAo+ID4gY29ycmVjdGx5IAo+ID4gd2l0aCBqdXN0IHJlYWRsL3dy aXRlbCwgYXMgdGhlIGV4aXN0aW5nIGNvZGUgZG9lcy4KPiA+IAo+ID4gSXMgaXQgcG9zc2libGUg dG8gd29ya2Fyb3VuZCB0aGlzIGluIHRoZSBQQ0kgc3Vic3lzdGVtIG9mIExpbnV4Pwo+IAo+IEkg ZGlkbid0IHRoaW5rIGFueW9uZSB3b3VsZCBjb21lIHVwIHdpdGggc29tZXRoaW5nIG1vcmUgYnJv a2VuCj4gdGhhbiB0YW5nbydzIFBDSWUgaG9zdCBicmlkZ2UuLi4KPiAKPiBJdCdzIGhhcmQgdG8g dW5kZXJzdGFuZCB3aGF0J3MgZ29pbmcgb24gaW5zaWRlIHRoZSBtaW5kcyBvZiB0aGVzZQo+IEhX IGRldnMuIEkgbWVhbiwgaWYgdGhlIHN0ZXBzIHJlcXVpcmVkIGFyZQo+IAo+IAlXUklURSBNQUdJ QyBDT05GSUcgUkVHCj4gCVJFQUQvV1JJVEUgQUREUkVTUyBSRUcKPiAKPiB0aGVuIHRoZSB3aG9s ZSBvcGVyYXRpb24gaXMgY2xlYXJseSBub3QgYXRvbWljLCBhbmQgYmFkIHRoaW5ncyBoYXBwZW4K PiB3aGVuIDIrIG9wZXJhdGlvbnMgcmFjZS4KPiAKPiBEbyB0aGV5IHRoaW5rIGluIHRlcm1zIG9m IHNpbmdsZSBjb3JlIHN5c3RlbXMgd2l0aCBub24tbXVsdGl0YXNraW5nCj4gT1M/Cj4gUHJvYmFi bHkgbm90Lgo+IAo+IE1heWJlIHRoZXkgdGhpbmsgaXQgaXMgbm90IGEgcHJvYmxlbSB0byB3cmFw IHRoZSBvcGVyYXRpb24gdXNpbmcgYQo+IG11dGV4PyBJJ2xsIGNvbmZlc3MgSSBoYXZlIG5vIGlk ZWEgaG93IGJhZCB0aGF0IGlzIGZvciBwZXJmb3JtYW5jZS4KPiBIb3dldmVyLCB0aGF0IGlzIG5v dCBhbiBvcHRpb24gaW4gTGludXgsIGJlY2F1c2UgbWVtIHNwYWNlIGFjY2Vzc2VzCj4gYXJlIGp1 c3QgcGxhaW4gbW1pbyBhY2Nlc3NlcywgYW5kIGl0J3Mgbm90IHBvc3NpYmxlIHRvIHJld3JpdGUg dGhlCj4gZHJpdmVycywgZXZlbiBhcyBhbiBvdXQtb2YtdHJlZSBwYXRjaC4KPiAKPiBJIHN1cHBv c2UgaXQgY291bGQgYmUgcG9zc2libGUgdG8gbWFrZSB0aGUgZmlyc3Qgd3JpdGUgIm1hZ2ljIiBp biB0aGUKPiBzZW5zZSB0aGF0IGl0IGNvdWxkICJsb2NrIiB0aGUgYnVzIHVudGlsIHRoZSBzZWNv bmQgYWNjZXNzIGlzCj4gcGVyZm9ybWVkPwo+IFNvcnQgb2YgbGlrZSBhbiBpbXBsaWNpdCBIVyBt dXRleC4gQWN0dWFsbHksIHRhbmdvIGhhcyBleHBsaWNpdCBIVwo+IG11dGV4ZXMgdGhhdCB3b3Jr IGFsb25nIHRoZXNlIGxpbmVzLgoKVW5mb3J0dW5hdGVseSBzdW41MGktaDYgZG9lc24ndCBoYXZl IGl0LgoKPiAKPiA+IChJIGhhdmUgdGhvdWdodCBhIHdvcmthcm91bmQgdGhhdCBvbmx5IG1hcHMg dGhlIGN1cnJlbnQgYWNjZXNzaWJsZSAKPiA+IDY0S2lCIHdpdGggdGhlIE1NVSwgYW5kIHdoZW4g YWNjZXNzaW5nIHRoZSBub24tYWNjZXNzaWJsZSBwYXJ0LCAKPiA+IGNhdGNoIHRoZSBwYWdlIGZh dWx0IGFuZCByZS1zZXR1cCB0aGUgbWFwIHRvIHRoZSBuZXcgNjRLaUIgcGFnZS4KPiA+IEJ1dCAK PiA+IHN1cmVseSBpdCB3aWxsIGtpbGwgdGhlIHBlcmZvcm1hbmNlLikKPiAKPiBUaGUgaW1wbGVt ZW50YXRpb24gbWlnaHQgYmUgbm9uLXRyaXZpYWwsIGFzIHdlbGwuCgpJdCBtaWdodCBiZSBwb3Nz aWJsZSBmb3Igc2V0IHVwIGEgaHlwZXJ2aXNvciB0byBkbyBpdC4gKEFsdGhvdWdoIGl0J3MKc3Vy ZWx5IGFuIGFidXNlIG9mIHRoZSBIWVAvRUwyIG1vZGUpCgo+IAo+ID4gW3RhbmdvIGlzXSBzdGls bCBsZXNzIHF1aXJreSB0aGFuIEFsbHdpbm5lciBINiBQQ0llLiBJdCdzIG9ubHkgYQo+ID4gY29u ZmlnL01NSU8gbXV4IG9uIHRhbmdvOyBob3dldmVyIG9uIEg2IFBDSWUgYm90aCBjb25maWcgc3Bh Y2UgYW5kCj4gPiBNTUlPIHNwYWNlIGFyZSBzcGxpdHRlZCB0byBtYW55IHBhZ2VzLiBTbyBvbiBI NiBpZiBubyBzb2x1dGlvbiBpcwo+ID4gd29ya2VkIG91dCwgaXQgd2lsbCBub3QgYmUgdW5yZWxp YWJsZSAtLSBpdCB3aWxsIGJlIHVudXNhYmxlCj4gPiBpbnN0ZWFkLgo+IAo+IEkgaGF2ZSBvbmx5 IGxpbWl0ZWQgZXhwZXJpZW5jZSwgYnV0IGl0IHNlZW1zIHRoYXQgbWFueSB1c2VmdWwgUENJZQo+ IGFkYXB0ZXJzIHJlcXVpcmUgb25seSB2ZXJ5IGxpdHRsZSBtZW0gYWRkcmVzcyBzcGFjZS4KCkJ1 dCB0aGVyZSdzIGFsc28gbWFueSB0aGF0IHJlcXVpcmUgYmlnZ2VyIG1lbW9yeSBhZGRyZXNzIHNw YWNlIHRoYW4KNjRLLgoKZS5nLiB0aGUgQXRoZXJvcyBBUjk0NjIgODAyLjExbiBhZGFwdGVyIG5l ZWRzIDUxMksgbm9uLXByZWZldGNoYWJsZQptZW1vcnkuCgo+IAo+IEZvciBleGFtcGxlLCB0aGUg VVNCMyBQQ0llIGFkYXB0ZXIgSSB0ZXN0ZWQgbXkgaW1wbGVtZW50YXRpb24gd2l0aAo+IHJlcXVp cmVzIG9ubHkgOCBLQi4KPiAKPiAwMTowMC4wIFVTQiBjb250cm9sbGVyOiBSZW5lc2FzIFRlY2hu b2xvZ3kgQ29ycC4gdVBENzIwMjAxIFVTQiAzLjAKPiBIb3N0IENvbnRyb2xsZXIgKHJldiAwMykg KHByb2ctaWYgMzAgW1hIQ0ldKQo+ICAgICAgICAgRmxhZ3M6IGZhc3QgZGV2c2VsCj4gICAgICAg ICBNZW1vcnkgYXQgNTA0MDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9OEtd Cj4gICAgICAgICBDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMK PiAgICAgICAgIENhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS84IE1hc2th YmxlLSA2NGJpdCsKPiAgICAgICAgIENhcGFiaWxpdGllczogWzkwXSBNU0ktWDogRW5hYmxlLSBD b3VudD04IE1hc2tlZC0KPiAgICAgICAgIENhcGFiaWxpdGllczogW2EwXSBFeHByZXNzIEVuZHBv aW50LCBNU0kgMDAKPiAgICAgICAgIENhcGFiaWxpdGllczogWzEwMF0gQWR2YW5jZWQgRXJyb3Ig UmVwb3J0aW5nCj4gICAgICAgICBDYXBhYmlsaXRpZXM6IFsxNTBdIExhdGVuY3kgVG9sZXJhbmNl IFJlcG9ydGluZwo+IAo+IAo+IFNhbWUgdGhpbmcgZm9yIHRoZSBmb2xsb3dpbmcgV2lGaSBhZGFw dGVyLgo+IAo+IDAxOjAwLjAgTmV0d29yayBjb250cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlvbiBX aXJlbGVzcyA3MjYwIChyZXYgYmIpCj4gICAgICAgICBTdWJzeXN0ZW06IEludGVsIENvcnBvcmF0 aW9uIER1YWwgQmFuZCBXaXJlbGVzcy1BQyA3MjYwCj4gICAgICAgICBGbGFnczogZmFzdCBkZXZz ZWwsIElSUSAyMgo+ICAgICAgICAgTWVtb3J5IGF0IDUwNDAwMDAwICg2NC1iaXQsIG5vbi1wcmVm ZXRjaGFibGUpIFtkaXNhYmxlZF0KPiBbc2l6ZT04S10KPiAgICAgICAgIENhcGFiaWxpdGllczog W2M4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMwo+ICAgICAgICAgQ2FwYWJpbGl0aWVzOiBb ZDBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kwo+ICAgICAgICAgQ2Fw YWJpbGl0aWVzOiBbNDBdIEV4cHJlc3MgRW5kcG9pbnQsIE1TSSAwMAo+ICAgICAgICAgQ2FwYWJp bGl0aWVzOiBbMTAwXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRpbmcKPiAgICAgICAgIENhcGFiaWxp dGllczogWzE0MF0gRGV2aWNlIFNlcmlhbCBOdW1iZXIgNDgtNTEtYjctZmYtZmYtODQtCj4gNjkt MjYKPiAgICAgICAgIENhcGFiaWxpdGllczogWzE0Y10gTGF0ZW5jeSBUb2xlcmFuY2UgUmVwb3J0 aW5nCj4gICAgICAgICBDYXBhYmlsaXRpZXM6IFsxNTRdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1h dGlvbjogSUQ9Y2FmZQo+IFJldj0xIExlbj0wMTQgPD8+Cj4gCj4gCj4gTWF5YmUgeW91IGNhbiBk ZWNpZGUgdGhhdCB5b3Ugd2lsbCBzdXBwb3J0IG9ubHkgNjQgS0I/CgpEZXNwaXRlIHN1cHBvcnQg b2Ygc29tZSBkZXZpY2VzIHdpbGwgZmFpbCwgSSBzdGlsbCB0aGluayB0aGlzIGlzIGEgZ29vZApp ZGVhLiBJdCBtYWtlcyB0aGUgcHJvYmxlbSBtdWNoIHNpbXBsZXIgLS0gaXQgd2lsbCBiZWNvbWUg YSBtdXggYW1vbmcKY29uZmlnIHNwYWNlLCBJTyBzcGFjZSBhbmQgNjRLQiBub24tcHJlZmV0Y2hh YmxlIG1lbW9yeS4KCklmIGEgUENJZS1maXhpbmcgaHlwZXJ2aXNvciBpcyBkb25lIGl0IGNhbiBz aW1wbHkgc2tpcCB0aGUga2VybmVsIGdsdWUsCmJ1dCBsZXQgdGhlIGtlcm5lbCBjb25maWd1cmUg aXQgd2l0aCBFQ0FNIG1vZGUuCgo+IAo+IFJlZ2FyZHMuCj4gCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlz dApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJh ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6 2018-03-08 13:18 ` Icenowy Zheng @ 2018-03-08 14:11 ` Icenowy Zheng 0 siblings, 0 replies; 9+ messages in thread From: Icenowy Zheng @ 2018-03-08 14:11 UTC (permalink / raw) To: Marc Gonzalez, Bjorn Helgaas Cc: Joao Pinto, Marc Gonzalez, Maxime Ripard, linux-pci, Chen-Yu Tsai, linux-sunxi, Lorenzo Pieralisi, Jingoo Han, Linux ARM 在 2018-03-08四的 21:18 +0800，Icenowy Zheng写道： > 在 2018-03-08四的 12:55 +0100，Marc Gonzalez写道： > > On 08/03/2018 06:48, Icenowy Zheng wrote: > > > > > I'm trying to implement a driver for the quirky (DW) PCIe RC in > > > the > > > Allwinner H6 SoC. > > > > > > The quirk is that only the "dbi" space is always mapped, but at > > > the > > > same time only 64KiB of other spaces (config, downstream IO and > > > non- > > > prefetchable memory) are accessible. To access a certain address > > > the > > > high 16-bit of the address (all bus addresses in H6 SoC are 32- > > > bit > > > despite the CPU is 64-bit) needs to be written into the > > > PCIE_ADDR_PAGE_CFG register (a vendor-defined register in DBI > > > space). So the access to these spaces cannot be processed > > > correctly > > > with just readl/writel, as the existing code does. > > > > > > Is it possible to workaround this in the PCI subsystem of Linux? > > > > I didn't think anyone would come up with something more broken > > than tango's PCIe host bridge... > > > > It's hard to understand what's going on inside the minds of these > > HW devs. I mean, if the steps required are > > > > WRITE MAGIC CONFIG REG > > READ/WRITE ADDRESS REG > > > > then the whole operation is clearly not atomic, and bad things > > happen > > when 2+ operations race. > > > > Do they think in terms of single core systems with non-multitasking > > OS? > > Probably not. > > > > Maybe they think it is not a problem to wrap the operation using a > > mutex? I'll confess I have no idea how bad that is for performance. > > However, that is not an option in Linux, because mem space accesses > > are just plain mmio accesses, and it's not possible to rewrite the > > drivers, even as an out-of-tree patch. > > > > I suppose it could be possible to make the first write "magic" in > > the > > sense that it could "lock" the bus until the second access is > > performed? > > Sort of like an implicit HW mutex. Actually, tango has explicit HW > > mutexes that work along these lines. > > Unfortunately sun50i-h6 doesn't have it. > > > > > > (I have thought a workaround that only maps the current > > > accessible > > > 64KiB with the MMU, and when accessing the non-accessible part, > > > catch the page fault and re-setup the map to the new 64KiB page. > > > But > > > surely it will kill the performance.) > > > > The implementation might be non-trivial, as well. > > It might be possible for set up a hypervisor to do it. (Although it's > surely an abuse of the HYP/EL2 mode) > > > > > > [tango is] still less quirky than Allwinner H6 PCIe. It's only a > > > config/MMIO mux on tango; however on H6 PCIe both config space > > > and > > > MMIO space are splitted to many pages. So on H6 if no solution is > > > worked out, it will not be unreliable -- it will be unusable > > > instead. > > > > I have only limited experience, but it seems that many useful PCIe > > adapters require only very little mem address space. > > But there's also many that require bigger memory address space than > 64K. > > e.g. the Atheros AR9462 802.11n adapter needs 512K non-prefetchable > memory. > > > > > For example, the USB3 PCIe adapter I tested my implementation with > > requires only 8 KB. > > > > 01:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 > > Host Controller (rev 03) (prog-if 30 [XHCI]) > > Flags: fast devsel > > Memory at 50400000 (64-bit, non-prefetchable) [size=8K] > > Capabilities: [50] Power Management version 3 > > Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ > > Capabilities: [90] MSI-X: Enable- Count=8 Masked- > > Capabilities: [a0] Express Endpoint, MSI 00 > > Capabilities: [100] Advanced Error Reporting > > Capabilities: [150] Latency Tolerance Reporting > > > > > > Same thing for the following WiFi adapter. > > > > 01:00.0 Network controller: Intel Corporation Wireless 7260 (rev > > bb) > > Subsystem: Intel Corporation Dual Band Wireless-AC 7260 > > Flags: fast devsel, IRQ 22 > > Memory at 50400000 (64-bit, non-prefetchable) [disabled] > > [size=8K] > > Capabilities: [c8] Power Management version 3 > > Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ > > Capabilities: [40] Express Endpoint, MSI 00 > > Capabilities: [100] Advanced Error Reporting > > Capabilities: [140] Device Serial Number 48-51-b7-ff-ff-84- > > 69-26 > > Capabilities: [14c] Latency Tolerance Reporting > > Capabilities: [154] Vendor Specific Information: ID=cafe > > Rev=1 Len=014 <?> > > > > > > Maybe you can decide that you will support only 64 KB? > > Despite support of some devices will fail, I still think this is a > good > idea. It makes the problem much simpler -- it will become a mux among > config space, IO space and 64KB non-prefetchable memory. However the DW PCIe RC core claims 1MiB non-prefetchable memory... > > If a PCIe-fixing hypervisor is done it can simply skip the kernel > glue, > but let the kernel configure it with ECAM mode. > > > > > Regards. > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6 2018-03-06 23:38 ` Bjorn Helgaas 2018-03-08 5:48 ` Icenowy Zheng @ 2018-03-08 12:10 ` Marc Gonzalez 1 sibling, 0 replies; 9+ messages in thread From: Marc Gonzalez @ 2018-03-08 12:10 UTC (permalink / raw) To: Bjorn Helgaas, Icenowy Zheng Cc: Lorenzo Pieralisi, Maxime Ripard, Jingoo Han, Chen-Yu Tsai, Joao Pinto, linux-pci, Linux ARM, Marc Gonzalez On 07/03/2018 00:38, Bjorn Helgaas wrote: > [+cc Marc] Thanks for the CC. Please update your address books, by changing marc_gonzalez@sigmadesigns.com to marc.w.gonzalez@free.fr if you wish to contact me, as Sigma Designs has started the the liquidation process. In related news, I have received the following notice. > Unfortunately, the PCI-SIG has expired Sigma Designs, Inc's > membership. The annual membership fee of $4,000 US was due upon your > renewal date of February 20, 2018. Several reminders were sent to > enable Sigma Designs, Inc to renew their membership, however, the > PCI-SIG did not receive your company's renewal payment. Please > understand that the use of your vendor ID number is conditioned upon > your maintaining an active membership in the PCI-SIG. > > The PCI-SIG does reserve the right to re-assign or revoke any vendor > ID previously assigned to former members. Since we have not received > your renewal payment, the PCI-SIG must request that you cease and > desist all future use of your vendor ID number on devices > manufactured by your company. So Long, and Thanks for All the Fish :-) Regards. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-03-08 14:11 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-03-05 14:50 Question about a quirky (DesignWare) PCIe RC in Allwinner H6 Icenowy Zheng 2018-03-05 21:47 ` Bjorn Helgaas 2018-03-06 3:57 ` Icenowy Zheng 2018-03-06 23:38 ` Bjorn Helgaas 2018-03-08 5:48 ` Icenowy Zheng 2018-03-08 11:55 ` Marc Gonzalez 2018-03-08 13:18 ` Icenowy Zheng 2018-03-08 14:11 ` Icenowy Zheng 2018-03-08 12:10 ` Marc Gonzalez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).