arm: mach-mvebu: convert to use mvebu-mbus driver

The changes needed to migrate the mach-mvebu (Armada 370 and Armada
XP) to the mvebu-mbus driver are fairly minimal, since not many
devices currently supported on those SoCs use address decoding
windows. The only one being the BootROM window, used to bring up
secondary CPUs.

However, this BootROM window needed for SMP brings an important
requirement: the mvebu-mbus driver must be initialized at the
->early_init() time, otherwise the BootROM window cannot be setup
early enough to be ready before the secondary CPUs are started.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-kirkwood: convert to use mvebu-mbus driver

This commit migrates the mach-kirkwood platforms to use the mvebu-mbus
driver and therefore removes the Kirkwood-specific addr-map code.

In order to do this, we have to introduce a separate
kirkwood_dt_init_early() function. It continues to be quite similar to
kirkwood_init_early(), except that it does a DT-based initialization
of the mvebu-mbus driver. On the other hand, the kirkwood_init_early()
function does a legacy initialization of the mvebu-mbus driver (which
will be removed once all boards have been migrated to the Device
Tree).

The address decoding windows are now registered in the
kirkwood_setup_wins() function. It is worth noting that the four PCIe
address decoding windows will ultimately no longer have to be
registered here: it will be done automatically by the PCIe driver once
Kirkwood has been migrated to use the upcoming mvebu PCIe driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
arm: mach-dove: convert to use mvebu-mbus driver

This commit migrates the mach-dove platforms to use the mvebu-mbus
driver and therefore removes the Dove-specific addr-map code.

In order to do this, we have to introduce a separate
dove_dt_init_early() function. It continues to be quite similar to
dove_init_early(), except that it does a DT-based initialization of
the mvebu-mbus driver. On the other hand, the dove_init_early()
function does a legacy initialization of the mvebu-mbus driver (which
will be removed once all boards have been migrated to the Device
Tree).

The address decoding windows are now registered in the
dove_setup_cpu_wins() function. It is worth noting that the four PCIe
address decoding windows will ultimately no longer have to be
registered here: it will be done automatically by the PCIe driver once
Dove has been migrated to use the upcoming mvebu PCIe driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
arm: mach-orion5x: convert to use mvebu-mbus driver

This commit migrates the mach-orion5x platforms to use the mvebu-mbus
driver and therefore removes the Orion5x-specific addr-map code.

In order to do this, we have to do a number of things:

 * introduce a separate dove_dt_init_early() function. It continues to
   be quite similar to dove_init_early(), except that it does a
   DT-based initialization of the mvebu-mbus driver. On the other
   hand, the dove_init_early() function does a legacy initialization
   of the mvebu-mbus driver (which will be removed once all boards
   have been migrated to the Device Tree).

 * introduce a orion5x-88f5182.dtsi file, which is used as an
   intermediate dtsi include between the board .dts (currently only
   orion5x-lacie-ethernet-disk-mini-v2.dts) and the common
   orion5x.dtsi. This is needed because the Orion5x SoCs have many
   things in common (described in orion5x.dtsi), but they are still
   some differences between 5182, 5281, etc, especially when it comes
   to address decoding windows. We therefore need to use a different
   compatible string for the different SoCs in the mbus DT node.

 * convert a number of orion5x_setup_xyz_win() calls to the
   appropriate mvebu_mbus_add_window() calls, as each board was doing
   its own setup for the NOR window or other devices. Ultimately,
   those devices will be probed from the DT.

 * the common address decoding windows are now registered in the
   orion5x_setup_wins() function. It is worth noting that the four
   PCIe address decoding windows will ultimately no longer have to be
   registered here: it will be done automatically by the PCIe driver
   once Dove has been migrated to use the upcoming mvebu PCIe driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-mv78xx0: convert to use the mvebu-mbus driver

This commit convers the mach-mv78xx0 sub-architecture to use the
mvebu-mbus driver. mv78xx0 has not been converted to the Device Tree
yet, so we simply have to call mvebu_mbus_init() in the ->init_early()
function, and modify the PCIe code so that it uses the new functions
provided by mvebu-mbus to create the needed PCIe windows.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: plat-orion: remove addr-map code

Now that all Marvell EBU platforms have been converted to use the
mvebu-mbus driver, we can remove the common plat-orion/addr-map.c code
that isn't compiled anymore.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
of/pci: Provide support for parsing PCI DT ranges property

DT bindings for PCI host bridges often use the ranges property to describe
memory and IO ranges - this binding tends to be the same across architectures
yet several parsing implementations exist, e.g. arch/mips/pci/pci.c,
arch/powerpc/kernel/pci-common.c, arch/sparc/kernel/pci.c and
arch/microblaze/pci/pci-common.c (clone of PPC). Some of these duplicate
functionality provided by drivers/of/address.c.

