From: Tony Lindgren <tony@atomide.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] arm: Make VFPv3 usable on ARMv6
Date: Wed, 23 Jun 2010 10:57:03 +0300 [thread overview]
Message-ID: <20100623075703.GB12255@atomide.com> (raw)
In-Reply-To: <20100622132037.GV12255@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]
* Tony Lindgren <tony@atomide.com> [100622 16:15]:
> * Catalin Marinas <catalin.marinas@arm.com> [100622 15:53]:
> > On Mon, 2010-06-21 at 14:51 +0100, Tony Lindgren wrote:
> > > diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
> > > index 315a540..19ba626 100644
> > > --- a/arch/arm/vfp/vfpmodule.c
> > > +++ b/arch/arm/vfp/vfpmodule.c
> > > @@ -549,10 +549,14 @@ static int __init vfp_init(void)
> > > /*
> > > * Check for the presence of the Advanced SIMD
> > > * load/store instructions, integer and single
> > > - * precision floating point operations.
> > > + * precision floating point operations. Only check
> > > + * for NEON if the hardware has TLS register as the
> > > + * MVFR registers got added in ARM1136 r1p0 with TLS.
> > > */
> > > - if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
> > > - elf_hwcap |= HWCAP_NEON;
> > > + if (elf_hwcap & HWCAP_TLS) {
> > > + if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
> > > + elf_hwcap |= HWCAP_NEON;
> > > + }
> >
> > MVFR should be available with the new CPU id format:
> >
> > ((read_cpuid_id() & 0x000f0000) == 0x000f0000)
> >
> > I think that would be a cleaner test than relying on the TLS presence.
>
> OK, thanks that's better. Will update accordingly and repost.
Here's this one updated. Using your better MVFR check also removes the
dependency to the previous patch.
Regards,
Tony
[-- Attachment #2: vfpv3-armv6-fix.patch --]
[-- Type: text/x-diff, Size: 3323 bytes --]
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 21 Jun 2010 16:33:28 +0300
Subject: [PATCH] arm: Make VFPv3 usable on ARMv6
MVFR0 and MVFR1 are only available starting with ARM1136 r1p0 release
according to "B.5 VFP changes" in DDI0211F_arm1136_r1p0_trm.pdf. This is
also when TLS register got added, so we can use HAS_TLS also to test for
MVFR0 and MVFR1.
Otherwise VFPFMRX and VFPFMXR access fails and we get:
Internal error: Oops - undefined instruction: 0 [#1]
PC is at no_old_VFP_process+0x8/0x3c
LR is at __und_svc+0x48/0x80
...
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
index 422f3cc..3d5fc41 100644
--- a/arch/arm/include/asm/vfpmacros.h
+++ b/arch/arm/include/asm/vfpmacros.h
@@ -3,6 +3,8 @@
*
* Assembler-only file containing VFP macros and register definitions.
*/
+#include <asm/hwcap.h>
+
#include "vfp.h"
@ Macros to allow building with old toolkits (with no VFP support)
@@ -22,12 +24,20 @@
LDC p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d0-d15}
#endif
#ifdef CONFIG_VFPv3
+#if __LINUX_ARM_ARCH__ <= 6
+ ldr \tmp, =elf_hwcap @ may not have MVFR regs
+ ldr \tmp, [\tmp, #0]
+ tst \tmp, #HWCAP_VFPv3D16
+ ldceq p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
+ addne \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
cmp \tmp, #2 @ 32 x 64bit registers?
ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
addne \base, \base, #32*4 @ step over unused register space
#endif
+#endif
.endm
@ write all the working registers out of the VFP
@@ -38,10 +48,18 @@
STC p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d0-d15}
#endif
#ifdef CONFIG_VFPv3
+#if __LINUX_ARM_ARCH__ <= 6
+ ldr \tmp, =elf_hwcap @ may not have MVFR regs
+ ldr \tmp, [\tmp, #0]
+ tst \tmp, #HWCAP_VFPv3D16
+ stceq p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
+ addne \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
cmp \tmp, #2 @ 32 x 64bit registers?
stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
addne \base, \base, #32*4 @ step over unused register space
#endif
+#endif
.endm
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 315a540..8063a32 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -15,6 +15,7 @@
#include <linux/sched.h>
#include <linux/init.h>
+#include <asm/cputype.h>
#include <asm/thread_notify.h>
#include <asm/vfp.h>
@@ -549,10 +550,13 @@ static int __init vfp_init(void)
/*
* Check for the presence of the Advanced SIMD
* load/store instructions, integer and single
- * precision floating point operations.
+ * precision floating point operations. Only check
+ * for NEON if the hardware has the MVFR registers.
*/
- if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
- elf_hwcap |= HWCAP_NEON;
+ if ((read_cpuid_id() & 0x000f0000) == 0x000f0000) {
+ if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
+ elf_hwcap |= HWCAP_NEON;
+ }
#endif
}
return 0;
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm: Make VFPv3 usable on ARMv6
Date: Wed, 23 Jun 2010 10:57:03 +0300 [thread overview]
Message-ID: <20100623075703.GB12255@atomide.com> (raw)
In-Reply-To: <20100622132037.GV12255@atomide.com>
* Tony Lindgren <tony@atomide.com> [100622 16:15]:
> * Catalin Marinas <catalin.marinas@arm.com> [100622 15:53]:
> > On Mon, 2010-06-21 at 14:51 +0100, Tony Lindgren wrote:
> > > diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
> > > index 315a540..19ba626 100644
> > > --- a/arch/arm/vfp/vfpmodule.c
> > > +++ b/arch/arm/vfp/vfpmodule.c
> > > @@ -549,10 +549,14 @@ static int __init vfp_init(void)
> > > /*
> > > * Check for the presence of the Advanced SIMD
> > > * load/store instructions, integer and single
> > > - * precision floating point operations.
> > > + * precision floating point operations. Only check
> > > + * for NEON if the hardware has TLS register as the
> > > + * MVFR registers got added in ARM1136 r1p0 with TLS.
> > > */
> > > - if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
> > > - elf_hwcap |= HWCAP_NEON;
> > > + if (elf_hwcap & HWCAP_TLS) {
> > > + if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
> > > + elf_hwcap |= HWCAP_NEON;
> > > + }
> >
> > MVFR should be available with the new CPU id format:
> >
> > ((read_cpuid_id() & 0x000f0000) == 0x000f0000)
> >
> > I think that would be a cleaner test than relying on the TLS presence.
>
> OK, thanks that's better. Will update accordingly and repost.
Here's this one updated. Using your better MVFR check also removes the
dependency to the previous patch.
Regards,
Tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vfpv3-armv6-fix.patch
Type: text/x-diff
Size: 3323 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100623/75317dfe/attachment.bin>
next prev parent reply other threads:[~2010-06-23 7:56 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-21 13:51 [PATCH 0/2] Make ARMv6 behave with TLS, VFPv3, and NEON Tony Lindgren
2010-06-21 13:51 ` Tony Lindgren
2010-06-21 13:51 ` [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6 Tony Lindgren
2010-06-21 13:51 ` Tony Lindgren
2010-06-22 9:28 ` Tony Lindgren
2010-06-22 9:28 ` Tony Lindgren
2010-06-22 17:00 ` Jamie Lokier
2010-06-22 17:00 ` Jamie Lokier
2010-06-23 7:39 ` Tony Lindgren
2010-06-23 7:39 ` Tony Lindgren
2010-06-23 8:12 ` Russell King - ARM Linux
2010-06-23 8:12 ` Russell King - ARM Linux
2010-06-23 9:28 ` Tony Lindgren
2010-06-23 9:28 ` Tony Lindgren
2010-06-23 9:32 ` Russell King - ARM Linux
2010-06-23 9:32 ` Russell King - ARM Linux
2010-06-23 13:28 ` Jamie Lokier
2010-06-23 13:28 ` Jamie Lokier
2010-06-23 13:36 ` Jamie Lokier
2010-06-23 13:36 ` Jamie Lokier
2010-06-23 14:19 ` Nicolas Pitre
2010-06-23 14:19 ` Nicolas Pitre
2010-06-24 0:28 ` Jamie Lokier
2010-06-24 0:28 ` Jamie Lokier
2010-06-29 14:18 ` Tony Lindgren
2010-06-29 14:18 ` Tony Lindgren
2010-06-29 19:20 ` Nicolas Pitre
2010-06-29 19:20 ` Nicolas Pitre
2010-06-30 11:08 ` Tony Lindgren
2010-06-30 11:08 ` Tony Lindgren
2010-06-30 13:17 ` Tony Lindgren
2010-06-30 13:17 ` Tony Lindgren
2010-06-30 14:42 ` Nicolas Pitre
2010-06-30 14:42 ` Nicolas Pitre
2010-07-01 9:25 ` Tony Lindgren
2010-07-01 9:25 ` Tony Lindgren
2010-07-01 17:40 ` Jamie Lokier
2010-07-01 17:40 ` Jamie Lokier
2010-07-02 2:37 ` Nicolas Pitre
2010-07-02 2:37 ` Nicolas Pitre
2010-07-02 10:37 ` Tony Lindgren
2010-07-02 10:37 ` Tony Lindgren
2010-07-05 13:55 ` Tony Lindgren
2010-07-05 13:55 ` Tony Lindgren
2011-04-08 3:39 ` Li Li
2011-04-08 3:39 ` Li Li
2011-04-08 13:19 ` Nicolas Pitre
2011-04-08 13:19 ` Nicolas Pitre
2011-04-08 13:35 ` Li Li
2011-04-08 13:35 ` Li Li
2011-04-08 14:35 ` Jamie Lokier
2011-04-08 14:35 ` Jamie Lokier
2011-04-08 14:40 ` Li Li
2011-04-08 14:40 ` Li Li
2010-06-21 13:51 ` [PATCH 2/2] arm: Make VFPv3 usable on ARMv6 Tony Lindgren
2010-06-21 13:51 ` Tony Lindgren
2010-06-22 12:59 ` Catalin Marinas
2010-06-22 12:59 ` Catalin Marinas
2010-06-22 13:20 ` Tony Lindgren
2010-06-22 13:20 ` Tony Lindgren
2010-06-23 7:57 ` Tony Lindgren [this message]
2010-06-23 7:57 ` Tony Lindgren
2010-06-25 13:50 ` Catalin Marinas
2010-06-25 13:50 ` Catalin Marinas
2010-07-01 12:42 ` Tony Lindgren
2010-07-01 12:42 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100623075703.GB12255@atomide.com \
--to=tony@atomide.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.