From: Stephen Boyd <sboyd@codeaurora.org>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
Steve Muckle <smuckle@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [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
WARNING: multiple messages have this Message-ID (diff)
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: 22+ 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 8:08 ` Stephen Boyd
2013-02-22 18:27 ` Will Deacon
2013-02-22 18:27 ` Will Deacon
2013-02-22 23:46 ` Stephen Boyd
2013-02-22 23:46 ` Stephen Boyd
2013-02-25 11:18 ` Will Deacon
2013-02-25 11:18 ` Will Deacon
2013-02-26 3:01 ` Stephen Boyd [this message]
2013-02-26 3:01 ` Stephen Boyd
2013-02-26 17:54 ` Russell King - ARM Linux
2013-02-26 17:54 ` Russell King - ARM Linux
2013-02-27 17:44 ` Stephen Boyd
2013-02-27 17:44 ` Stephen Boyd
2013-02-25 17:25 ` Russell King - ARM Linux
2013-02-25 17:25 ` Russell King - ARM Linux
2013-02-25 20:02 ` Russell King - ARM Linux
2013-02-25 20:02 ` Russell King - ARM Linux
2013-02-27 1:37 ` Stephen Boyd
2013-02-27 1:37 ` Stephen Boyd
2013-02-27 11:22 ` Russell King - ARM Linux
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 \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=smuckle@codeaurora.org \
--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.