ARM: make xscale iwmmxt code multiplatform aware
authorArnd Bergmann <arnd@arndb.de>
Tue, 15 Apr 2014 13:38:39 +0000 (15:38 +0200)
committerArnd Bergmann <arnd@arndb.de>
Tue, 1 Dec 2015 20:44:24 +0000 (21:44 +0100)
commitd33c43ac185e2921e0f541872719588c3d491c60
treeda03c6f7cbc9c939d2ccc4c5f1a4bfe4ad8a7209
parent990f2f223cb479a15afda9eb8552582aa82e2404
ARM: make xscale iwmmxt code multiplatform aware

In a multiplatform configuration, we may end up building a kernel for
both Marvell PJ1 and an ARMv4 CPU implementation. In that case, the
xscale-cp0 code is built with gcc -march=armv4{,t}, which results in a
build error from the coprocessor instructions.

Since we know this code will only have to run on an actual xscale
processor, we can simply build the entire file for ARMv5TE.

Related to this, we need to handle the iWMMXT initialization sequence
differently during boot, to ensure we don't try to touch xscale
specific registers on other CPUs from the xscale_cp0_init initcall.
cpu_is_xscale() used to be hardcoded to '1' in any configuration that
enables any XScale-compatible core, but this breaks once we can have a
combined kernel with MMP1 and something else.

In this patch, I replace the existing cpu_is_xscale() macro with a new
cpu_is_xscale_family() macro that evaluates true for xscale, xsc3 and
mohawk, which makes the behavior more deterministic.

The two existing users of cpu_is_xscale() are modified accordingly,
but slightly change behavior for kernels that enable CPU_MOHAWK without
also enabling CPU_XSCALE or CPU_XSC3. Previously, these would leave leave
PMD_BIT4 in the page tables untouched, now they clear it as we've always
done for kernels that enable both MOHAWK and the support for the older
CPU types.

Since the previous behavior was inconsistent, I assume it was
unintentional.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
arch/arm/include/asm/cputype.h
arch/arm/kernel/xscale-cp0.c
arch/arm/mm/idmap.c
arch/arm/mm/mmu.c
This page took 0.02557 seconds and 5 git commands to generate.