From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: Fix mounting root on omaps with CPU_V6 and CPU_V7
Date: Thu, 18 Mar 2010 10:00:22 -0700 [thread overview]
Message-ID: <20100318170021.GN2900@atomide.com> (raw)
In-Reply-To: <1268910826.15334.32.camel@e102109-lin.cambridge.arm.com>
* Catalin Marinas <catalin.marinas@arm.com> [100318 04:10]:
> On Wed, 2010-03-17 at 19:11 +0000, Tony Lindgren wrote:
> > * Catalin Marinas <catalin.marinas@arm.com> [100317 11:04]:
> > > On Wed, 2010-03-17 at 17:57 +0000, Tony Lindgren wrote:
> > > > Here's an updated version of this patch with more details.
> > > >
> > > > Looks like VFPv3 is only available on V7:
> > > >
> > > > http://www.arm.com/products/processors/technologies/vector-floating-point.php
> > >
> > > But does it cause any problem if the feature is enabled in the kernel?
> > > The vfp_init() code should check for its presence and set the hwcap
> > > accordingly.
> >
> > Yeah, it causes the problem posted in the patch description. I took a
> > quick look at it and at least the VFPFMRX in vfpmacros.h for CONFIG_VFPv3
> > is a problem.
>
> This would indeed need more checking to avoid reading some registers
> which aren't present on ARMv6.
>
> I think the main problem with just falling back to VFPv2 is the lack of
> NEON support even if the CPU supports it.
Yeah it would be nice to have things also working in a reasonably fast
and usable way for distros etc.
> > Also I think we would need to have separate vfp_get_double functions
> > in vfphw.S for VFPv2 and 3 that get used based on the features.
>
> I don't think that's causing problems (or at least we can identify where
> the function gets called for higher VFP registers). Even with VFPv3, you
> may not have the D16-D31 registers.
OK. There's also an ifdef else define for VFP_REG_ZERO in vfp.h. Sounds
like that test would also need to be done dynamically.
> > > > HAS_TLS reg is only on ARM11 starting with r1p0:
> > > >
> > > > http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211k/Babeihid.html
> > > >
> > > > So that explains why it won't work on omap2420 as it's r0p2.
> > >
> > > Same here, would it work with dynamic detection?
> >
> > Hmm I believe here the problem is __switch_to in entry-armv.S.
> > I don't think we want to dynamically test it every time.. Or
> > at least it would have to be optimized out in most cases.
>
> But if you disable this, you won't be able to use an SMP build on both
> v6 and v7. Anyway, I don't think that dynamically checking this would
> introduce performance penalties, the __switch_to code is pretty complex
> already with all the notifier calls.
OK. I'll take a look at setting the TLS a HWCAP flag.
> We may also have optimised user space that reads the TLS register
> directly rather than going through the kuser helper, in which case we
> would need a kernel built only for ARMv7 (maybe that's acceptable in
> this situation).
Sounds like more of a hassle to me :)
Tony
next prev parent reply other threads:[~2010-03-18 17:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-17 17:57 [PATCH] arm: Fix mounting root on omaps with CPU_V6 and CPU_V7 Tony Lindgren
2010-03-17 18:07 ` Catalin Marinas
2010-03-17 19:11 ` Tony Lindgren
2010-03-18 11:13 ` Catalin Marinas
2010-03-18 17:00 ` Tony Lindgren [this message]
2010-03-19 1:35 ` [PATCH] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6 Tony Lindgren
2010-03-19 3:24 ` Tony Lindgren
2010-03-19 3:46 ` Jamie Lokier
2010-03-19 8:54 ` Russell King - ARM Linux
2010-03-19 15:32 ` Tony Lindgren
2010-03-19 8:53 ` Russell King - ARM Linux
2010-03-19 15:58 ` Tony Lindgren
2010-03-23 0:16 ` Russell King - ARM Linux
2010-03-23 0:54 ` Tony Lindgren
-- strict thread matches above, loose matches on Subject: below --
2010-03-15 22:25 [PATCH] arm: Fix mounting root on omaps with CPU_V6 and CPU_V7 Tony Lindgren
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=20100318170021.GN2900@atomide.com \
--to=tony@atomide.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).