From: Stephen Boyd <sboyd@codeaurora.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-msm@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations
Date: Wed, 01 Oct 2014 10:54:18 -0700 [thread overview]
Message-ID: <542C3FCA.2010006@codeaurora.org> (raw)
In-Reply-To: <541C74C1.9060504@codeaurora.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations
Date: Wed, 01 Oct 2014 10:54:18 -0700 [thread overview]
Message-ID: <542C3FCA.2010006@codeaurora.org> (raw)
In-Reply-To: <541C74C1.9060504@codeaurora.org>
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
next prev parent reply other threads:[~2014-10-01 17:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 21:43 [PATCH 0/3] Krait VFP fixes Stephen Boyd
2014-09-18 21:43 ` Stephen Boyd
2014-09-18 21:43 ` [PATCH 1/3] ARM: vfp: Workaround bad MVFR1 register on some Kraits Stephen Boyd
2014-09-18 21:43 ` Stephen Boyd
2014-09-18 21:43 ` [PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations Stephen Boyd
2014-09-18 21:43 ` Stephen Boyd
2014-09-18 22:46 ` Russell King - ARM Linux
2014-09-18 22:46 ` Russell King - ARM Linux
2014-09-19 18:24 ` Stephen Boyd
2014-09-19 18:24 ` Stephen Boyd
2014-10-01 17:54 ` Stephen Boyd [this message]
2014-10-01 17:54 ` Stephen Boyd
2014-10-08 12:49 ` Will Deacon
2014-10-08 12:49 ` Will Deacon
2014-10-01 21:50 ` Russell King - ARM Linux
2014-10-01 21:50 ` Russell King - ARM Linux
2014-10-01 22:09 ` Stephen Boyd
2014-10-01 22:09 ` Stephen Boyd
2014-09-18 21:43 ` [PATCH 3/3] arm: vfp: Bounce undefined instructions in vectored mode Stephen Boyd
2014-09-18 21:43 ` Stephen Boyd
2014-09-18 22:55 ` Russell King - ARM Linux
2014-09-18 22:55 ` Russell King - ARM Linux
2014-09-19 1:40 ` Will Deacon
2014-09-19 1:40 ` Will Deacon
2014-09-18 22:32 ` [PATCH 0/3] Krait VFP fixes Russell King - ARM Linux
2014-09-18 22:32 ` Russell King - ARM Linux
2014-09-19 16:29 ` Stephen Boyd
2014-09-19 16:29 ` Stephen Boyd
2014-09-21 16:40 ` Rob Clark
2014-09-21 16:40 ` Rob Clark
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=542C3FCA.2010006@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=will.deacon@arm.com \
/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.