I accidentally move the DEBUG_LL_UART_EFM32 option when sorting all
other options alphanumerically, but it belongs into the same group
as DEBUG_LL_UART_8250 and DEBUG_LL_UART_PL01X.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 1dc93416 ("ARM: debug-ll: reorder Kconfig alphanumerically")

The debug-ll infrastructure can be configured in two ways, either
by selecting a platform specific debug option, or by picking one
of the generic options (8250 or pl01x typically). For compatibility
with multiplatform kernels, we have changed a couple of platforms
to use the former method now when they used to use the latter.

Unfortunately, this broke the defconfigs because now they still
enable CONFIG_DEBUG_LL_UART_PL01X or CONFIG_DEBUG_LL_UART_8250,
and we no longer configure the correct register addresses
automatically.

Embarrassingly, this was only found in linux-next when the
defconfig builds turned up errors for multiple people, and I
had not caught those in my own tests, which were done using
the randconfig fixes patchset on top, and that has a workaround
to avoid a build error when the addresses are not configured.

The error was something like:

.config:2010:warning: symbol value '' invalid for DEBUG_UART_PHYS
.config:2011:warning: symbol value '' invalid for DEBUG_UART_VIRT

This patch avoids the problem by removing the respective
statements from the defconfig files. Any out of tree defconfig
files on the platforms I have changed will have to do the same
change or run into the build error above. Any users that have
a full .config already set the correct DEBUG_UART_PHYS/VIRT
addresses and do not need to change anything.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 4db22c10 ("ARM: debug-ll: rework integrator/versatile handling")
Fixes: f06455fa ("ARM: debug-ll: rework ep93xx handling")
Fixes: c047f529 ("ARM: debug-ll: reorganize mvebu debug uart config")
Fixes: 59bd4c38 ("ARM: debug-ll: rework lpc32xx handling")

Merge "mvebu soc for 4.5 (part 1)" from Gregory CLEMENT:

- orion5x/mv78xx0 multiplatform conversion
- legacy dove PMU support conversion

