BMC/Intel-BMC/linux.git/arch/arm/mach-hisi, branch dev

Merge branch 'for-arm-soc' into for-next

2015-06-12T20:18:59+00:00

ARM: v7 setup function should invalidate L1 cache

2015-06-01T10:30:26+00:00

All ARMv5 and older CPUs invalidate their caches in the early assembly setup function, prior to enabling the MMU. This is because the L1 cache should not contain any data relevant to the execution of the kernel at this point; all data should have been flushed out to memory. This requirement should also be true for ARMv6 and ARMv7 CPUs - indeed, these typically do not search their caches when caching is disabled (as it needs to be when the MMU is disabled) so this change should be safe. ARMv7 allows there to be CPUs which search their caches while caching is disabled, and it's permitted that the cache is uninitialised at boot; for these, the architecture reference manual requires that an implementation specific code sequence is used immediately after reset to ensure that the cache is placed into a sane state. Such functionality is definitely outside the remit of the Linux kernel, and must be done by the SoC's firmware before _any_ CPU gets to the Linux kernel. Changing the data cache clean+invalidate to a mere invalidate allows us to get rid of a lot of platform specific hacks around this issue for their secondary CPU bringup paths - some of which were buggy. Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli Tested-by: Heiko Stuebner Tested-by: Dinh Nguyen Acked-by: Sebastian Hesselbarth Tested-by: Sebastian Hesselbarth Acked-by: Shawn Guo Tested-by: Thierry Reding Acked-by: Thierry Reding Tested-by: Geert Uytterhoeven Tested-by: Michal Simek Tested-by: Wei Xu Signed-off-by: Russell King

ARM: 8370/1: hisi: fix hip04 build without HOTPLUG_CPU

2015-05-27T23:22:49+00:00

The hip04 smp implementation provides the hotplug operations (cpu_die and cpu_kill) unconditionally at the moment, which leads to a build error when HOTPLUG_CPU is disabled: mach-hisi/platmcpm.c:242:13: note: (near initialization for 'hip04_smp_ops') mach-hisi/platmcpm.c:242:2: error: unknown field 'cpu_die' specified in initializer mach-hisi/platmcpm.c:243:2: error: unknown field 'cpu_kill' specified in initializer This uses an #ifdef to remove the code from the build when that option is not set. Fixes: 905cdf9dda5d ("ARM: hisi/hip04: remove the MCPM overhead") Signed-off-by: Arnd Bergmann Acked-by: Nicolas Pitre Acked-by: Wei Xu Signed-off-by: Russell King

ARM: hisi/hip04: remove the MCPM overhead

2015-05-06T15:42:01+00:00

This platform is currently relying on the MCPM infrastructure for no apparent reason. The MCPM concurrency handling brings no benefits here as there is no asynchronous CPU wake-ups to be concerned about (this is used for CPU hotplug and secondary boot only, not for CPU idle). This platform is also different from the other MCPM users because a given CPU can't shut itself down completely without the assistance of another CPU. This is at odds with the on-going MCPM backend refactoring. To simplify things, this is converted to hook directly into the smp_operations callbacks, bypassing the MCPM infrastructure. Tested-by: Wei Xu Cc: Haojian Zhuang Signed-off-by: Nicolas Pitre

ARM: make arrays containing machine compatible strings const

2015-02-19T08:44:17+00:00

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: Uwe Kleine-König Signed-off-by: Arnd Bergmann

ARM: hisi: enable smp for HiP01

2015-01-21T22:33:39+00:00

Enable smp for HiP01 board. Signed-off-by: Wang Long Signed-off-by: Wei Xu [olof: split off the dts change to a separate commit] Signed-off-by: Olof Johansson

ARM: hisi: rename secondary_startup function

2015-01-21T22:33:01+00:00

As hix5hd2 and hip01 has the same secondary_startup so rename hix5hd2_secondary_startup to to hisi_secondary_startup. the hip01 will use hisi_secondary_startup for the secondary core boot. Signed-off-by: Wang Long Signed-off-by: Wei Xu Signed-off-by: Olof Johansson

ARM: hisi: rename smp_prepares_cpus function

2015-01-21T22:32:53+00:00

As hix5hd2 and hip01 has the same .smp_prepare_cpus in struct smp_operations, so rename hix5hd2_smp_prepare_cpus to hisi_common_smp_prepare_cpus. the hip01 will use hisi_common_smp_prepare_cpus in its struct smp_operations. Signed-off-by: Wang Long Signed-off-by: Wei Xu Signed-off-by: Olof Johansson

ARM: hisi: enable HiP01 SoC

2015-01-21T22:31:06+00:00

Enable Hisilicon HiP01 SoC. This HiP01 SoC series support both one core or dual cores and quad cores. The core is Cortex A9. Signed-off-by: Wang Long Signed-off-by: Wei Xu Signed-off-by: Olof Johansson

ARM: hisi: depend on ARCH_MULTI_V7

2014-10-02T14:40:10+00:00

hisi has a general dependency on ARCH_MULTIPLATFORM, which is problematic when building a kernel for non-V7 platforms but selecting drivers that might conflict with other architecture levels. In this case, it broke my (still out of tree) patch set that enables V7M multiplatform support, since that does not enable MULTI_IRQ support: arch/arm/kernel/built-in.o: In function `set_handle_irq': arch/arm/kernel/irq.c:125: undefined reference to `handle_arch_irq' arch/arm/kernel/built-in.o: In function `setup_arch': arch/arm/kernel/setup.c:965: undefined reference to `handle_arch_irq' Since all hisilicon platforms are ARMv7 based, we can avoid this problem by just making the dependency more specific. Signed-off-by: Arnd Bergmann Acked-by: Wei Xu