All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Russell King <linux@arm.linux.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Rob Clark <robdclark@gmail.com>
Subject: Re: [PATCH v2 2/3] ARM: vfp: Fix VFPv3 hwcap detection on CPUID based cpus
Date: Tue, 28 Oct 2014 12:11:55 +0000	[thread overview]
Message-ID: <20141028121154.GA12136@arm.com> (raw)
In-Reply-To: <544EA212.7030401@codeaurora.org>

On Mon, Oct 27, 2014 at 07:50:42PM +0000, Stephen Boyd wrote:
> On 10/27/2014 03:31 AM, Will Deacon wrote:
> > On Tue, Oct 14, 2014 at 02:48:58PM +0100, Stephen Boyd wrote:
> >> If the CPU is using CPUID scheme, use the MVFR registers to
> >> determine what version of VFP is supported. We already do this
> >> for VFPv4, so do something similar for VFPv3 and look for single
> >> or double precision support in MVFR0. Otherwise fall back to
> >> using FPSID to detect VFP suppport on non-CPUID scheme CPUs. We
> >> know that VFPv3 is only present in CPUs that have support for the
> >> CPUID scheme so this should be equivalent.
> > This looks correct to me, but it raises a bigger question about the
> > suitability of hwcaps for describing features of the instruction set.
> 
> Great. Can I get your reviewed-by on this patch please?

Sure. There's a spelling mistake ("arhitecture") which you should fix,
but the code looks ok.

> > With the extended CPUID scheme, there are a whole bunch of different
> > instruction set features that are reported and bundling arbitrary subsets of
> > them into hwcaps such as `VFPv4' doesn't feel like the right thing to do in
> > the long run. It also doesn't seem to match where the architecture is going.
> >
> > Perhaps it would be better to consider exposing the ID registers to
> > userspace in some manner? This could be done either via an undef handler, or
> > using the vdso. We would add a (final) hwcap advertising this cpuid support.
> > For big/little systems, the kernel would need to expose a suitable subset of
> > the features (we already have the sanity checking code from Rutland).
> >
> > I'd certainly like to explore that route for arm64, before we start adding a
> > bunch of fine-grained capabilities.
> 
> I have an RFC for the undef handler written up, except for the
> big/little thing. Let me post it. Is there anyone from the userspace
> side that can be on Cc?

Off the top of my head:

  Mans Rullgard (already replied to this thread)
  Peter Maydell <peter.maydell@linaro.org> [QEMU]
  Jacob Bramley <jacob.bramley@arm.com> [JITs]
  Kyrylo Tkachov <kyrylo.tkachov@arm.com> [GCC]

(CC Rutland for the big/little bits too)

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/3] ARM: vfp: Fix VFPv3 hwcap detection on CPUID based cpus
Date: Tue, 28 Oct 2014 12:11:55 +0000	[thread overview]
Message-ID: <20141028121154.GA12136@arm.com> (raw)
In-Reply-To: <544EA212.7030401@codeaurora.org>

On Mon, Oct 27, 2014 at 07:50:42PM +0000, Stephen Boyd wrote:
> On 10/27/2014 03:31 AM, Will Deacon wrote:
> > On Tue, Oct 14, 2014 at 02:48:58PM +0100, Stephen Boyd wrote:
> >> If the CPU is using CPUID scheme, use the MVFR registers to
> >> determine what version of VFP is supported. We already do this
> >> for VFPv4, so do something similar for VFPv3 and look for single
> >> or double precision support in MVFR0. Otherwise fall back to
> >> using FPSID to detect VFP suppport on non-CPUID scheme CPUs. We
> >> know that VFPv3 is only present in CPUs that have support for the
> >> CPUID scheme so this should be equivalent.
> > This looks correct to me, but it raises a bigger question about the
> > suitability of hwcaps for describing features of the instruction set.
> 
> Great. Can I get your reviewed-by on this patch please?

Sure. There's a spelling mistake ("arhitecture") which you should fix,
but the code looks ok.

> > With the extended CPUID scheme, there are a whole bunch of different
> > instruction set features that are reported and bundling arbitrary subsets of
> > them into hwcaps such as `VFPv4' doesn't feel like the right thing to do in
> > the long run. It also doesn't seem to match where the architecture is going.
> >
> > Perhaps it would be better to consider exposing the ID registers to
> > userspace in some manner? This could be done either via an undef handler, or
> > using the vdso. We would add a (final) hwcap advertising this cpuid support.
> > For big/little systems, the kernel would need to expose a suitable subset of
> > the features (we already have the sanity checking code from Rutland).
> >
> > I'd certainly like to explore that route for arm64, before we start adding a
> > bunch of fine-grained capabilities.
> 
> I have an RFC for the undef handler written up, except for the
> big/little thing. Let me post it. Is there anyone from the userspace
> side that can be on Cc?

Off the top of my head:

  Mans Rullgard (already replied to this thread)
  Peter Maydell <peter.maydell@linaro.org> [QEMU]
  Jacob Bramley <jacob.bramley@arm.com> [JITs]
  Kyrylo Tkachov <kyrylo.tkachov@arm.com> [GCC]

(CC Rutland for the big/little bits too)

Will

  reply	other threads:[~2014-10-28 12:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-14 13:48 [PATCH v2 0/3] VFP fixes Stephen Boyd
2014-10-14 13:48 ` Stephen Boyd
2014-10-14 13:48 ` [PATCH v2 1/3] ARM: vfp: Workaround bad MVFR1 register on some Kraits Stephen Boyd
2014-10-14 13:48   ` Stephen Boyd
2014-10-14 13:48 ` [PATCH v2 2/3] ARM: vfp: Fix VFPv3 hwcap detection on CPUID based cpus Stephen Boyd
2014-10-14 13:48   ` Stephen Boyd
2014-10-27 10:31   ` Will Deacon
2014-10-27 10:31     ` Will Deacon
2014-10-27 11:49     ` Måns Rullgård
2014-10-27 11:49       ` Måns Rullgård
2014-10-27 11:49       ` Måns Rullgård
2014-10-27 19:50     ` Stephen Boyd
2014-10-27 19:50       ` Stephen Boyd
2014-10-28 12:11       ` Will Deacon [this message]
2014-10-28 12:11         ` Will Deacon
2014-10-28 17:54         ` Stephen Boyd
2014-10-28 17:54           ` Stephen Boyd
2014-10-14 13:48 ` [PATCH v2 3/3] arm: vfp: Bounce undefined instructions in vectored mode Stephen Boyd
2014-10-14 13:48   ` Stephen Boyd
2014-10-16 13:14 ` [PATCH v2 0/3] VFP fixes Rob Clark
2014-10-16 13:14   ` 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=20141028121154.GA12136@arm.com \
    --to=will.deacon@arm.com \
    --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=robdclark@gmail.com \
    --cc=sboyd@codeaurora.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 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.