From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Date: Tue, 24 Nov 2015 22:11:57 +0100 [thread overview]
Message-ID: <3507881.xd2FjVJzjC@wuerfel> (raw)
In-Reply-To: <20151124203516.GH8644@n2100.arm.linux.org.uk>
On Tuesday 24 November 2015 20:35:16 Russell King - ARM Linux wrote:
> We'd need to do something similar for v7VE as well. As we're getting
> more of this, I'd suggest we move to:
>
> arch-v7a-y =$(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
> arch-v7a-$(CONFIG_CPU_32v7VE) =... whatever it was...
> arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 $(arch-v7a-y)
> arch-v6-y =$(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
> arch-v6-$(CONFIG_CPU_32v6K) =$(call cc-option,-march=armv6k,-march=armv5t -Wa$(comma)-march=armv6k)
> arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 $(arch-v6-y)
I would argue that V7VE is different from V6K here: The instructions
that are added in V6K compared to V6 are not generated by gcc but
are typically used in assembly like
static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
{
...
#ifndef CONFIG_CPU_V6
asm volatile(...); /* v6k specific instruction */
#endif
}
while the logic in your example above would break normal v7 support when
both V7 and V7VE are enabled.
> > My understanding is that we want to support CPU_V7VE without
> > CPU_V7 enabled so that it uses the idiv instructions in that
> > configuration. When V7VE and V7 are both enabled, we should
> > degrade to the aeabi functions, and the same is true for when
> > V7VE is disabled.
>
> Let me have another look at this, it's been a while since I touched these
> options...
There is one idea that I've had in the back of my mind for a long
while, and probably mentioned on the list before:
We could decide to simplify the CPU architecture selection for
multiplatform a lot if we turn the somewhat overengineered ARCH_MULTI_*
options into a choice statement, where each of them implies the
higher architecture levels. That way we can linearize
ARMv6/v6k/v7/v7VE/v8/v8.1 so that you just pick which platforms you
want to see by selecting the minimum level, and all higher ones will
automatically be available (for v8 and v8.1 that means just MACH_VIRT,
as we don't really want to run 32-bit kernels on bare metal v8-A
machines).
That way, we can have LPAE and -march=armv7ve support depend on
CONFIG_ARCH_MULTI_V7VE, which would imply that we don't support
CPU_V7 based platforms.
Arnd
next prev parent reply other threads:[~2015-11-24 21:11 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-21 1:23 [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd
2015-11-21 1:23 ` [RFC/PATCH 1/3] scripts: Allow recordmcount to be used without tracing enabled Stephen Boyd
2015-11-21 1:23 ` [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Stephen Boyd
2015-11-21 10:13 ` Russell King - ARM Linux
2015-11-23 20:53 ` Stephen Boyd
2015-11-23 20:58 ` Steven Rostedt
2015-11-23 21:03 ` Russell King - ARM Linux
2015-11-23 21:16 ` Stephen Boyd
2015-11-23 21:33 ` Russell King - ARM Linux
2015-11-24 1:04 ` Stephen Boyd
2015-11-21 1:23 ` [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions Stephen Boyd
2015-11-21 11:50 ` Måns Rullgård
2015-11-23 20:49 ` Stephen Boyd
2015-11-23 20:54 ` Måns Rullgård
2015-11-23 21:16 ` Stephen Boyd
2015-11-21 20:39 ` [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann
2015-11-21 20:45 ` Måns Rullgård
2015-11-21 21:00 ` Arnd Bergmann
2015-11-21 22:11 ` Måns Rullgård
2015-11-21 23:14 ` Arnd Bergmann
2015-11-21 23:21 ` Arnd Bergmann
2015-11-22 13:29 ` Peter Maydell
2015-11-22 19:25 ` Arnd Bergmann
2015-11-22 19:30 ` Måns Rullgård
2015-11-22 19:47 ` Russell King - ARM Linux
2015-11-22 19:58 ` Arnd Bergmann
2015-11-22 20:03 ` Russell King - ARM Linux
2015-11-22 20:37 ` Arnd Bergmann
2015-11-22 20:39 ` Måns Rullgård
2015-11-22 21:18 ` Arnd Bergmann
2015-11-23 2:36 ` Nicolas Pitre
2015-11-23 8:15 ` Arnd Bergmann
2015-11-23 14:14 ` Christopher Covington
2015-11-23 15:32 ` Arnd Bergmann
2015-11-23 20:38 ` Stephen Boyd
2015-11-23 21:19 ` Arnd Bergmann
2015-11-23 21:32 ` Stephen Boyd
2015-11-23 21:57 ` Arnd Bergmann
2015-11-23 23:13 ` Stephen Boyd
2015-11-24 10:17 ` Arnd Bergmann
2015-11-24 12:15 ` Måns Rullgård
2015-11-24 13:45 ` Arnd Bergmann
2015-11-25 1:51 ` Stephen Boyd
2015-11-25 7:21 ` Arnd Bergmann
2015-11-24 0:13 ` Stephen Boyd
2015-11-24 8:53 ` Stephen Boyd
2015-11-24 10:38 ` Arnd Bergmann
2015-11-24 10:42 ` Russell King - ARM Linux
2015-11-24 12:10 ` Måns Rullgård
2015-11-24 12:23 ` Russell King - ARM Linux
2015-11-24 12:29 ` Måns Rullgård
2015-11-24 14:00 ` Russell King - ARM Linux
2015-11-24 14:03 ` Måns Rullgård
2015-11-24 10:39 ` Russell King - ARM Linux
2015-11-24 20:07 ` Stephen Boyd
2015-11-24 20:35 ` Russell King - ARM Linux
2015-11-24 21:11 ` Arnd Bergmann [this message]
2016-01-13 1:51 ` Stephen Boyd
2015-11-24 10:37 ` 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=3507881.xd2FjVJzjC@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