arm: plat-orion: only build addr-map.c when needed

For now, addr-map.c is needed by all 5 Marvell EBU
sub-architectures. However, we are going to introduce the orion-mbus
driver, which will replace the address decoding code from
addr-map.c. In order to ease the migration process, we will do that
one sub-architecture at a time, which will require us to remove the
compilation of addr-map.c one sub-architecture at a time.

Therefore, we split the unconditional obj-y inclusion of addr-map.c
into 5 conditionals obj-$(CONFIG_...) lines, one per sub-architecture.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: plat-orion: use mv_mbus_dram_info() in PCIe code

The PCIe code was directly accessing the orion_mbus_dram_info
structure to get access to a description of the SDRAM chip selects in
order to configure the PCIe -> SDRAM address decoding
windows.

However, with the introduction of the orion-mbus driver, we are going
to remove this global structure and instead leave only the exported
mv_mbus_dram_info() function to access this description of the SDRAM
chip selects. Therefore, we simply switch to using this API.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-orion5x: use mv_mbus_dram_info() in PCI code

The PCI code was directly accessing the orion_mbus_dram_info structure
to get access to a description of the SDRAM chip selects in order to
configure the PCIe -> SDRAM address decoding windows.

However, with the introduction of the mvebu-mbus driver, we are going
to remove this global structure and instead leave only the exported
mv_mbus_dram_info() function to access this description of the SDRAM
chip selects. Therefore, we simply switch to using this API.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
bus: introduce an Marvell EBU MBus driver

The Marvell EBU SoCs have a configurable physical address space
layout: the physical ranges of memory used to address PCI(e)
interfaces, NOR flashes, SRAM and various other types of memory are
configurable by software, through a mechanism of so-called 'address
decoding windows'.

This new driver mvebu-mbus consolidates the existing code to address
the configuration of these memory ranges, which is spread into
mach-mvebu, mach-orion5x, mach-mv78xx0, mach-dove and mach-kirkwood.

Following patches convert each Marvell EBU SoC family to use this
driver, therefore removing the old code that was configuring the
address decoding windows.

It is worth mentioning that the MVEBU_MBUS Kconfig option is
intentionally added as a blind option. The new driver implements and
exports the mv_mbus_dram_info() function, which is used by various
Marvell drivers throughout the tree to get access to window
configuration parameters that they require. This function is also
implemented in arch/arm/plat-orion/addr-map.c, which ultimately gets
removed at the end of this patch series. So, in order to preserve
bisectability, we want to ensure that *either* this new driver, *or*
the legacy code in plat-orion/addr-map.c gets compiled in.

By making MVEBU_MBUS a blind option, we are sure that only a platform
that does 'select MVEBU_MBUS' will get this new driver compiled
in. Therefore, throughout the next patches that convert the Marvell
sub-architectures one after the other to this new driver, we add the
'select MVEBU_MBUS' and also ensure to remove plat-orion/addr-map.c
from the build for this specific sub-architecture. This ensures that
bisectability is preserved.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
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>
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>