ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

PATCH New Paul Walmsley 5 participants 9 messages Oct 13, 2012 – Oct 16, 2012

Subsystems (2)

Arm (32-bit) Arm/vfp support

lore

Share & tools

lore

Paul Walmsley

author

2012-10-13 04:46 UTC #0 lore raw

PATCH 1/1 ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig:

[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8

It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so the kernel dies with an undefined instruction exception. The kernel didn't crash before commit 846a136 because the save and restore code only touched d0-d15, present on all VFP.

Fix to save and restore the d16-d31 registers only if they are present.

Signed-off-by Paul Walmsley <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Russell King <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Dave Martin <[email protected]>

---
 arch/arm/include/asm/vfp.h       |    6 ++++++
 arch/arm/include/asm/vfpmacros.h |    8 ++++----
 arch/arm/vfp/vfpmodule.c         |   10 ++++++++++
 3 files changed, 20 insertions(+), 4 deletions(-)

arch/arm/include/asm/vfp.h +6 -0

index f4ab34f..5689798 100644
@@ -82,3 +82,9 @@
 #define VFPOPDESC_UNUSED_BIT	(24)
 #define VFPOPDESC_UNUSED_MASK	(0xFF << VFPOPDESC_UNUSED_BIT)
 #define VFPOPDESC_OPDESC_MASK	(~(VFPOPDESC_LENGTH_MASK | VFPOPDESC_UNUSED_MASK))
+
+#ifndef __ASSEMBLER__
+#include <linux/types.h>
+
+extern u32 vfp_has_d16_d31;
+#endif

arch/arm/include/asm/vfpmacros.h +4 -4

index 6a6f1e4..11496a9 100644
@@ -25,9 +25,9 @@
 #endif
 #ifdef CONFIG_VFPv3
 #if __LINUX_ARM_ARCH__ <= 6
-	ldr	\tmp, =elf_hwcap		    @ may not have MVFR regs
+	ldr	\tmp, =vfp_has_d16_d31		    @ have VFP regs d16-d31?
 	ldr	\tmp, [\tmp, #0]
-	tst	\tmp, #HWCAP_VFPv3D16
+	cmp	\tmp, #1
 	ldceql	p11, cr0, [\base],#32*4		    @ FLDMIAD \base!, {d16-d31}
 	addne	\base, \base, #32*4		    @ step over unused register space
 #else

@@ -49,9 +49,9 @@
 #endif
 #ifdef CONFIG_VFPv3
 #if __LINUX_ARM_ARCH__ <= 6
-	ldr	\tmp, =elf_hwcap		    @ may not have MVFR regs
+	ldr	\tmp, =vfp_has_d16_d31		    @ have VFP regs d16-d31?
 	ldr	\tmp, [\tmp, #0]
-	tst	\tmp, #HWCAP_VFPv3D16
+	cmp	\tmp, #1
 	stceql	p11, cr0, [\base],#32*4		    @ FSTMIAD \base!, {d16-d31}
 	addne	\base, \base, #32*4		    @ step over unused register space
 #else

arch/arm/vfp/vfpmodule.c +10 -0

index c834b32..929b53b 100644
@@ -58,6 +58,12 @@ unsigned int VFP_arch;
 union vfp_state *vfp_current_hw_state[NR_CPUS];
 
 /*
+ * If the VFP on this ARM core has registers d16-d31, vfp_has_d16_d31 will
+ * be set to 1; otherwise, 0.  Only valid after startup.
+ */
+u32 vfp_has_d16_d31;
+
+/*
  * Is 'thread's most up to date state stored in this CPUs hardware?
  * Must be called from non-preemptible context.
  */

@@ -691,6 +697,8 @@ static int __init vfp_init(void)
 		thread_register_notifier(&vfp_notifier_block);
 		vfp_pm_init();
 
+		vfp_has_d16_d31 = 0;
+
 		/*
 		 * We detected VFP, and the support code is
 		 * in place; report VFP support to userspace.

@@ -706,6 +714,8 @@ static int __init vfp_init(void)
 			 */
 			if (((fmrx(MVFR0) & MVFR0_A_SIMD_MASK)) == 1)
 				elf_hwcap |= HWCAP_VFPv3D16;
+			else
+				vfp_has_d16_d31 = 1;
 		}
 #endif
 		/*

Signature · 1 line

1.7.10.4

Russell King - ARM Linux

2012-10-13 09:02 UTC #1 lore raw

PATCH 1/1 ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

Quoted 22 lines · Paul Walmsley

After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig:
[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8
It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so the kernel dies with an undefined instruction exception. The kernel didn't crash before commit 846a136 because the save and restore code only touched d0-d15, present on all VFP.

Quoted 2 lines

Fix to save and restore the d16-d31 registers only if they are present.

No. VFPv3D16 HWCAP means that the VFP supports just 16 double registers
- and it communicates this information to userspace. If this bit is clear, and the VFP only has 16 double registers, then _that_ is a bug.

Måns Rullgård

2012-10-13 10:50 UTC #2 lore raw

PATCH 1/1 ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

Quoted 23 lines · Russell King - ARM Linux

Quoted 22 lines · Paul Walmsley
After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig:
[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8
It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so the kernel dies with an undefined instruction exception. The kernel didn't crash before commit 846a136 because the save and restore code only touched d0-d15, present on all VFP.

Quoted 6 lines

Quoted 2 lines
Fix to save and restore the d16-d31 registers only if they are present.
No. VFPv3D16 HWCAP means that the VFP supports just 16 double registers
- and it communicates this information to userspace. If this bit is clear, and the VFP only has 16 double registers, then _that_ is a bug.

That bit will be clear on VFPv2 (because it's not v3), and this has only 16 D registers. The high D registers are present if (vfpv3 && !vfpv3d16). Pre-calculating this to avoid doing it in the context save/restore code is probably a good idea.

Signature · 2 lines

M?ns Rullg?rd
mans at mansr.com

Russell King - ARM Linux

2012-10-13 13:36 UTC #3 lore raw

PATCH 1/1 ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

Quoted 28 lines · M?ns Rullg?rd

Quoted 26 lines · Russell King - ARM Linux
Quoted 24 lines · Paul Walmsley
After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig:
[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8
It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so the kernel dies with an undefined instruction exception. The kernel didn't crash before commit 846a136 because the save and restore code only touched d0-d15, present on all VFP.
Fix to save and restore the d16-d31 registers only if they are present.

Quoted 8 lines

Quoted 3 lines
No. VFPv3D16 HWCAP means that the VFP supports just 16 double registers
- and it communicates this information to userspace. If this bit is clear, and the VFP only has 16 double registers, then _that_ is a bug.
That bit will be clear on VFPv2 (because it's not v3), and this has only 16 D registers. The high D registers are present if (vfpv3 && !vfpv3d16). Pre-calculating this to avoid doing it in the context save/restore code is probably a good idea.

No. What we should do in that case is get away from this mixed logic. The HWCAP fields should _always_ be telling us what we have, not what we don't have. So, this means we should have VFPv3 and VFPv4 bits, but also VFPD16 to say "yes, we have d16-d31 registers too".

And, these bits should be set as follows:

	VFP architecture	flags
	VFPv2			VFP
	VFPv3d16		VFP|VFPv3|VFPv3D16
	VFPv3			VFP|VFPv3|VFPD16
	VFPv4			VFP|VFPv3|VFPv4|VFPD16

whereas, at the present time we have the silly situation where VFPv3D16 gives us two bits of information. Note that the above combination sorts this out for ever, and doesn't involve any userspace changes, and makes this stuff much more sane - and ends up giving everyone exactly what they need to make the appropriate decisions.

Paul Walmsley

author

2012-10-15 01:58 UTC #4 lore raw

PATCH 1/1 ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig:

[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8

It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so this results in an undefined instruction exception. The code didn't crash before commit 846a136 because the save and restore code was only touching d0-d15, present on all VFP.

Fix by implementing a request from Russell King to add a new HWCAP flag that affirmatively indicates the presence of the d16-d31 registers:

http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2

Signed-off-by Paul Walmsley <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Russell King <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Dave Martin <[email protected]>

Cc M?ns Rullg?rd <[email protected]>

---
Applies on v3.7-rc1.

 arch/arm/include/asm/vfpmacros.h  |   12 ++++++------
 arch/arm/include/uapi/asm/hwcap.h |    3 ++-
 arch/arm/vfp/vfpmodule.c          |    9 ++++++---
 3 files changed, 14 insertions(+), 10 deletions(-)

arch/arm/include/asm/vfpmacros.h +6 -6

index 6a6f1e4..77f40ea 100644
@@ -27,9 +27,9 @@
 #if __LINUX_ARM_ARCH__ <= 6
 	ldr	\tmp, =elf_hwcap		    @ may not have MVFR regs
 	ldr	\tmp, [\tmp, #0]
-	tst	\tmp, #HWCAP_VFPv3D16
-	ldceql	p11, cr0, [\base],#32*4		    @ FLDMIAD \base!, {d16-d31}
-	addne	\base, \base, #32*4		    @ step over unused register space
+	tst	\tmp, #HWCAP_VFPD16
+	ldcnel	p11, cr0, [\base],#32*4		    @ FLDMIAD \base!, {d16-d31}
+	addeq	\base, \base, #32*4		    @ step over unused register space
 #else
 	VFPFMRX	\tmp, MVFR0			    @ Media and VFP Feature Register 0
 	and	\tmp, \tmp, #MVFR0_A_SIMD_MASK	    @ A_SIMD field

@@ -51,9 +51,9 @@
 #if __LINUX_ARM_ARCH__ <= 6
 	ldr	\tmp, =elf_hwcap		    @ may not have MVFR regs
 	ldr	\tmp, [\tmp, #0]
-	tst	\tmp, #HWCAP_VFPv3D16
-	stceql	p11, cr0, [\base],#32*4		    @ FSTMIAD \base!, {d16-d31}
-	addne	\base, \base, #32*4		    @ step over unused register space
+	tst	\tmp, #HWCAP_VFPD16
+	stcnel	p11, cr0, [\base],#32*4		    @ FSTMIAD \base!, {d16-d31}
+	addeq	\base, \base, #32*4		    @ step over unused register space
 #else
 	VFPFMRX	\tmp, MVFR0			    @ Media and VFP Feature Register 0
 	and	\tmp, \tmp, #MVFR0_A_SIMD_MASK	    @ A_SIMD field

arch/arm/include/uapi/asm/hwcap.h +2 -1

index f254f65..b1555d0 100644
@@ -18,11 +18,12 @@
 #define HWCAP_THUMBEE	(1 << 11)
 #define HWCAP_NEON	(1 << 12)
 #define HWCAP_VFPv3	(1 << 13)
-#define HWCAP_VFPv3D16	(1 << 14)
+#define HWCAP_VFPv3D16	(1 << 14)	/* also set for VFPv4-D16 */
 #define HWCAP_TLS	(1 << 15)
 #define HWCAP_VFPv4	(1 << 16)
 #define HWCAP_IDIVA	(1 << 17)
 #define HWCAP_IDIVT	(1 << 18)
+#define HWCAP_VFPD16	(1 << 19)	/* set if VFP has 32 regs (not 16) */
 #define HWCAP_IDIV	(HWCAP_IDIVA | HWCAP_IDIVT)

arch/arm/vfp/vfpmodule.c +6 -3

index c834b32..f3e611c 100644
@@ -701,11 +701,14 @@ static int __init vfp_init(void)
 			elf_hwcap |= HWCAP_VFPv3;
 
 			/*
-			 * Check for VFPv3 D16. CPUs in this configuration
-			 * only have 16 x 64bit registers.
+			 * Check for VFPv3 D16 and VFPv4 D16.  CPUs in
+			 * this configuration only have 16 x 64bit
+			 * registers.
 			 */
 			if (((fmrx(MVFR0) & MVFR0_A_SIMD_MASK)) == 1)
-				elf_hwcap |= HWCAP_VFPv3D16;
+				elf_hwcap |= HWCAP_VFPv3D16; /* also v4-D16 */
+			else
+				elf_hwcap |= HWCAP_VFPD16;
 		}
 #endif
 		/*

Signature · 1 line

1.7.10.4

Mans Rullgard

2012-10-15 02:39 UTC #5 lore raw

PATCH 1/1 ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

Quoted 4 lines · Paul Walmsley

Fix by implementing a request from Russell King to add a new HWCAP flag that affirmatively indicates the presence of the d16-d31 registers:

[...]

Quoted 6 lines

arch/arm/include/uapi/asm/hwcap.h +0 -0

index f254f65..b1555d0 100644
@@ -18,11 +18,12 @@
 #define HWCAP_THUMBEE  (1 << 11)

arch/arm/include/uapi/asm/hwcap.h line 27

Quoted 10 lines

arch/arm/include/uapi/asm/hwcap.h +2 -1

 #define HWCAP_NEON     (1 << 12)
 #define HWCAP_VFPv3    (1 << 13)
-#define HWCAP_VFPv3D16 (1 << 14)
+#define HWCAP_VFPv3D16 (1 << 14)       /* also set for VFPv4-D16 */
 #define HWCAP_TLS      (1 << 15)
 #define HWCAP_VFPv4    (1 << 16)
 #define HWCAP_IDIVA    (1 << 17)
 #define HWCAP_IDIVT    (1 << 18)
+#define HWCAP_VFPD16   (1 << 19)       /* set if VFP has 32 regs (not 16) */
 #define HWCAP_IDIV     (HWCAP_IDIVA | HWCAP_IDIVT)

Please consider calling the new flag VFPD32 or so instead. The D16 suffix usually signifies an implementation with 16 registers, i.e. the opposite of what this flag does. Using the same tag to mean both things depending on whether there's a 'v3' before it is nothing but confusing.

Signature · 1 line

Mans Rullgard / mru

Paul Walmsley

author

2012-10-15 05:24 UTC #6 lore raw

PATCH v3 1/1 ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig:

[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8

It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so this results in an undefined instruction exception. The code didn't crash before commit 846a136 because the save and restore code was only touching d0-d15, present on all VFP.

Fix by implementing a request from Russell King to add a new HWCAP flag that affirmatively indicates the presence of the d16-d31 registers:

http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2

and some feedback from M?ns to clarify the name of the HWCAP flag.

Signed-off-by Paul Walmsley <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Russell King <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Dave Martin <[email protected]>

Cc M?ns Rullg?rd <[email protected]>

---
Thanks for the suggestion, M?ns; certainly a readability improvement.

 arch/arm/include/asm/vfpmacros.h  |   12 ++++++------
 arch/arm/include/uapi/asm/hwcap.h |    3 ++-
 arch/arm/vfp/vfpmodule.c          |    9 ++++++---
 3 files changed, 14 insertions(+), 10 deletions(-)

arch/arm/include/asm/vfpmacros.h +6 -6

index 6a6f1e4..301c1db 100644
@@ -27,9 +27,9 @@
 #if __LINUX_ARM_ARCH__ <= 6
 	ldr	\tmp, =elf_hwcap		    @ may not have MVFR regs
 	ldr	\tmp, [\tmp, #0]
-	tst	\tmp, #HWCAP_VFPv3D16
-	ldceql	p11, cr0, [\base],#32*4		    @ FLDMIAD \base!, {d16-d31}
-	addne	\base, \base, #32*4		    @ step over unused register space
+	tst	\tmp, #HWCAP_VFPD32
+	ldcnel	p11, cr0, [\base],#32*4		    @ FLDMIAD \base!, {d16-d31}
+	addeq	\base, \base, #32*4		    @ step over unused register space
 #else
 	VFPFMRX	\tmp, MVFR0			    @ Media and VFP Feature Register 0
 	and	\tmp, \tmp, #MVFR0_A_SIMD_MASK	    @ A_SIMD field

@@ -51,9 +51,9 @@
 #if __LINUX_ARM_ARCH__ <= 6
 	ldr	\tmp, =elf_hwcap		    @ may not have MVFR regs
 	ldr	\tmp, [\tmp, #0]
-	tst	\tmp, #HWCAP_VFPv3D16
-	stceql	p11, cr0, [\base],#32*4		    @ FSTMIAD \base!, {d16-d31}
-	addne	\base, \base, #32*4		    @ step over unused register space
+	tst	\tmp, #HWCAP_VFPD32
+	stcnel	p11, cr0, [\base],#32*4		    @ FSTMIAD \base!, {d16-d31}
+	addeq	\base, \base, #32*4		    @ step over unused register space
 #else
 	VFPFMRX	\tmp, MVFR0			    @ Media and VFP Feature Register 0
 	and	\tmp, \tmp, #MVFR0_A_SIMD_MASK	    @ A_SIMD field

arch/arm/include/uapi/asm/hwcap.h +2 -1

index f254f65..3688fd1 100644
@@ -18,11 +18,12 @@
 #define HWCAP_THUMBEE	(1 << 11)
 #define HWCAP_NEON	(1 << 12)
 #define HWCAP_VFPv3	(1 << 13)
-#define HWCAP_VFPv3D16	(1 << 14)
+#define HWCAP_VFPv3D16	(1 << 14)	/* also set for VFPv4-D16 */
 #define HWCAP_TLS	(1 << 15)
 #define HWCAP_VFPv4	(1 << 16)
 #define HWCAP_IDIVA	(1 << 17)
 #define HWCAP_IDIVT	(1 << 18)
+#define HWCAP_VFPD32	(1 << 19)	/* set if VFP has 32 regs (not 16) */
 #define HWCAP_IDIV	(HWCAP_IDIVA | HWCAP_IDIVT)

arch/arm/vfp/vfpmodule.c +6 -3

index c834b32..3b44e0d 100644
@@ -701,11 +701,14 @@ static int __init vfp_init(void)
 			elf_hwcap |= HWCAP_VFPv3;
 
 			/*
-			 * Check for VFPv3 D16. CPUs in this configuration
-			 * only have 16 x 64bit registers.
+			 * Check for VFPv3 D16 and VFPv4 D16.  CPUs in
+			 * this configuration only have 16 x 64bit
+			 * registers.
 			 */
 			if (((fmrx(MVFR0) & MVFR0_A_SIMD_MASK)) == 1)
-				elf_hwcap |= HWCAP_VFPv3D16;
+				elf_hwcap |= HWCAP_VFPv3D16; /* also v4-D16 */
+			else
+				elf_hwcap |= HWCAP_VFPD32;
 		}
 #endif
 		/*

Signature · 1 line

1.7.10.4

Tony Lindgren

2012-10-15 17:53 UTC #7 lore raw

PATCH v3 1/1 ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

Quoted 28 lines · Paul Walmsley

After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig:
[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8
It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so this results in an undefined instruction exception. The code didn't crash before commit 846a136 because the save and restore code was only touching d0-d15, present on all VFP.
Fix by implementing a request from Russell King to add a new HWCAP flag that affirmatively indicates the presence of the d16-d31 registers:
   http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2

Quoted 8 lines

and some feedback from M?ns to clarify the name of the HWCAP flag.
Signed-off-by Paul Walmsley <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Russell King <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Dave Martin <[email protected]>
Cc M?ns Rullg?rd <[email protected]>

This fixes the error above on my 2430sdp:

Tested-by Tony Lindgren <[email protected]>

Jon Hunter

2012-10-16 17:13 UTC #8 lore raw

PATCH v3 1/1 ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

Quoted 38 lines · Tony Lindgren

Quoted 28 lines · Paul Walmsley
After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig:
[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8
It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so this results in an undefined instruction exception. The code didn't crash before commit 846a136 because the save and restore code was only touching d0-d15, present on all VFP.
Fix by implementing a request from Russell King to add a new HWCAP flag that affirmatively indicates the presence of the d16-d31 registers:
   http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2
Quoted 8 lines
and some feedback from M?ns to clarify the name of the HWCAP flag.
Signed-off-by Paul Walmsley <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Russell King <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Dave Martin <[email protected]>
Cc M?ns Rullg?rd <[email protected]>

Quoted 3 lines

This fixes the error above on my 2430sdp:
Tested-by Tony Lindgren <[email protected]>

Fixes same error on 2420 H4.

Tested-by Jon Hunter <[email protected]>

Cheers
Jon