This patch provides a common iterator-based parser for the ranges property, it
is hoped this will reduce DT representation differences between architectures
and that architectures will migrate in part to this new parser.

It is also hoped (and the motativation for the patch) that this patch will
reduce duplication of code when writing host bridge drivers that are supported
by multiple architectures.

This patch provides struct resources from a device tree node, e.g.:

	u32 *last = NULL;
	struct resource res;
	while ((last = of_pci_process_ranges(np, res, last))) {
		//do something with res
	}

Platforms with quirks can then do what they like with the resource or migrate
common quirk handling to the parser. In an ideal world drivers can just request
the obtained resources and pass them on (e.g. pci_add_resource_offset).

Signed-off-by: Andrew Murray <Andrew.Murray@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
of/pci: Add of_pci_get_devfn() function

This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
of/pci: Add of_pci_get_bus() function

This function can be used to parse the number of a device's parent PCI
bus from a standard 5-cell PCI resource.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
of/pci: Add of_pci_parse_bus_range() function

This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
pci: infrastructure to add drivers in drivers/pci/host

As agreed by the community, PCI host drivers will now be stored in
drivers/pci/host. This commit adds this directory and the related
Kconfig/Makefile changes to allow new drivers to be added in this
directory.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: pci: add a align_resource hook

The PCI specifications says that an I/O region must be aligned on a 4
KB boundary, and a memory region aligned on a 1 MB boundary.

However, the Marvell PCIe interfaces rely on address decoding windows
(which allow to associate a range of physical addresses with a given
device). For PCIe memory windows, those windows are defined with a 1
MB granularity (which matches the PCI specs), but PCIe I/O windows can
only be defined with a 64 KB granularity, so they have to be 64 KB
aligned. We therefore need to tell the PCI core about this special
alignement requirement.

The PCI core already calls pcibios_align_resource() in the ARM PCI
core, specifically for such purposes. So this patch extends the ARM
PCI core so that it calls a ->align_resource() hook registered by the
PCI driver, exactly like the existing ->map_irq() and ->swizzle()
hooks.

A particular PCI driver can register a align_resource() hook, and do
its own specific alignement, depending on the specific constraints of
the underlying hardware.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Russell King <linux@arm.linux.org.uk>
clk: mvebu: create parent-child relation for PCIe clocks on Armada 370

The Armada 370 has two gatable clocks for each PCIe interface, and we
want both of them to be enabled. We therefore make one of the two
clocks a child of the other, as we did for the sataX and sataXlnk
clocks on Armada XP.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mike Turquette <mturquette@linaro.org>
clk: mvebu: add more PCIe clocks for Armada XP

The current revision of the datasheet only mentions the gatable clocks
for the PCIe 0.0, 0.1, 0.2 and 0.3 interfaces, and forgot to mention
the ones for the PCIe 1.0, 1.1, 1.2, 1.3, 2.0 and 3.0
interfaces. After confirmation with Marvell engineers, this patch adds
the missing gatable clocks for those PCIe interfaces.

It also changes the name of the previously existing PCIe gatable
clocks, in order to match the naming using the datasheets.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
pci: PCIe driver for Marvell Armada 370/XP systems

This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.

The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.

Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.

In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the new armada_370_xp_alloc_pcie_window()
function from mach-mvebu/addr-map.c.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mvebu: PCIe support is now available on mvebu

Now that the PCIe driver for mvebu has been integrated and all its
relevant dependencies, we can mark the ARCH_MVEBU platform has
MIGHT_HAVE_PCI, which allows to select the PCI bus support if needed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mvebu: add PCIe Device Tree informations for Armada 370

The Armada 370 SoC has two 1x PCIe 2.0 interfaces, so we add the
necessary Device Tree informations to make these interfaces availabel.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mvebu: add PCIe Device Tree informations for Armada XP

The Armada XP SoCs have multiple PCIe interfaces. The MV78230 has 2
PCIe units (one 4x or quad 1x, the other 1x only), the MV78260 has 3
PCIe units (two 4x or quad 1x and one 4x/1x), the MV78460 has 4 PCIe
units (two 4x or quad 1x and two 4x/1x). We therefore add the
necessary Device Tree informations to make those PCIe interfaces
usable.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4

The PlatHome OpenBlocks AX3-4 has an internal mini-PCIe slot that can
be used to plug mini-PCIe devices. We therefore enable the PCIe
interface that corresponds to this slot.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mvebu: PCIe Device Tree informations for Armada XP DB

The Marvell evaluation board (DB) for the Armada XP SoC has 6
physicals full-size PCIe slots, so we enable the corresponding PCIe
interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>