* tag 'mvebu-soc-4.5-1' of git://git.infradead.org/linux-mvebu:
  ARM: dove: convert legacy dove to PMU support
  soc: dove: add legacy support to PMU driver
  ARM: orion5x: multiplatform support
  ARM: orion5x: clean up mach/*.h headers
  ARM: mv78xx0: multiplatform support
  ARM: mv78xx0: clean up mach/*.h headers
  ARM: orion: use SPARSE_IRQ everywhere
  ARM: orion: always use MULTI_IRQ_HANDLER
  ARM: orion: move watchdog setup to mach-orion5x

Conflicts:
	arch/arm/Kconfig
	arch/arm/mach-dove/include/mach/entry-macro.S
	arch/arm/mach-orion5x/include/mach/entry-macro.S

Merge tag 'realview-base-armsoc-1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into next/multiplatform

Merge "Realview multiplatform support" from Linus Walleij:

The board and infrastructure changes for RealView
multiplatform and extended DT support.

* tag 'realview-base-armsoc-1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator:
  ARM: realview: add an DT SMP boot method
  ARM: realview: select SP810 and ICST for the DT variant
  soc: versatile: add support for the PB11MPCore
  clk: versatile-icst: add device tree support
  clk: versatile-icst: refactor to allocate regmap separately
  clk: versatile-icst: convert to use regmap
  ARM: realview: remove private barrier implementation
  ARM: no longer force unbuffered DMA for realview
  clk/realview: stop using machine headers
  ARM: realview: don't map undefined PCI registers
  ARM: realview: remove sparsemem hack

Conflicts:
	drivers/clk/versatile/Kconfig

Merge "ARM Versatile multi-platform support" from Rob Herring:

Arnd lit a fire under me to dust this off and get it merged. So here it
is. The main change from prior version is I merged all the code to a
single file. It's a bigger patch than I'd like, but I don't think trying
to do it in multiple steps is worth it.

This is dependent on some solution for the default platform choice on
!MMU builds (allnoconfig) as it can't be Versatile after this series.
Arnd has some ideas on how to address that.

This is tested under QEMU. Linus previously tested this on actual h/w
and had a problem with the display identification which needs
investigation or agreement to worry about it if and when someone
actually cares.

* versatile/multiplatform:
  ARM: versatile: convert to multi-platform
  ARM: versatile: merge mach code into a single file
  ARM: versatile: switch to DT only booting and remove legacy code
  ARM: versatile: add DT based PCI detection
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>

Now that all the prerequisites are in place, we can enable Versatile
boards for multi-platform kernels.
Signed-off-by: NRob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

With DT-only support now in place and most of the legacy code removed,
the separation of core.c and versatile_dt.c makes little sense. The
headers in mach include directory also have to move for multi-platform
support, but with a single .c file the remaining definitions needed can
also be moved into the versatile_dt.c.

In the move, the system registers and IB2 registers are converted to
run-time mappings and all register accesses converted to use
readl/writel.
Signed-off-by: NRob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

With DT support for clocks, irqchips, timers, and PCI now in place, DT
based booting has feature parity with non-DT legacy boot. The final
piece is actually enabling common clock support on Versatile. Enabling
full DT support requires either removing the old Versatile clock code,
updating the legacy boot to use the common clock code, or making DT and
legacy boot mutually exclusive. Given that removing legacy boot code is
the goal anyway, I am going with the 1st option.
Signed-off-by: NRob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mike Turquette <mturquette@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Disable the Versatile PCI DT node when no PCI backplane is detected. This
will prevent the Versatile PCI driver from probing when PCI is not
populated.
Signed-off-by: NRob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The ezx platform contains multiple machine descriptors, but not all
of them use all of the data structures, and it's possible to disable
all of the machines, which produces some harmless warnings:

mach-pxa/ezx.c:53:26: warning: 'ezx_pwm_lookup' defined but not used [-Wunused-variable]
mach-pxa/ezx.c:86:31: warning: 'ezx_fb_info_1' defined but not used [-Wunused-variable]
mach-pxa/ezx.c:107:31: warning: 'ezx_fb_info_2' defined but not used [-Wunused-variable]
mach-pxa/ezx.c:113:32: warning: 'ezx_devices' defined but not used [-Wunused-variable]
mach-pxa/ezx.c:117:22: warning: 'ezx_pin_config' defined but not used [-Wunused-variable]

This marks all those structures as __maybe_unused to avoid the warnings.
Obviously a configuration that contains the ezx platform but no specific
model is a bit silly, but it should not cause compile-time warnings.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>

The raumfeld.c file contains three similar machine definitions,
each with their own init function. If one or more of them are
disabled, we get compile-time warnings:

arm/mach-pxa/raumfeld.c:1070:123: warning: 'raumfeld_connector_init' defined but not used [-Wunused-function]
arm/mach-pxa/raumfeld.c:1082:123: warning: 'raumfeld_speaker_init' defined but not used [-Wunused-function]

This marks the functions as __maybe_unused to avoid the warnings.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NDaniel Mack <daniel@zonque.org>

In an old commit, we worked around the duplicate definition of
GPIO24_SSP1_SFRM in cm-x2xx.c, which includes files for both
pxa25x and pxa27x. Apparently the problem has come back and we
now have four additional duplicate symbols that cause warnings:

In file included from /git/arm-soc/arch/arm/mach-pxa/pxa27x.h:7:0,
                 from /git/arm-soc/arch/arm/mach-pxa/cm-x2xx.c:27:
/git/arm-soc/arch/arm/mach-pxa/mfp-pxa27x.h:21:0: warning: "GPIO86_GPIO" redefined
 #define GPIO86_GPIO  MFP_CFG_IN(GPIO86, AF0)

This uses the same hack as before and undefines all symbols that
are defined more than once. Fortunately, cm-x2xx does not need
any of these.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>

* mmp/multiplatform:
  ARM: mmp: avoid unused functions
  ARM: mmp: move into ARCH_MULTIPLATFORM
  ARM: mmp: make all header files local
  ARM: mmp: make plat-pxa build standalone
  ARM: mmp: remove remaining legacy pxa-dma support
  ARM: mohawk: allow building with MMU disabled
  ARM: make xscale iwmmxt code multiplatform aware
  clk: mmp: stop using platform headers

* s3c64xx/multiplatform:
  ARM: s3c64xx: allow building without board support
  ARM: s3c64xx: multiplatform support
  ARM: s3c64xx: use common debug-ll implementation
  ARM: s3c64xx: use new adc/touchscreen driver
  iio: exynos-adc: add experimental touchscreen support
  ARM: s3c64xx: enable sparse IRQ support
  ARM: s3c64xx: prepare initcalls for multiplatform
  gpio: samsung: move gpio-samsung driver back to platform code
  ASoC: samsung/smartq: use dynamic registration
  Input: s3c2410_ts: fix S3C_ADC dependency

Conflicts:
	arch/arm/Kconfig.debug

* multiplatform/debug-ll:
  ARM: debug-ll: reorder Kconfig alphanumerically
  ARM: debug-ll: rework footbridge handling
  ARM: debug-ll: rework lpc32xx handling
  ARM: debug-ll: rework gemini handling
  ARM: debug-ll: rework integrator/versatile handling
  ARM: debug-ll: rework SPEAr handling
  ARM: debug-ll: rework ep93xx handling
  ARM: debug-ll: reorganize mvebu debug uart config
  ARM: debug-ll: fix UART configuration with ARCH_KEYSTONE

The file has gotten a little out of sync, as platforms got
added in the wrong place, or have been renamed. This moves
the options around, but should not change any functionality.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Footbridge has two debug ports that are handled a bit differently:

The 8250 port uses the normal debug/8250.S implementation that is shared
with a lot of other platforms, but it relies on the DEBUG_UART_8250
option to be turned on automatically instead of being selected by
DEBUG_FOOTBRIDGE_COM1 as we do for most other platforms. I'm changing
this to use a 'select' and change the dependency to the debug symbol
rather than the platform symbol for consistency.

The DC21285 UART has a separate top-level option, and relies on
the traditional include/mach/debug-macro.S method. With the s3c64xx
multiplatform series queued up for 4.5, it is now the last one that does
this, so by moving this file to include/debug/dc21285.S, we can get
all platforms to do things the same way.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

LPC32xx can not yet be configured in a multiplatform kernel, but
if we ever get there, enabling one of the LPC32xx platforms
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.

This changes the logic to use the LPC32xx default addresses only
if we have also picked the respective Kconfig symbols introduced
here.

While we're at it, this also reorders the virtual address as
it should be.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>

Gemini can not yet be configured in a multiplatform kernel, but
if we ever get there, enabling one of the gemini platforms
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.

This changes the logic to use the gemini default addresses and
the flow control settings only if we have also picked the respective
Kconfig symbols introduced here.

While we're at it, this also reorders the virtual address as
it should be.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NHans Ulli Kroll <ulli.kroll@googlemail.com>

Enabling one of the integrator platforms in a multiplatform kernel
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.

This changes the logic to use the integrator default addresses only
if we have also picked the respective Kconfig symbols introduced
here. Versatile is not yet part of multiplatform, but hopefully
soon will be, so we do the same change for versatile as well.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Enabling one of the SPEAr platforms in a multiplatform kernel
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.

This changes the logic to use the SPEAr default addresses only
if we have also picked the respective Kconfig symbols introduced
here.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This makes ep93xx debug-ll handling more consistent with the other
platforms, by adding a separate Kconfig symbol for it that
in turn selects the standard DEBUG_UART_PL01X symbol.

We still have to pick a physical address even if DEBUG_LL is disabled
here, because the EP93xx uncompress output code uses
CONFIG_DEBUG_UART_PHYS. If we ever move to multiplatform support,
this can go away.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

As we are moving dove/mv78xx0/orion into multiplatform, the debug-ll
configuration options for these platforms are conflicting with the
multiplatform configuration: enabling one of those platforms sometimes
changes the default addresses to the ones used on one of them, rather
than the one that was selected in Kconfig.

This changes the configuration so we share the physical address
configuration with mach-mvebu.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

We may have multiple platforms enabled and also DEBUG_LL
configured for one of them. However if we enable ARCH_KEYSTONE,
we default to using 32-bit UART access independent of which
platform we are actually using, which can be confusing.

This changes the logic so the 32-bit default gets only
used by default if we actually configure the keystone
UART, as opposed to picking some other 8250 setting on
a kernel that has keystone support enabled.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This adds an SMP boot method for the ARM RealView reference
designs. We also select HAVE_SMP by default and make it use
SMP_ON_UP so we only need to support one single kernel across
the RealView reference designs when using DT.

The RealViews need to have the SCU (Snoop Control Unit)
activated on boot, and this is now done by looking up its
address from the device tree and initializing it and counting
the available cores.

The RealViews boot by using a magic address register in the
system controller (SYS_FLAGS) to store the boot address,
the ROM will then read this register to the PC when the CPUs
are taken out of WFI. This code uses a handle to the syscon
regmap to access this register.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The device tree boot for RealView need the SP810 system controller
(same as found on the Versatile Express) to set up the timers on the
board so the machine can tick. It further utilize the ICST307 through
its system controller for 6 other oscillators. We have to select these
from Kconfig or the machine does not boot.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The SoC driver needs a minor update to display the correct
sysfs information for the PB11MPCore.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This adds support for the ARM syscon ICST clocks to initialized
directly from the device tree syscon node on ARM Integrator,
Versatile and RealView reference designs.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-clk@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Break out the registration function so it creates a regmap and
pass to the setup function, so the latter can be shared with
a device tree probe function that already has a regmap.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-clk@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Instead of passing around register bases, pass around a regmap
in this driver. This refactoring make things so much easier when
we later want to manage an ICST that is part of a syscon.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-clk@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The realview barrier implementation tries to avoid calling outer_sync in order
to not lock up as a result of a bug in the l220 cache controller.

This gets in the way of the multiplatform support, but we can still remove
it if we make sure that the outer_sync function never gets called, by replacing
the function pointer with NULL, right after initialization.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
[Fixed up header inclusions]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit 42c4dafe ("ARM: 6202/1: Do not ARM_DMA_MEM_BUFFERABLE
on RealView boards with L210/L220") changed the generic setting for
ARM_DMA_MEM_BUFFERABLE to be disabled on any Realview kernel that includes
support for any of the ARM11 variations. Doing this was required to
allow doing DMA without a lockup in the l2x0 cache controller on the
Realview platform.

Unfortunately, in a kernel that also contains support for any ARMv7
based machine, the same change makes it impossible to do DMA on ARMv7,
which gets in the way of enabling multiplatform support on Realview.

As confirmed by Catalin Marinas and Linus Walleij, the current
code for Realview that we have in the kernel does not actually
perform any DMA, and this is unlikely to change in the future.
Therefore we can revert 42c4dafe without introducing regressions,
but we must never start using DMA on this platform in the future.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to move realview into multiplatform, we have to prevent device
drivers from accessing the machine header files.

In case of the clk driver, this is very simple, we just copy the
small set of register definitions into the driver that needs them.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

PCI support for realview was never merged, and trying to build realview with
CONFIG_PCI enabled fails because the constants for the mapping windows are
not defined anywhere.

This removes them from the static I/O window mapping table as a preparation
for multiplatform support.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The realview-pbx platform has an elaborate way of avoiding the use of highmem
by redefining its phys_to_virt function. In practice this doesn't help all
that much, and it gets in the way of doing multiplatform builds for
realview.

This removes the feature and kills off the mach/memory.h file for realview.
We also lose the ability to do sparsemem with this patch, but that should
be put back into place for generic multiplatform configurations, to save
a little memory on PBX.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since Dove has non-DT support for various facilities in the PMU, convert
the legacy support to use the new PMU driver.
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>

Add support for legacy non-DT Dove to the PMU driver, so that we can
transition the legacy support over.

[gregory.clement@free-electrons.com: removed pm_genpd_poweroff_unused]
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>

The orion5x platform is now ready to be enabled for multiplatform
support, this patch does the switch over by modifying the Kconfig file,
the defconfig and removing the last mach/*.h header that becomes obsolete
with this.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>

This is a simple move of all header files that are no longer
included by anything else from the include/mach directory
to the platform directory itself as preparation for
multiplatform support.

The mach/uncompress.h headers are left in place for now,
and are mildly modified to be independent of the other
headers. They will be removed entirely when ARCH_MULTIPLATFORM
gets enabled and they become obsolete.

Rather than updating the path names inside of the comments
of each header, I delete those comments to avoid having to
update them again, should they get moved or copied another
time.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>

The mv78xx0 platform is now ready to be enabled for multiplatform
support, this patch does the switch over by modifying the Kconfig file,
the defconfig and removing the last mach/*.h header that becomes obsolete
with this.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>