linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] ARM: hwcap: disable HWCAP_SWP if the CPU advertises it has exclusives
Date: Mon, 7 Jul 2014 14:46:24 +0100	[thread overview]
Message-ID: <20140707134624.GC32276@arm.com> (raw)
In-Reply-To: <20140707131335.GB21766@n2100.arm.linux.org.uk>

On Mon, Jul 07, 2014 at 02:13:35PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 07, 2014 at 01:05:52PM +0100, Catalin Marinas wrote:
> > On Mon, Jul 07, 2014 at 12:17:12PM +0100, Russell King - ARM Linux wrote:
> > > On Mon, Jul 07, 2014 at 12:02:48PM +0100, Catalin Marinas wrote:
> > > > I'm not sure that's the right approach. ARM added the CPUID scheme to
> > > > allow the software to check specific features rather than guessing
> > > > specific architecture versions. Basically there isn't a clear way to
> > > > identify whether your CPU is ARMv6K or ARMv7 from a single ID register
> > > > read (you may be able to infer by reading multiple ID regs).
> > > > 
> > > > I'm now trying to figure out whether the TPIDR registers actually have a
> > > > dedicated ID. I think they only come as part of the VMSA version 7 as
> > > > identified from ID_MMFR0. The ARM1136 r1p1 TRM states that ID_MMFR0[3:0]
> > > > are 0x3 which mean VMSAv7.
> > > 
> > > You can't rely on the CPUID registers on 1136, because it doesn't
> > > advertise them as being present - the architecture field of MIDR is
> > > 0x7, not 0xf.
> > 
> > I was hoping they changed it with r1 but looking at the TRM that's not
> > the case.
> 
> You misunderstand.  r0 did not have the CPUID registers at all, so 0x7
> is correct.  r1 added the CPUID registers, but left the MIDR with the
> architecture field set to 0x7.

Yes, that's what I understood (and as I said above, I _was_ hoping ARM
brought the full CPUID to 1136 r1, including the MIDR arch field, but
that's not the case).

> > > So actually, 1136r0 is the architecturally correct version, and 1136r1
> > > is the slightly cocked up non-standard version where we have to be careful
> > > how we treat it.
> > 
> > Yes. Looking at ARM1176, it seems to be using the full CPUID scheme and
> > reporting VMSAv7. So I guess we can safely assume TLS presence if VMSAv7
> > (actually what __get_cpu_architecture checks) or ARM1136 r1+.
> 
> *Not* ARM1136 r1, because there the CPUID registers are ignored because
> MIDR does not indicate their presence.  So all ARM1136 are currently
> identified as ARMv6 by the kernel.

I agree.

> With my proposal, ARM1136 with MPIDR would be identified as ARMv6K,
> but ARM1136 r1 without MPIDR would remain identified as ARMv6.

The ARM1136 TRM states that r1 introduces ARMv6K features. However, I
can't find any trace of MPIDR and it may actually just return MIDR. If
that's the case, we don't have a way to classify ARMv6K here based on
MPIDR.

My original point was to ignore the v6K classification and, for the TLS
presence, just check the feature registers if full CPUID is present,
otherwise let TLS enabled for ARM1136 r1 because we know it implements
it (according to the TRM, special case without full CPUID).

-- 
Catalin

  reply	other threads:[~2014-07-07 13:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04 19:51 [PATCH 0/4] ABI updates Russell King - ARM Linux
2014-07-04 19:52 ` [PATCH 1/4] ARM: alignment: save last kernel aligned fault location Russell King
2014-07-04 19:52 ` [PATCH 2/4] ARM: SWP emulation: always enable when SMP is enabled Russell King
2014-07-04 19:52 ` [PATCH 3/4] ARM: SWP emulation: only initialise on ARMv7 CPUs Russell King
2014-07-04 19:52 ` [PATCH 4/4] ARM: hwcap: disable HWCAP_SWP if the CPU advertises it has exclusives Russell King
2014-07-04 20:11   ` Arnd Bergmann
2014-07-04 20:51     ` Russell King - ARM Linux
2014-07-04 20:58       ` Arnd Bergmann
2014-07-04 21:48         ` Russell King - ARM Linux
2014-07-05 18:46           ` Arnd Bergmann
2014-07-07 11:02         ` Catalin Marinas
2014-07-07 11:17           ` Russell King - ARM Linux
2014-07-07 12:05             ` Catalin Marinas
2014-07-07 13:13               ` Russell King - ARM Linux
2014-07-07 13:46                 ` Catalin Marinas [this message]
2014-07-07 15:31                   ` Russell King - ARM Linux
2014-07-07 15:59                     ` Catalin Marinas
2014-07-07 16:31                       ` Russell King - ARM Linux
2014-07-07 17:50                         ` Catalin Marinas
2014-07-07  9:34       ` Will Deacon
2014-07-07  9:41         ` Russell King - ARM Linux
2014-07-07  9:51           ` Will Deacon
2014-07-04 20:12 ` [PATCH 0/4] ABI updates Arnd Bergmann
2014-07-07 11:19 ` Tony Lindgren
2014-07-07 11:23   ` Russell King - ARM Linux
2014-07-07 13:23     ` Tony Lindgren
2014-07-07 13:52 ` Catalin Marinas

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=20140707134624.GC32276@arm.com \
    --to=catalin.marinas@arm.com \
    --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).