All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations
Date: Wed, 01 Oct 2014 15:09:29 -0700	[thread overview]
Message-ID: <542C7B99.60500@codeaurora.org> (raw)
In-Reply-To: <20141001215043.GS5182@n2100.arm.linux.org.uk>

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

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 15:09:29 -0700	[thread overview]
Message-ID: <542C7B99.60500@codeaurora.org> (raw)
In-Reply-To: <20141001215043.GS5182@n2100.arm.linux.org.uk>

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

  reply	other threads:[~2014-10-01 22:09 UTC|newest]

Thread overview: 33+ 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
2014-10-01 17:54         ` Stephen Boyd
2014-10-08 12:49         ` Will Deacon
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 [this message]
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-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
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=542C7B99.60500@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.