From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: VFP handling in multiplatform feroceon kernels
Date: Tue, 24 Jun 2014 16:32:20 +0200 [thread overview]
Message-ID: <5647865.08hn2WHr6u@wuerfel> (raw)
In-Reply-To: <20140624142505.GF4489@arm.com>
On Tuesday 24 June 2014 15:25:05 Catalin Marinas wrote:
> On Tue, Jun 24, 2014 at 03:14:23PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Jun 24, 2014 at 03:10:56PM +0100, Catalin Marinas wrote:
> > > On Tue, Jun 24, 2014 at 03:04:14PM +0100, Nicolas Pitre wrote:
> > > > On Tue, 24 Jun 2014, Catalin Marinas wrote:
> > > > Only the early revision did hijack the ARM9 ID but still. We certainly
> > > > can determine at run time if the platform being booted is equiped with a
> > > > Feroceon before user space is started. In that case I'd suggest some
> > > > runtime code patching to branch to some out-of-line assembly code for
> > > > Feroceon.
> > >
> > > You don't even need to branch to out of line assembly, just branch over
> > > the imprecise VFP abort handling in arch/arm/vfp/vfphw.S.
> >
> > This is not just about VFP - it's much bigger than that. Feroceon can't
> > use proc-arm926.S (it has errata in the cache maintanence instructions)
> > which also need handing. That's why we have a separate implementation
> > (proc-feroceon.S) so that ARM926 is not hurt by this stupidity.
>
> As Arnd suggested, we could enable multi-platform only for newer
> Feroceon chips which presumably have different id, keeping
> CONFIG_CPU_FEROCEON_OLD_ID disabled.
Note that we do disable CONFIG_CPU_FEROCEON_OLD_ID for both
kirkwood_defconfig and mvebu_v5_defconfig, and we don't even
support multiplatform on orion5x (yet), which is the platform
that needs CONFIG_CPU_FEROCEON_OLD_ID. It would be good to know
if all Orion5x suffer from this problem, or just the older ones.
I'm also not sure about mv78xx0, but it's possible we won't need
to care about that one much longer.
> The VFP code needs to be changed to
> depend on CPU_FEROCEON_OLD_ID, otherwise do proper id checking.
Right, that is all I was asking for.
> Are there other places where we need to check for CPU_FEROCEON_OLD_ID?
For all I can tell, the VFP assembly is the only code that doesn't use the
proc-feroceon.S abstraction.
Arnd
next prev parent reply other threads:[~2014-06-24 14:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 13:17 VFP handling in multiplatform feroceon kernels Arnd Bergmann
2014-06-24 13:31 ` Andrew Lunn
2014-06-24 13:47 ` Arnd Bergmann
2014-06-24 13:42 ` Catalin Marinas
2014-06-24 13:57 ` Arnd Bergmann
2014-06-24 14:04 ` Nicolas Pitre
2014-06-24 14:10 ` Catalin Marinas
2014-06-24 14:14 ` Russell King - ARM Linux
2014-06-24 14:25 ` Catalin Marinas
2014-06-24 14:32 ` Arnd Bergmann [this message]
2014-06-24 14:45 ` Nicolas Pitre
2014-06-24 14:35 ` Russell King - ARM Linux
2014-06-24 14:56 ` Nicolas Pitre
2014-06-24 15:01 ` Arnd Bergmann
2014-06-24 14:49 ` Nicolas Pitre
2014-06-24 14:56 ` Arnd Bergmann
2014-06-24 14:08 ` 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=5647865.08hn2WHr6u@wuerfel \
--to=arnd@arndb.de \
--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