For kexec, we need more functionality from the IDMAP system.  We need to
be able to convert physical addresses to their identity mappped versions
as well as virtual addresses.

Convert the existing arch_virt_to_idmap() to deal with physical
addresses instead.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

K2G SoC family is the newest version of the Keystone family of processors.

The technical reference manual for K2G can be found here:
http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf

Add new bindings for K2G and the K2G evm. Also document these new bindings.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NFranklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: NSantosh Shilimkar <ssantosh@kernel.org>

Make virt_to_idmap() return an unsigned long rather than phys_addr_t.

Returning phys_addr_t here makes no sense, because the definition of
virt_to_idmap() is that it shall return a physical address which maps
identically with the virtual address.  Since virtual addresses are
limited to 32-bit, identity mapped physical addresses are as well.

Almost all users already had an implicit narrowing cast to unsigned long
so let's make this official and part of this interface.
Tested-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

With future SoCs of keystone2 family, the generic compatible match
may not be sufficient to handle SoC specific handling. So introduce
matches based on SoC compatiblity.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NSantosh Shilimkar <ssantosh@kernel.org>

The init_meminfo() method is not about initialising meminfo - it's about
fixing up the physical to virtual translation so that we use a different
physical address space, possibly above the 4GB physical address space.
Therefore, the name "init_meminfo()" is confusing.

Rename it to pv_fixup() instead.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There is no point platform code doing this, let's move it into the
generic code so it doesn't get duplicated.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Make the init_meminfo function return the offset to be applied to the
phys-to-virt translation constants.  This allows us to move the update
into generic code, along with the requirements for this update.

This avoids platforms having to know the details of the phys-to-virt
translation support.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We ideally want the init_meminfo function to do nothing but return the
delta to be applied to PHYS_OFFSET - it should do nothing else.  As we
can detect in platform init code whether we are running in the high
physical address space, move the platform notifier initialisation
entirely into the platform init code.
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Tested-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The definition

	static const char *axxia_dt_match[] __initconst = {
		...

defines a changable array of constant strings. That is you must not do:

	*axxia_dt_match[0] = 'k';

but

	axxia_dt_match[0] = "different string";

is fine. So the annotation __initconst is wrong and yields a compiler
error when other really const variables are added with __initconst.

As the struct machine_desc member dt_compat is declared as

	const char *const *dt_compat;

making the arrays const is the better alternative over changing all
annotations to __initdata.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Laura's series removed the meminfo structure and its no longer available.
Update keystone code to remove the usage of it.
Reported-by: NRussell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Remove reset stuff in flavour of using keystone reset driver:
driver/power/reset/keystone-reset.c
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Tested-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

With late code patching updates for LPAE machines has merged now and
memblock conversion from bootmem is on its way, Keystone can switch to
the coherent memory address space which starts beyond 4GB boundary.
The idmap alias needs are managed via virt_to_idmap() for boot purpose.
Tested-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

As suggested by Olof Johansson at
http://www.spinics.net/lists/arm-kernel/msg314009.html.
It be better just keeping a "ti,keystone" top-level compatible and
just using that to probe. If so we don't have to touch the file
for new boards in the future.

So use common "ti,keystone" compatible in keystone.c for all boards.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

This patch add compatibility strings for k2hk, k2l and k2e EVMs

Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Keystone PM bus makes use of generic PM clock core backend. Since
generic PM clock core uses platform bus notifiers to track events like
ADD_DEVICE/DEL_DEVICE and to fill clock lists per each device, we need
to initialise Keystone PM domains before the platform devices have been
created.

Hence, fix it by moving keystone_pm_runtime_init() before platform
devices have been populated.
Reported-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Keystone II peripheral devices support 32-bit DMA and hence can access only
first 2GB of the memory address space. So set the platform dma_zone_size
to handle that case.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Fix the following compilation warning:

  arch/arm/mach-keystone/keystone.c:74:2: warning: initialization from incompatible pointer type [enabled by default]
  arch/arm/mach-keystone/keystone.c:74:2: warning: (near initialization for ‘__mach_desc_KEYSTONE.restart’) [enabled by default]
Signed-off-by: NVincent Stehlé <vincent.stehle@freescale.com>
Cc: Robin Holt <holt@sgi.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: trivial@kernel.org
Signed-off-by: NOlof Johansson <olof@lixom.net>

Add basic SMP support for Keystone machines. This does not
include support for CPU hotplug for now.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: arm@kernel.org
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Texas Instruments Keystone family of multi-core devices are
based on ARM Cortex A15. Patch adds basic definitions for a
new Keystone sub-architecture in ARM.

The TCI66xxK2H Communications Infrastructure Keystone SoCs
are member of the C66x family based on TI's new KeyStone 2
multi-core SoC Architecture designed specifically for high
performance wireless and networking infrastructure applications.
The SOCs contains many subsystems like Cortex A15 ARM CorePacs,
C66XX DSP CorePacs, MSMC memory controller, Tera Net bus,
IP Network, Navigator, Hyperlink, 1G/10G Ethernet, Radio layers
and queue based communication systems.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: arm@kernel.org
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>