summaryrefslogtreecommitdiff
path: root/tools/power
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2014-04-15 13:38:39 (GMT)
committerArnd Bergmann <arnd@arndb.de>2015-12-01 20:44:24 (GMT)
commitd33c43ac185e2921e0f541872719588c3d491c60 (patch)
treeda03c6f7cbc9c939d2ccc4c5f1a4bfe4ad8a7209 /tools/power
parent990f2f223cb479a15afda9eb8552582aa82e2404 (diff)
downloadlinux-d33c43ac185e2921e0f541872719588c3d491c60.tar.xz
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>
Diffstat (limited to 'tools/power')
0 files changed, 0 insertions, 0 deletions