kernel.git/arch/arm/vfp, branch linux-3.15.y

ARM: 8026/1: Fix emulation of multiply accumulate instructions

2014-04-14T22:28:24Z

The emulation for single and double precision multiply accumulate instructions correctly normalised any denormal values in the operand registers, but failed to normalise the destination (accumulator) register. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=70501 Signed-off-by: Jay Foad Signed-off-by: Russell King

ARM: 8018/1: Add {inc,dec}_preempt_count asm macros

2014-04-09T12:08:08Z

The patch adds asm macros for inc_preempt_count and dec_preempt_count_ti (which also gets the current thread_info) instead of open-coding them in arch/arm/vfp/*.S files. Signed-off-by: Catalin Marinas Tested-by: Arun KS Signed-off-by: Russell King

ARM: 8017/1: Move asm macro get_thread_info to asm/assembler.h

2014-04-09T12:08:07Z

asm/assembler.h is a better place for this macro since it is used by asm files outside arch/arm/kernel/ Signed-off-by: Catalin Marinas Tested-by: Arun KS Signed-off-by: Russell King

ARM: 7873/1: vfp: clear vfp_current_hw_state for dying cpu

2013-10-30T22:10:10Z

The CPU_DYING notifier is called by cpu stopper task which does not own the context held in the VFP hardware. Calling vfp_force_reload() has no effect. Replace it with clearing vfp_current_hw_state. Signed-off-by: Yuanyuan Zhong Signed-off-by: Russell King

ARM: add support for kernel mode NEON

2013-07-08T21:08:51Z

In order to safely support the use of NEON instructions in kernel mode, some precautions need to be taken: - the userland context that may be present in the registers (even if the NEON/VFP is currently disabled) must be stored under the correct task (which may not be 'current' in the UP case), - to avoid having to keep track of additional vfpstates for the kernel side, disallow the use of NEON in interrupt context and run with preemption disabled, - after use, re-enable preemption and re-enable the lazy restore machinery by disabling the NEON/VFP unit. This patch adds the functions kernel_neon_begin() and kernel_neon_end() which take care of the above. It also adds the Kconfig symbol KERNEL_MODE_NEON to enable it. Signed-off-by: Ard Biesheuvel Acked-by: Nicolas Pitre

ARM: be strict about FP exceptions in kernel mode

2013-07-08T21:07:38Z

The support code in vfp_support_entry does not care whether the exception that caused it to be invoked occurred in kernel mode or in user mode. However, neither condition that could trigger this exception (lazy restore and VFP bounce to support code) is currently allowable in kernel mode. In either case, print a message describing the condition before letting the undefined instruction handler run its course and trigger an oops. Signed-off-by: Ard Biesheuvel Acked-by: Nicolas Pitre

ARM: move VFP init to an earlier boot stage

2013-07-08T17:22:19Z

In order to use the NEON unit in the kernel, we should initialize it a bit earlier in the boot process so NEON users that like to do a quick benchmark at load time (like the xor_blocks or RAID-6 code) find the NEON/VFP unit already enabled. Replaced late_initcall() with core_initcall(). Signed-off-by: Ard Biesheuvel Acked-by: Nicolas Pitre

ARM: 7729/1: vfp: ensure VFP_arch is non-zero when VFP is not supported

2013-05-22T21:01:37Z

Commit d3f79584a8b5 ("ARM: cleanup undefined instruction entry code") improved the register scheduling when handling undefined instructions. A side effect of this is that r5 is now used as a temporary, whilst the VFP probing code relies on r5 containing a non-zero value when VFP is not supported. This patch fixes the VFP detection code so that we don't rely on the contents of r5. Without this patch, Linux dies loudly on CPUs without VFP support. Signed-off-by: Will Deacon Signed-off-by: Russell King

ARM: Fix broken commit 0cc41e4a21d43 corrupting kernel messages

2013-03-01T21:09:59Z

Commit 0cc41e4a21d43 (arch: remove direct definitions of KERN_ uses) is broken - not enough thought was put into changing: .asciz "string" to .asciz "string1" "string2" The problem is that each string gets _separately_ NUL terminated, so the result is a string containing: "string1\0string2\0" rather than: "string1string2\0" With our new printk levels, this ends up as - eg, KERN_DEBUG "string": 0x01 0x00 0x07 0x00 "string" 0x00 which produces lots of \x01 in the kernel log. Signed-off-by: Russell King

ARM: VFP: fix emulation of second VFP instruction

2013-02-25T16:09:12Z

Martin Storsjö reports that the sequence: ee312ac1 vsub.f32 s4, s3, s2 ee702ac0 vsub.f32 s5, s1, s0 e59f0028 ldr r0, [pc, #40] ee111a90 vmov r1, s3 on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5) where s3 is a denormal and s2 is zero results in incorrect behaviour - the instruction "vsub.f32 s5, s1, s0" is not executed: VFP: bounce: trigger ee111a90 fpexc d0000780 VFP: emulate: INST=0xee312ac1 SCR=0x00000000 ... As we can see, the instruction triggering the exception is the "vmov" instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to properly take account of the FPEXC_FP2V flag in FPEXC. This is because the test for the second instruction register being valid is bogus, and will always skip emulation of the second instruction. Cc: Reported-by: Martin Storsjö Tested-by: Martin Storsjö Signed-off-by: Russell King