[PATCH 0/3] Krait VFP fixes

[PATCH 0/3] Krait VFP fixes

[Stephen Boyd]

These changes allow us to support VFP correctly on Krait processors.
They also fix short vector emulation for Cortex-A15 and Krait.

Stepan Moskovchenko (1):
  arm: vfp: Bounce undefined instructions in vectored mode

Stephen Boyd (2):
  ARM: vfp: Workaround bad MVFR1 register on some Kraits
  ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations

 arch/arm/include/asm/cputype.h | 1 +
 arch/arm/include/asm/vfp.h     | 2 +-
 arch/arm/mm/proc-v7.S          | 5 +++--
 arch/arm/vfp/vfphw.S           | 6 ++++++
 arch/arm/vfp/vfpmodule.c       | 7 +++++++
 5 files changed, 18 insertions(+), 3 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 1/3] ARM: vfp: Workaround bad MVFR1 register on some Kraits

[Stephen Boyd]

Certain versions of the Krait processor don't report that they
support the fused multiply accumulate instruction via the MVFR1
register despite the fact that they actually do. Unfortunately we
use this register to identify support for VFPv4. Override the
hwcap on all Krait processors to indicate support for VFPv4 to
workaround this.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm/mm/proc-v7.S | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 3db2c2f04a30..3fd22f79a013 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -547,9 +547,10 @@ __krait_proc_info:
 	/*
 	 * Some Krait processors don't indicate support for SDIV and UDIV
 	 * instructions in the ARM instruction set, even though they actually
-	 * do support them.
+	 * do support them. They also don't indicate support for fused multiply
+	 * instructions even though they actually do support them.
 	 */
-	__v7_proc __v7_setup, hwcaps = HWCAP_IDIV
+	__v7_proc __v7_setup, hwcaps = HWCAP_IDIV | HWCAP_VFPv4
 	.size	__krait_proc_info, . - __krait_proc_info
 
 	/*
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations

[Stephen Boyd]

The subarchitecture field in the fpsid register is 7 bits wide.
The topmost bit is used to designate that the subarchitecture
designer is not ARM. We use this field to determine which VFP
version is supported by the CPU. Since the topmost bit is ignored
with the current mask we detect non-ARM subarchitectures as
supporting only HWCAP_VFP. In Qualcomm's processors (Krait and
Scorpion) it should see that we have HWCAP_VFPv3 but it doesn't.

Use the proper width for the mask and then check to see if the
implementor is 0x51 (Qualcomm). If so, indicate that the vfp
architecture is compatible with VFPv3 architecture or later with
common VFP subarchitecture v3.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm/include/asm/cputype.h | 1 +
 arch/arm/include/asm/vfp.h     | 2 +-
 arch/arm/vfp/vfpmodule.c       | 7 +++++++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 8c2b7321a478..a8329a5fd9b1 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -60,6 +60,7 @@
 	((mpidr >> (MPIDR_LEVEL_BITS * level)) & MPIDR_LEVEL_MASK)
 
 #define ARM_CPU_IMP_ARM			0x41
+#define ARM_CPU_IMP_QCOM		0x51
 #define ARM_CPU_IMP_INTEL		0x69
 
 #define ARM_CPU_PART_ARM1136		0xB360
diff --git a/arch/arm/include/asm/vfp.h b/arch/arm/include/asm/vfp.h
index f4ab34fd4f72..76d3f6907cce 100644
--- a/arch/arm/include/asm/vfp.h
+++ b/arch/arm/include/asm/vfp.h
@@ -21,7 +21,7 @@
 #define FPSID_FORMAT_MASK	(0x3  << FPSID_FORMAT_BIT)
 #define FPSID_NODOUBLE		(1<<20)
 #define FPSID_ARCH_BIT		(16)
-#define FPSID_ARCH_MASK		(0xF  << FPSID_ARCH_BIT)
+#define FPSID_ARCH_MASK		(0x7F  << FPSID_ARCH_BIT)
 #define FPSID_PART_BIT		(8)
 #define FPSID_PART_MASK		(0xFF << FPSID_PART_BIT)
 #define FPSID_VARIANT_BIT	(4)
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 2f37e1d6cb45..e6bd8d99e916 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -746,6 +746,13 @@ static int __init vfp_init(void)
 		hotcpu_notifier(vfp_hotplug, 0);
 
 		VFP_arch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT;  /* Extract the architecture version */
