summaryrefslogtreecommitdiffstats
path: root/arch/arm/mm/proc-xscale.S
diff options
context:
space:
mode:
authorLennert Buytenhek <buytenh@wantstofly.org>2006-12-03 18:51:14 +0100
committerRussell King <rmk+kernel@arm.linux.org.uk>2006-12-03 17:52:22 +0000
commitafe4b25e7d9260d85fccb2d13c9933a987bdfc8a (patch)
tree9b603e52ef91531089b45e5860e89d91d2e01565 /arch/arm/mm/proc-xscale.S
parentf5236225a3858b505221a59233af1f1158be9139 (diff)
downloadop-kernel-dev-afe4b25e7d9260d85fccb2d13c9933a987bdfc8a.zip
op-kernel-dev-afe4b25e7d9260d85fccb2d13c9933a987bdfc8a.tar.gz
[ARM] 3881/4: xscale: clean up cp0/cp1 handling
XScale cores either have a DSP coprocessor (which contains a single 40 bit accumulator register), or an iWMMXt coprocessor (which contains eight 64 bit registers.) Because of the small amount of state in the DSP coprocessor, access to the DSP coprocessor (CP0) is always enabled, and DSP context switching is done unconditionally on every task switch. Access to the iWMMXt coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is first issued, and iWMMXt context switching is done lazily. CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will have iWMMXt support', but boards are supposed to select this config symbol by hand, and at least one pxa27x board doesn't get this right, so on that board, proc-xscale.S will incorrectly assume that we have a DSP coprocessor, enable CP0 on boot, and we will then only save the first iWMMXt register (wR0) on context switches, which is Bad. This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on might have iWMMXt support, and we will enable iWMMXt context switching if it does.' This means that with this patch, running a CONFIG_IWMMXT=n kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt state over context switches, and running a CONFIG_IWMMXT=y kernel on a non-iWMMXt capable CPU will still do DSP context save/restore. These changes should make iWMMXt work on PXA3xx, and as a side effect, enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined), as well as setting and using HWCAP_IWMMXT properly. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'arch/arm/mm/proc-xscale.S')
-rw-r--r--arch/arm/mm/proc-xscale.S9
1 files changed, 2 insertions, 7 deletions
diff --git a/arch/arm/mm/proc-xscale.S b/arch/arm/mm/proc-xscale.S
index 906e9de..cc1004b 100644
--- a/arch/arm/mm/proc-xscale.S
+++ b/arch/arm/mm/proc-xscale.S
@@ -491,12 +491,7 @@ __xscale_setup:
mcr p15, 0, ip, c7, c7, 0 @ invalidate I, D caches & BTB
mcr p15, 0, ip, c7, c10, 4 @ Drain Write (& Fill) Buffer
mcr p15, 0, ip, c8, c7, 0 @ invalidate I, D TLBs
-#ifdef CONFIG_IWMMXT
- mov r0, #0 @ initially disallow access to CP0/CP1
-#else
- mov r0, #1 @ Allow access to CP0
-#endif
- orr r0, r0, #1 << 6 @ cp6 for IOP3xx and Bulverde
+ mov r0, #1 << 6 @ cp6 for IOP3xx and Bulverde
orr r0, r0, #1 << 13 @ Its undefined whether this
mcr p15, 0, r0, c15, c1, 0 @ affects USR or SVC modes
@@ -909,7 +904,7 @@ __pxa270_proc_info:
b __xscale_setup
.long cpu_arch_name
.long cpu_elf_name
- .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_IWMMXT
+ .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP
.long cpu_pxa270_name
.long xscale_processor_functions
.long v4wbi_tlb_fns
OpenPOWER on IntegriCloud