From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: vfp: fix fpsid register subarchitecture field mask width
Date: Mon, 25 Feb 2013 19:01:11 -0800 [thread overview]
Message-ID: <512C2577.3030202@codeaurora.org> (raw)
In-Reply-To: <20130225111835.GA24254@mudshark.cambridge.arm.com>
On 02/25/13 03:18, Will Deacon wrote:
> On Fri, Feb 22, 2013 at 11:46:18PM +0000, Stephen Boyd wrote:
>> On 2/22/2013 10:27 AM, Will Deacon wrote:
>>> What value do you have in fpsid? As far as I can tell, the
>>> subarchitecture bits 6:0 should start at 0x40 for you, right?
>> Yes it does.
> Ok, good. Could you share the different subarchitecture encodings that you
> have please? (assumedly some/all of these are compatible with a variant of
> VFP).
Definitely all Krait processors have 0x40 for the subarchitecture
encoding. I need to check our Scorpions but I'm fairly certain they also
have 0x40.
>
>>> I can see cases for changing this code, I just don't see why it would go
>>> wrong in the case you're describing.
>> VFP_arch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT;
>>
>> causes VFP_arch to be equal to 0 because 0x40 & 0xf == 0.
>>
>> and then a little bit later we have
>>
>> if (VFP_arch >= 2) {
>> elf_hwcap |= HWCAP_VFPv3;
>>
>>
>> The branch is not taken so we never set VFPv3.
> Ah, that's what I feared: the low bits are zero yet you are compatible with
> VFPv3. That's fine, but the proposed fix feels like a kludge; the only reason
> we'd choose on VFPv3 is because the implementor is not ARM, which may not hold
> true for other vendors. I think it would be better if we translated
> vendor-specific subarchitectures that are compatible with VFPvN into the
> corresponding architecture number instead. This would also allow us to add
> extra hwcaps for extensions other than VFP.
Ok. We should be able to make VFP_arch into 0x4 if the implementer is
0x51 and the subarch bits are 0x40.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2013-02-26 3:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 8:08 [PATCH] ARM: vfp: fix fpsid register subarchitecture field mask width Stephen Boyd
2013-02-22 18:27 ` Will Deacon
2013-02-22 23:46 ` Stephen Boyd
2013-02-25 11:18 ` Will Deacon
2013-02-26 3:01 ` Stephen Boyd [this message]
2013-02-26 17:54 ` Russell King - ARM Linux
2013-02-27 17:44 ` Stephen Boyd
2013-02-25 17:25 ` Russell King - ARM Linux
2013-02-25 20:02 ` Russell King - ARM Linux
2013-02-27 1:37 ` Stephen Boyd
2013-02-27 11:22 ` Russell King - ARM Linux
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=512C2577.3030202@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).