aboutsummaryrefslogtreecommitdiff
path: root/arch
diff options
context:
space:
mode:
authorCatalin Marinas <catalin.marinas@arm.com>2008-01-10 19:16:17 +0100
committerRussell King <rmk+kernel@arm.linux.org.uk>2008-01-26 14:44:02 +0000
commitb5872db4a2ebe7dbc7a5e4013ae8ee37f3de3b97 (patch)
treeeab14c59c2b068868a5f53a56eb149fc1f902b13 /arch
parent25ebee020bd34d1f4c5678538204f0b10bf9f6d5 (diff)
[ARM] 4584/2: ARMv7: Add Advanced SIMD (NEON) extension support
This patch enables the use of the Advanced SIMD (NEON) extension on ARMv7. The NEON technology is a 64/128-bit hybrid SIMD architecture for accelerating the performance of multimedia and signal processing applications. The extension shares the registers with the VFP unit and enabling/disabling and saving/restoring follow the same rules. In addition, there are instructions that do not have the appropriate CP number encoded, the checks being made in the call_fpe function. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'arch')
-rw-r--r--arch/arm/Kconfig7
-rw-r--r--arch/arm/kernel/entry-armv.S38
2 files changed, 45 insertions, 0 deletions
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f4eeb03bc6a..709f9d383c8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -966,6 +966,13 @@ config VFPv3
depends on VFP
default y if CPU_V7
+config NEON
+ bool "Advanced SIMD (NEON) Extension support"
+ depends on VFPv3 && CPU_V7
+ help
+ Say Y to include support code for NEON, the ARMv7 Advanced SIMD
+ Extension.
+
endmenu
menu "Userspace binary formats"
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 29dec080a60..8de21f51e48 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -480,6 +480,13 @@ __und_usr:
* co-processor instructions. However, we have to watch out
* for the ARM6/ARM7 SWI bug.
*
+ * NEON is a special case that has to be handled here. Not all
+ * NEON instructions are co-processor instructions, so we have
+ * to make a special case of checking for them. Plus, there's
+ * five groups of them, so we have a table of mask/opcode pairs
+ * to check against, and if any match then we branch off into the
+ * NEON handler code.
+ *
* Emulators may wish to make use of the following registers:
* r0 = instruction opcode.
* r2 = PC+4
@@ -488,6 +495,23 @@ __und_usr:
* lr = unrecognised instruction return address
*/
call_fpe:
+#ifdef CONFIG_NEON
+ adr r6, .LCneon_opcodes
+2:
+ ldr r7, [r6], #4 @ mask value
+ cmp r7, #0 @ end mask?
+ beq 1f
+ and r8, r0, r7
+ ldr r7, [r6], #4 @ opcode bits matching in mask
+ cmp r8, r7 @ NEON instruction?
+ bne 2b
+ get_thread_info r10
+ mov r7, #1
+ strb r7, [r10, #TI_USED_CP + 10] @ mark CP#10 as used
+ strb r7, [r10, #TI_USED_CP + 11] @ mark CP#11 as used
+ b do_vfp @ let VFP handler handle this
+1:
+#endif
tst r0, #0x08000000 @ only CDP/CPRT/LDC/STC have bit 27
#if defined(CONFIG_CPU_ARM610) || defined(CONFIG_CPU_ARM710)
and r8, r0, #0x0f000000 @ mask out op-code bits
@@ -537,6 +561,20 @@ call_fpe:
mov pc, lr @ CP#14 (Debug)
mov pc, lr @ CP#15 (Control)
+#ifdef CONFIG_NEON
+ .align 6
+
+.LCneon_opcodes:
+ .word 0xfe000000 @ mask
+ .word 0xf2000000 @ opcode
+
+ .word 0xff100000 @ mask
+ .word 0xf4000000 @ opcode
+
+ .word 0x00000000 @ mask
+ .word 0x00000000 @ opcode
+#endif
+
do_fpe:
enable_irq
ldr r4, .LCfp