arm: mach-dove: use plus instead of or for address definitions

Since we are going to use IOMEM() to define many base virtual
addresses, we can no longer use binary or to define the individual
register addresses ("binary or" arithmetic on pointers is not
allowed). Instead, use the more conventional plus operator to do so.

The binary or operators were actually not useful because the low-order
bits of the base address were always zero, so the usage of the binary
or operators was effectively identical to a plus operator.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-kirkwood: use plus instead of or for address definitions

Since we are going to use IOMEM() to define many base virtual
addresses, we can no longer use binary or to define the individual
register addresses ("binary or" arithmetic on pointers is not
allowed). Instead, use the more conventional plus operator to do so.

The binary or operators were actually not useful because the low-order
bits of the base address were always zero, so the usage of the binary
or operators was effectively identical to a plus operator.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-mv78xx0: use plus instead of or for address definitions

Since we are going to use IOMEM() to define many base virtual
addresses, we can no longer use binary or to define the individual
register addresses ("binary or" arithmetic on pointers is not
allowed). Instead, use the more conventional plus operator to do so.

The binary or operators were actually not useful because the low-order
bits of the base address were always zero, so the usage of the binary
or operators was effectively identical to a plus operator.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-orion5x: use plus instead of or for address definitions

Since we are going to use IOMEM() to define many base virtual
addresses, we can no longer use binary or to define the individual
register addresses ("binary or" arithmetic on pointers is not
allowed). Instead, use the more conventional plus operator to do so.

The binary or operators were actually not useful because the low-order
bits of the base address were always zero, so the usage of the binary
or operators was effectively identical to a plus operator.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-dove: use IOMEM() for base address definitions

We now define all virtual base address constants using IOMEM() so that
those are naturally typed as void __iomem pointers, and we do the
necessary adjustements in the mach-dove code.

Note that we introduce a few temporary additional "unsigned long"
casts when calling into plat-orion functions. Those are removed by
followup patches converting plat-orion functions to void __iomem
pointers as well.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-kirkwood: use IOMEM() for base address definitions

We now define all virtual base address constants using IOMEM() so that
those are naturally typed as void __iomem pointers, and we do the
necessary adjustements in the mach-kirkwood code.

Note that we introduce a few temporary additional "unsigned long"
casts when calling into plat-orion functions. Those are removed by
followup patches converting plat-orion functions to void __iomem
pointers as well.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-mv78xx0: use IOMEM() for base address definitions

We now define all virtual base address constants using IOMEM() so that
those are naturally typed as void __iomem pointers, and we do the
necessary adjustements in the mach-mv78xx0 code.

Note that we introduce a few temporary additional "unsigned long"
casts when calling into plat-orion functions. Those are removed by
followup patches converting plat-orion functions to void __iomem
pointers as well.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-orion5x: use IOMEM() for base address definitions

We now define all virtual base address constants using IOMEM() so that
those are naturally typed as void __iomem pointers, and we do the
necessary adjustements in the mach-orion5x code.

Note that we introduce a few temporary additional "unsigned long"
casts when calling into plat-orion functions. Those are removed by
followup patches converting plat-orion functions to void __iomem
pointers as well.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: mach-mvebu: use IOMEM() for base address definitions

We now define all virtual base address constants using IOMEM() so that
those are naturally typed as void __iomem pointers, and we do the
necessary adjustements in the mach-mvebu code.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: plat-orion: use void __iomem pointers for UART registration functions

The registration functions for UARTs now take void __iomem pointers,
so we remove the temporary "unsigned long" casts from the
mach-*/common.c files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: plat-orion: use void __iomem pointers for MPP functions

The registration function for MPP now takes void __iomem pointers, so
we remove the temporary "unsigned long" casts from the mach-*/mpp.c
files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: plat-orion: use void __iomem pointers for time functions

The functions for time management now take void __iomem pointers, so
we remove the temporary "unsigned long" casts from the mach-*/common.c
files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: plat-orion: use void __iomem pointers for addr-map functions

The functions for address mapping management now take void __iomem
pointers, so we remove the temporary "unsigned long" casts from the
mach-*/common.c files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option

Until now, the PLAT_ORION configuration option was common to all the
Marvell EBU SoCs, and selecting this option had the effect of enabling
the MPP code, GPIO code, address decoding and PCIe code from
plat-orion, as well as providing access to driver-specific header
files from plat-orion/include.

However, the Armada 370 and XP SoCs will not use the MPP and GPIO code
(instead some proper pinctrl and gpio drivers are in preparation), and
generally, we want to move away from plat-orion and instead have
everything in mach-mvebu.

That said, in the mean time, we want to leverage the driver-specific
headers as well as the address decoding code, so we introduce
PLAT_ORION_LEGACY. The older Marvell SoCs need to select
PLAT_ORION_LEGACY, while the newer Marvell SoCs need to select
PLAT_ORION. Of course, when PLAT_ORION_LEGACY is selected, it
automatically selects PLAT_ORION.

Then, with just PLAT_ORION, you have the address decoding code plus
the driver-specific headers. If you add PLAT_ORION_LEGACY to this, you
gain the old MPP, GPIO and PCIe code.

Again, this is only a temporary solution until we make all Marvell EBU
platforms converge into the mach-mvebu directory. This solution avoids
duplicating the existing address decoding code into mach-mvebu.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
arm: plat-orion: make bridge_virt_base non-const to support DT use case

For the Armada 370 and XP SoCs where the DT is used, we need to fill
at runtime the bridge_virt_base field on the
orion_addr_map_cfg. Therefore, remove the 'const' qualifier on this
field.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
arm: mvebu: add basic address decoding support to Armada 370/XP

This commit adds basic support for address decoding configuration for
the Armada 370 and Armada XP SoCs, re-using the infrastructure
provided in plat-orion.

For now, only a BootROM window is configured on Armada XP, which is
needed to get the non-boot CPUs started and is therefore a requirement
for SMP support.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
arm: mvebu: add address decoding controller to the DT

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>