On Mon, Jun 20, 2016 at 02:56:58AM +0200, Niklas Cassel wrote: > > On 06/13/2016 03:33 PM, Bjorn Helgaas wrote: > > On Mon, Jun 13, 2016 at 03:12:13PM +0200, Niklas Cassel wrote: > >> On 06/10/2016 12:41 AM, Bjorn Helgaas wrote: > >>> On Mon, May 09, 2016 at 01:49:03PM +0200, Niklas Cassel wrote: > >>>> From: Niklas Cassel <niklas.cassel@xxxxxxxx> > >>>> > >>>> The Axis ARTPEC-6 SoC integrates a PCIe controller from Synopsys. > >>>> This commit adds a new driver that provides the small glue > >>>> needed to use the existing Designware driver to make it work on > >>>> the Axis ARTPEC-6 SoC. > >>>> > >>>> Signed-off-by: Niklas Cassel <niklas.cassel@xxxxxxxx> > >>> Hi Niklas, > >>> > >>> I'll review this soon. In the meantime, can you send /proc/iomem and > >>> /proc/ioport contents? I'm looking to avoid problems like this: > >>> http://lkml.kernel.org/r/20160606230537.20936.2892.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > >>> > >>> It looks like this is based on DesignWare, so it probably has the > >>> problem, and will probably be fixed by these: > >>> > >>> http://lkml.kernel.org/r/20160606230452.20936.28937.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > >>> http://lkml.kernel.org/r/20160606230501.20936.71818.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > >>> http://lkml.kernel.org/r/20160606230508.20936.81845.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > >>> > >>> If you wanted to apply those and then send /proc/iomem and > >>> /proc/ioports, that would be even better. > >>> > >>> Bjorn > >>> > >> Output with your patches applied: > > Great, thanks, Niklas! Comments below: > > > >> [ 2.107320] PCI host bridge /pcie@f8050000 ranges: > >> [ 2.112138] No bus range found for /pcie@f8050000, using [bus 00-ff] > > Your DT *should* provide a bus number range. There is no way for the > > PCI core to correctly determine the range. > Ok, I will update the DT example to include bus-range. > > > > >> [ 2.118684] IO 0xc0010000..0xc001ffff -> 0x00010000 > >> [ 2.123835] MEM 0xc0020000..0xdfffffff -> 0xc0020000 > >> [ 2.245559] artpec6-pcie f8050000.pcie: link up > >> [ 2.250228] artpec6-pcie f8050000.pcie: PCI host bridge to bus 0000:00 > >> [ 2.256773] pci_bus 0000:00: root bus resource [bus 00-ff] > >> [ 2.262273] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0x10000-0x1ffff]) > > This looks questionable. This says we're using I/O ports > > 0x10000-0x1ffff on the PCI bus. That's legal, but unusual. > > > > The conventional PCI spec allowed the upper 16 bits of I/O BARs > > to be hard-wired to zero "for devices intended for 16-bit I/O > > systems, such as PC compatibles." > > > > I don't know whether a PCIe device with an I/O BAR with the > > upper bits hard-wired to zero exists. The conservative approach > > would be to use ports 0x0000-0xffff on PCI. > Thank you for the detailed explanation. > We simply chose a value during testing, > there wasn't any deeper thought behind it. > Since other DesignWare drivers seem to use 0x0, lets stick to that. > > I'm currently on parental leave, but I'm back on work next week. Congratulations! > I will try the new settings and send out a patch that updates the DT example. > > Hopefully there's no hurry, since both changes are in the DT example. Nope, no hurry. I'll be on vacation for a while myself. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
