Question about a quirky (DesignWare) PCIe RC in Allwinner H6

Question about a quirky (DesignWare) PCIe RC in Allwinner H6

[Icenowy Zheng]

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

Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6

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

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6

[Icenowy Zheng]

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

Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6

[Bjorn Helgaas]

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=

Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6

[Icenowy Zheng]

在 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

Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6

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

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

Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6

[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

Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6

[Icenowy Zheng]

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

Re: Question about a quirky (DesignWare) PCIe RC in Allwinner H6

[Icenowy Zheng]

在 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