+
+		/*
+		 * Qualcomm implementations are VFPv3 architecture or later
+		 * with common VFP subarchitecture v3
+		 */
+		if (ARM_CPU_IMP_QCOM == ((vfpsid & FPSID_IMPLEMENTER_MASK) >> FPSID_IMPLEMENTER_BIT))
+			VFP_arch = 4;
 		pr_cont("implementor %02x architecture %d part %02x variant %x rev %x\n",
 			(vfpsid & FPSID_IMPLEMENTER_MASK) >> FPSID_IMPLEMENTER_BIT,
 			(vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations

[Russell King - ARM Linux]

On Thu, Sep 18, 2014 at 02:43:11PM -0700, Stephen Boyd wrote:
> diff --git a/arch/arm/include/asm/vfp.h b/arch/arm/include/asm/vfp.h
> index f4ab34fd4f72..76d3f6907cce 100644
> --- a/arch/arm/include/asm/vfp.h
> +++ b/arch/arm/include/asm/vfp.h
> @@ -21,7 +21,7 @@
>  #define FPSID_FORMAT_MASK	(0x3  << FPSID_FORMAT_BIT)
>  #define FPSID_NODOUBLE		(1<<20)
>  #define FPSID_ARCH_BIT		(16)
> -#define FPSID_ARCH_MASK		(0xF  << FPSID_ARCH_BIT)
> +#define FPSID_ARCH_MASK		(0x7F  << FPSID_ARCH_BIT)

This is incorrect.  On VFPv2, the architecture field is four bits long.
As you can see from the above, bit 20 indicates that there are no
double operations provided, and the next two bits indicate the FSTMX/
FLDMX format.

I know that you're changing this to conform with the ARM ARM, but we
have to consider that before VFP was subsumed into the ARM ARM, this
register had the format described as per this file, and these other
bits may be set for an ARM part.  Including these bits in the mask
means that we will mis-identify these older parts as VFPv3.

Welcome to the lack of standardisation!

-- 
FTTC broadband for 0.8mile line: currently@9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations

[Stephen Boyd]

On 09/18/14 15:46, Russell King - ARM Linux wrote:
> On Thu, Sep 18, 2014 at 02:43:11PM -0700, Stephen Boyd wrote:
>> diff --git a/arch/arm/include/asm/vfp.h b/arch/arm/include/asm/vfp.h
>> index f4ab34fd4f72..76d3f6907cce 100644
>> --- a/arch/arm/include/asm/vfp.h
>> +++ b/arch/arm/include/asm/vfp.h
>> @@ -21,7 +21,7 @@
>>  #define FPSID_FORMAT_MASK	(0x3  << FPSID_FORMAT_BIT)
>>  #define FPSID_NODOUBLE		(1<<20)
>>  #define FPSID_ARCH_BIT		(16)
>> -#define FPSID_ARCH_MASK		(0xF  << FPSID_ARCH_BIT)
>> +#define FPSID_ARCH_MASK		(0x7F  << FPSID_ARCH_BIT)
> This is incorrect.  On VFPv2, the architecture field is four bits long.
> As you can see from the above, bit 20 indicates that there are no
> double operations provided, and the next two bits indicate the FSTMX/
> FLDMX format.
>
> I know that you're changing this to conform with the ARM ARM, but we
> have to consider that before VFP was subsumed into the ARM ARM, this
> register had the format described as per this file, and these other
> bits may be set for an ARM part.  Including these bits in the mask
> means that we will mis-identify these older parts as VFPv3.
>
> Welcome to the lack of standardisation!
>

Thank you for the warm welcome! I looked at the TRMs for ARM11 and ARM9.
I can't find anywhere where VFPv2 is supported and these bits are set.

Bits 22-16 of FPSID:

ARM1136r1p5:     0x01
ARM1136r1p3:     0x01
ARM1176:         0x01
ARM11MPCorer2p0: 0x01
ARM11MPCorer1p0: 0x01
ARM1156:         0x01
ARM9:            0x01


Do you, or anyone else, know of other implementations? I *hope* that
this same exercise was done by the VFP architects before they
re-purposed bits but who knows. If nobody is actually setting these
higher bits then is there any problem widening the mask (besides it
being slightly confusing)?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations

[Stephen Boyd]

On 09/19/14 11:24, Stephen Boyd wrote:
> On 09/18/14 15:46, Russell King - ARM Linux wrote:
>> On Thu, Sep 18, 2014 at 02:43:11PM -0700, Stephen Boyd wrote:
>>> diff --git a/arch/arm/include/asm/vfp.h b/arch/arm/include/asm/vfp.h
>>> index f4ab34fd4f72..76d3f6907cce 100644
>>> --- a/arch/arm/include/asm/vfp.h
>>> +++ b/arch/arm/include/asm/vfp.h
>>> @@ -21,7 +21,7 @@
>>>  #define FPSID_FORMAT_MASK	(0x3  << FPSID_FORMAT_BIT)
>>>  #define FPSID_NODOUBLE		(1<<20)
>>>  #define FPSID_ARCH_BIT		(16)
>>> -#define FPSID_ARCH_MASK		(0xF  << FPSID_ARCH_BIT)
>>> +#define FPSID_ARCH_MASK		(0x7F  << FPSID_ARCH_BIT)
>> This is incorrect.  On VFPv2, the architecture field is four bits long.
>> As you can see from the above, bit 20 indicates that there are no
>> double operations provided, and the next two bits indicate the FSTMX/
>> FLDMX format.
>>
>> I know that you're changing this to conform with the ARM ARM, but we
>> have to consider that before VFP was subsumed into the ARM ARM, this
>> register had the format described as per this file, and these other
>> bits may be set for an ARM part.  Including these bits in the mask
>> means that we will mis-identify these older parts as VFPv3.
>>
>> Welcome to the lack of standardisation!
>>
> Thank you for the warm welcome! I looked at the TRMs for ARM11 and ARM9.
> I can't find anywhere where VFPv2 is supported and these bits are set.
>
> Bits 22-16 of FPSID:
>
> ARM1136r1p5:     0x01
> ARM1136r1p3:     0x01
> ARM1176:         0x01
> ARM11MPCorer2p0: 0x01
> ARM11MPCorer1p0: 0x01
> ARM1156:         0x01
> ARM9:            0x01
>
>
> Do you, or anyone else, know of other implementations? I *hope* that
> this same exercise was done by the VFP architects before they
> re-purposed bits but who knows. If nobody is actually setting these
> higher bits then is there any problem widening the mask (besides it
> being slightly confusing)?
>

Any thoughts?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations

[Will Deacon]

Hi all,

On Wed, Oct 01, 2014 at 06:54:18PM +0100, Stephen Boyd wrote:
> On 09/19/14 11:24, Stephen Boyd wrote:
> > On 09/18/14 15:46, Russell King - ARM Linux wrote:
> >> I know that you're changing this to conform with the ARM ARM, but we
> >> have to consider that before VFP was subsumed into the ARM ARM, this
> >> register had the format described as per this file, and these other
> >> bits may be set for an ARM part.  Including these bits in the mask
> >> means that we will mis-identify these older parts as VFPv3.
> >>
> > Do you, or anyone else, know of other implementations? I *hope* that
> > this same exercise was done by the VFP architects before they
> > re-purposed bits but who knows. If nobody is actually setting these
> > higher bits then is there any problem widening the mask (besides it
> > being slightly confusing)?
> >
> 
> Any thoughts?

I've spoken to the architects about this, and it seems that you need to
parse FPSID differently depending upon whether you are a v7 CPU or not.

However, as you are well aware, detecting whether or not you are v7 isn't as
simple as it sounds. cpu_architecture() checks the VMSA/PMSA fields in
MMFR0, but that's not quite right for 11MPcore (and 1176 iirc), which are
v6 implementations.

So, it sounds like the scheme is:

  if (revised_cpuid_format()) // i.e. MIDR.Architecture == 0xF
	determine_vfp_arch_using_mvfr_regs();
  else
        determine_vfp_arch_using_fpsid();

which in turn means that we probably need to rethink how we want to
advertise floating point hardware features in the future. ARMv8, for
example, adds an additional MVFR2 register, which advertises additional
floating point instructions without explicitly creating something akin to
VFPv5.

Will

[PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations

[Russell King - ARM Linux]

On Fri, Sep 19, 2014 at 11:24:01AM -0700, Stephen Boyd wrote:
> Thank you for the warm welcome! I looked at the TRMs for ARM11 and ARM9.
> I can't find anywhere where VFPv2 is supported and these bits are set.
> 
> Bits 22-16 of FPSID:
> 
> ARM1136r1p5:     0x01
> ARM1136r1p3:     0x01
> ARM1176:         0x01
> ARM11MPCorer2p0: 0x01
> ARM11MPCorer1p0: 0x01
> ARM1156:         0x01
> ARM9:            0x01
> 
> 
> Do you, or anyone else, know of other implementations? I *hope* that
> this same exercise was done by the VFP architects before they
> re-purposed bits but who knows. If nobody is actually setting these
> higher bits then is there any problem widening the mask (besides it
> being slightly confusing)?

There are certainly non-ARM implementations around, eg:

VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5

which is from Marvell Dove.  I don't know how the other Marvell offerings
identify.  I wouldn't be surprised if there were other implementations
from other vendors too.

However, if we do have any implementation which indicates that it does
not support both single and double precision ops (bit 20), then today
the VFP support code refuses to initialise, and the system will behave
as if there is no VFP present.

So, the problem case is whether we do have non-ARM produced implementations
where the VFP code refuses to init, which would then be misidentified as
some insane architecture version.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations

[Stephen Boyd]

On 10/01/14 14:50, Russell King - ARM Linux wrote:
> On Fri, Sep 19, 2014 at 11:24:01AM -0700, Stephen Boyd wrote:
>>
>> Do you, or anyone else, know of other implementations? I *hope* that
>> this same exercise was done by the VFP architects before they
>> re-purposed bits but who knows. If nobody is actually setting these
>> higher bits then is there any problem widening the mask (besides it
>> being slightly confusing)?
> There are certainly non-ARM implementations around, eg:
>
> VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5

Can you provide the raw value of the id register or at least bits 22:16?
This print is currently masking off the bits so we don't know what's
there. All we know is that bit 20 is not set because it doesn't fail to
initialize vfp.

>
> which is from Marvell Dove.  I don't know how the other Marvell offerings
> identify.  I wouldn't be surprised if there were other implementations
> from other vendors too.
>
> However, if we do have any implementation which indicates that it does
> not support both single and double precision ops (bit 20), then today
> the VFP support code refuses to initialise, and the system will behave
> as if there is no VFP present.
>
> So, the problem case is whether we do have non-ARM produced implementations
> where the VFP code refuses to init, which would then be misidentified as
> some insane architecture version.
>

I'm not aware of anything. You would know better than I though.

That check assumes a v2. We should update that check to only look for v2
or less (this isn't based on the current patch but can be squashed in).

---8<---
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 2f37e1d6cb45..22d6a1171a4e 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -738,14 +738,18 @@ static int __init vfp_init(void)
 	vfp_vector = vfp_null_entry;
 
 	pr_info("VFP support v0.3: ");
-	if (VFP_arch)
+	if (VFP_arch) {
 		pr_cont("not present\n");
-	else if (vfpsid & FPSID_NODOUBLE) {
-		pr_cont("no double precision support\n");
 	} else {
 		hotcpu_notifier(vfp_hotplug, 0);
 
 		VFP_arch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT;  /* Extract the architecture version */
+
+		if (VFP_arch < 2 && (vfpsid & FPSID_NODOUBLE)) {
+			pr_cont("no double precision support\n");
+			return 0;
+		}
+
 		pr_cont("implementor %02x architecture %d part %02x variant %x rev %x\n",
 			(vfpsid & FPSID_IMPLEMENTER_MASK) >> FPSID_IMPLEMENTER_BIT,
 			(vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT,


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 3/3] arm: vfp: Bounce undefined instructions in vectored mode

[Stephen Boyd]

From: Stepan Moskovchenko <stepanm@codeaurora.org>

Certain ARM CPU implementations (e.g. Cortex-A15) may not raise a
floating- point exception whenever deprecated short-vector VFP
instructions are executed. Instead these instructions are treated
as UNALLOCATED. Change the VFP exception handling code to emulate
short-vector instructions even if FPEXC exception bits are not
set.

Tested-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm/vfp/vfphw.S | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index be807625ed8c..c041579a8d82 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -197,6 +197,12 @@ look_for_VFP_exceptions:
 	tst	r5, #FPSCR_IXE
 	bne	process_exception
 
+	tst	r5, #FPSCR_LENGTH_MASK
+	beq	skip
+	orr	r1, r1, #FPEXC_DEX
+	b process_exception
+skip:
+
 	@ Fall into hand on to next handler - appropriate coproc instr
 	@ not recognised by VFP
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 3/3] arm: vfp: Bounce undefined instructions in vectored mode

[Russell King - ARM Linux]

On Thu, Sep 18, 2014 at 02:43:12PM -0700, Stephen Boyd wrote:
> From: Stepan Moskovchenko <stepanm@codeaurora.org>
> 
> Certain ARM CPU implementations (e.g. Cortex-A15) may not raise a
> floating- point exception whenever deprecated short-vector VFP
> instructions are executed. Instead these instructions are treated
> as UNALLOCATED. Change the VFP exception handling code to emulate
> short-vector instructions even if FPEXC exception bits are not
> set.

Purely out of interest, how much use do these instructions have in
real programs?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 3/3] arm: vfp: Bounce undefined instructions in vectored mode

[Will Deacon]

On Thu, Sep 18, 2014 at 11:55:31PM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 18, 2014 at 02:43:12PM -0700, Stephen Boyd wrote:
> > From: Stepan Moskovchenko <stepanm@codeaurora.org>
> > 
> > Certain ARM CPU implementations (e.g. Cortex-A15) may not raise a
> > floating- point exception whenever deprecated short-vector VFP
> > instructions are executed. Instead these instructions are treated
> > as UNALLOCATED. Change the VFP exception handling code to emulate
> > short-vector instructions even if FPEXC exception bits are not
> > set.
> 
> Purely out of interest, how much use do these instructions have in
> real programs?

They're seldom used, but there are apps in the app store that use short
vectors to play music.

Will

[PATCH 0/3] Krait VFP fixes

[Russell King - ARM Linux]

It would be nice to be copied on these patches, as the VFP code is
entirely my creation...  I'll review these patches shortly.

On Thu, Sep 18, 2014 at 02:43:09PM -0700, Stephen Boyd wrote:
> These changes allow us to support VFP correctly on Krait processors.
> They also fix short vector emulation for Cortex-A15 and Krait.
> 
> Stepan Moskovchenko (1):
>   arm: vfp: Bounce undefined instructions in vectored mode
> 
> Stephen Boyd (2):
>   ARM: vfp: Workaround bad MVFR1 register on some Kraits
>   ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations
> 
>  arch/arm/include/asm/cputype.h | 1 +
>  arch/arm/include/asm/vfp.h     | 2 +-
>  arch/arm/mm/proc-v7.S          | 5 +++--
>  arch/arm/vfp/vfphw.S           | 6 ++++++
>  arch/arm/vfp/vfpmodule.c       | 7 +++++++
>  5 files changed, 18 insertions(+), 3 deletions(-)
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/3] Krait VFP fixes

[Stephen Boyd]

On 09/18/14 15:32, Russell King - ARM Linux wrote:
> It would be nice to be copied on these patches, as the VFP code is
> entirely my creation...  I'll review these patches shortly.
>

Ah sorry. I will copy you on v2 and run get_maintainers too.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 0/3] Krait VFP fixes

[Rob Clark]

On Thu, Sep 18, 2014 at 5:43 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> These changes allow us to support VFP correctly on Krait processors.
> They also fix short vector emulation for Cortex-A15 and Krait.

fwiw, without these patches we were having problems w/ rpm in fedora,
which was looking for vfpv3 bits to decide whether the arch was
hardfloat or not.  With this patchset applied, this is solved.  So for
the series:

Tested-by: Rob Clark <robdclark@gmail.com>


> Stepan Moskovchenko (1):
>   arm: vfp: Bounce undefined instructions in vectored mode
>
> Stephen Boyd (2):
>   ARM: vfp: Workaround bad MVFR1 register on some Kraits
>   ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations
>
>  arch/arm/include/asm/cputype.h | 1 +
>  arch/arm/include/asm/vfp.h     | 2 +-
>  arch/arm/mm/proc-v7.S          | 5 +++--
>  arch/arm/vfp/vfphw.S           | 6 ++++++
>  arch/arm/vfp/vfpmodule.c       | 7 +++++++
>  5 files changed, 18 insertions(+), 3 deletions(-)
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html