On Monday, July 18, 2016 11:44:24 AM CEST Thomas Petazzoni wrote:
On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote:
I would assume that the PCIe port should work out of the box with the driver
Unfortunately, no. The PCIe on Orion5x requires a workaround for
reading/writing the PCI configuration space. Instead of doing MMIO
accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a
MBus window, which provides a memory-mapped view of the PCI
Definitely not impossible to implement, but the driver doesn't work
We also don't seem to need any MBUS window setup for the I/O and
memory spaces, which greatly simplifies the driver compared to the
pci-mvebu one, it would be a fairly straightforward implementation
based on pci-host-generic.c (which unfortunately just got way
more complicated and might need to go on a diet).
MBus windows are needed. See:
Ok, I was just looking at the wrong file, as they are set up from
common.c, not pci.c.
Note that we already have some Orion5x converted to DT, and that use
PCI: board-rd88f5182.c is an example. So we could very well take Jamie
patches as-is, and move later to a DT-representation for PCI/PCIe.
Ah, I thought all the DT users were moved to mach-mvebu. I agree
this new patch isn't introducing anything we don't already have then,
so we can just take it, but the conversion will not be nice when
we do that.
I was also hoping that we could get to the point where pci_common_init()
is only used for legacy machines without DT and without multiplatform,
it seems I missed a couple of users here.