Thread (19 messages) 19 messages, 3 authors, 2011-06-08
DORMANTno replies

[PATCH 06/11] ARM: cortex-a5: add HWCAP_VFPv4D16 to proc info structure

From: Will Deacon <hidden>
Date: 2011-06-08 09:24:39

On Wed, Jun 08, 2011 at 10:05:01AM +0100, Dave Martin wrote:
On Tue, Jun 07, 2011 at 05:22:04PM +0100, Will Deacon wrote:
quoted
On Tue, Jun 07, 2011 at 05:17:36PM +0100, Dave Martin wrote:
quoted
On Mon, Jun 06, 2011 at 05:55:50PM +0100, Will Deacon wrote:
quoted
The Cortex-A5 implements VFPv4D16, so add this to the hwcaps for this
processor.

Signed-off-by: Will Deacon <redacted>
---
 arch/arm/mm/proc-v7.S |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index b22d98d..8eba506 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -466,7 +466,7 @@ cpu_elf_name:
 __v7_ca5mp_proc_info:
 	.long	0x410fc050
 	.long	0xff0ffff0
-	__v7_proc __v7_ca5mp_setup
+	__v7_proc __v7_ca5mp_setup, HWCAP_VFPv4D16
Is VFPv4 a superset of VFPv3?  If so, should we also include
HWCAP_VFPv3D16 (and what about HWCAP_VFP)?
Actually, it looks like this shouldn't be declared statically at all, since the
kernel have not have VFP support compiled in. Rather, the vfp code will detect
the capability and adjust elf_hwcap at runtime.
Hah, yes, quite right.  My bad.
I'll fix it for v2.

As for the D16 stuff, I've had a better idea [need to check with the tools
guys]. Rather than waste two bits for VFPv4 and VFPv4D16, it should probably
be something like:

VFPv3    : HWCAP_VFPv3
VFPv3D16 : HWCAP_VFPv3 | HWCAP_VFPv3D16
VFPv4    : HWCAP_VFPv3 | HWCAP_VFPv4
VFPv4D16 : HWCAP_VFPv3 | HWCAP_VFPv3D16 | HWCAP_VFPv4

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help