pci: mvebu: fix off-by-one in the computed size of the mbus windows

mvebu_pcie_handle_membase_change() and
mvebu_pcie_handle_iobase_change() do not correctly compute the window
size. PCI uses an inclusive start/end address pair, which requires a
+1 when converting to size.

This only worked because a bug in the mbus driver allowed it to
silently accept and round up bogus sizes.

Fix this by adding one to the computed size.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Reviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
bus: mvebu-mbus: Avoid setting an undefined window size

The mbus hardware requires a power of two size, and size aligned base.
Currently, if a non-power of two is passed in to the low level routines
they configure the register in a way that results in undefined behaviour.

Call WARN and return EINVAL instead.

Also, update the debugfs routines to show a message if there is an
invalid register setting.

All together this makes the recent problems with silent failure
of PCI very obvious, noisy and debuggable.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
bus: mvebu-mbus: allow several windows with the same target/attribute

Having multiple windows with the same target and attribute is actually
legal, and can be useful for PCIe windows, when PCIe BARs have a size
that isn't a power of two, and we therefore need to create several
MBus windows to cover the PCIe BAR for a given PCIe interface.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
pci: pci-mvebu: split PCIe BARs into multiple MBus windows when needed

MBus windows are used on Marvell platforms to map certain peripherals
in the physical address space. In the PCIe context, MBus windows are
needed to map PCIe I/O and memory regions in the physical address.

However, those MBus windows can only have power of two sizes, while
PCIe BAR do not necessarily guarantee this. For this reason, the
current pci-mvebu breaks on platforms where PCIe devices have BARs
that don't sum up to a power of two size at the emulated bridge level.

This commit fixes this by allowing the pci-mvebu driver to create
multiple contiguous MBus windows (each having a power of two size) to
cover a given PCIe BAR.

To achieve this, two functions are added: mvebu_pcie_add_windows() and
mvebu_pcie_del_windows() to respectively add and remove all the MBus
windows that are needed to map the provided PCIe region base and
size. The emulated PCI bridge code now calls those functions, instead
of directly calling the mvebu-mbus driver functions.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
pci: pci-mvebu: wait for a device to appear to fix clock issues

With the introduction of the mvebu-soc-id mechanism in
arch/arm/mach-mvebu/, the PCIe clocks can be gated during early boot,
and then re-enabled later when the pci-mvebu driver gets
called. However, after the clock has been enabled, it takes some time
for the PCIe device to become visible: this is causing problems on
some platforms where PCIe devices may not be detected at boot time due
to this.

To fix this, this commit introduces a simple loop that waits for a
valid device to actually show up on each PCIe interface for which the
link is up.

It fixes a problem reported both by Gregory Clement and Neil
Greatorex, which were seeing all PCIe devices detected when
earlyprintk was enabled, but one of the device was missing when
earlyprintk was disabled. This was due to the fact that earlyprintk
was slowing down the boot sufficiently to make the problem invisible.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Neil Greatorex <neil@fatboyfat.co.uk>
Reported-by: Gregory CLEMENT <gregory.clement@free-electrons.com>