From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: VFP available on a single CPU in a dual-CPU complex
Date: Fri, 15 Aug 2014 12:00:07 -0700 [thread overview]
Message-ID: <53EE58B7.6030207@gmail.com> (raw)
In-Reply-To: <8014330.Y4lYRxBeEx@wuerfel>
On 08/15/2014 11:54 AM, Arnd Bergmann wrote:
> On Friday 15 August 2014 10:14:45 Will Deacon wrote:
>> On Fri, Aug 15, 2014 at 10:03:01AM +0100, Arnd Bergmann wrote:
>>> On Friday 15 August 2014, Florian Fainelli wrote:
>>>> Hello,
>>>>
>>>> On Broadcom's BCM63138 SoC, the second Cortex A9 CPU does not have
>>>> VFP, which is a problem as one might imagine because we currently
>>>> assume it is available for all CPUs within the complex.
>>>
>>> Wow, that is pretty crazy.
>>>
>>>> I started to patch vfp_support_entry to test for CPU1 and branch to a
>>>> different location, but that raises a bunch of question, in particular
>>>> what to do if NEON/VFP came from the kernel, how can we migrate that
>>>> execution to CPU0?
>>>>
>>>> If the answer is don't use VFP, I guess that's fine, and I can have a
>>>> runtime check in vfp_init() that checks for BCM63138 and set
>>>> vfp_vector to vfp_null_entry even though we are running on a multi-v7
>>>> kernel with VFP enabled.
>>>
>>> I think adding hooks to the scheduler for this case is problematic, so
>>> the easiest way would of course be to give the user a choice between
>>> VFP or SMP on this hardware. For anything beyond that, you could do
>>> a prototype patch (possibly for integration into OpenWRT) so we can
>>> see how ugly it gets to support this setup.
>>
>> I agree. We have something similar on the Realview-PBX (dual A9, only one
>> CPU with NEON) and the answer is not to enable NEON if you want SMP.
>
> Does that work with a multiplatform kernel?
>
> I have patches to enable realview for ARCH_MULTIPLATFORM, and I wonder
> if that gets in the way. Do we have code to detect this setup at runtime
> and disable NEON/VFP if only a subset of the enabled CPUs have it?
I was wondering about that too, here are the two options I see for these
pathological cases:
- if SMP is enabled, and CONFIG_VFP is also enabled, refuse bringing up
cores that do not support VFP/NEON, thus becoming a SMP on UP, and do
that for the platform/SoC-specific SMP support code
- or, in the VFP initialization, completely disable VFP (overriding
VFP_arch in SoC specific code?) because at least one of CPU does not
support it
I would favor enabling SMP over enabling VFP, because that's probably
what most people would expect.
--
Florian
next prev parent reply other threads:[~2014-08-15 19:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-15 4:45 VFP available on a single CPU in a dual-CPU complex Florian Fainelli
2014-08-15 9:03 ` Arnd Bergmann
2014-08-15 9:14 ` Will Deacon
2014-08-15 18:54 ` Arnd Bergmann
2014-08-15 19:00 ` Florian Fainelli [this message]
2014-08-15 21:24 ` Måns Rullgård
2014-08-18 14:22 ` Catalin Marinas
2014-08-15 9:07 ` 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=53EE58B7.6030207@gmail.com \
--to=f.fainelli@gmail.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 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.