Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1274584 > unrolled thread
| Started by | Stephen Boyd <sboyd@codeaurora.org> |
|---|---|
| First post | 2015-11-21 02:30 +0100 |
| Last post | 2015-11-21 21:50 +0100 |
| Articles | 18 on this page of 58 — 8 participants |
Back to article view | Back to linux.kernel
[RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-21 02:30 +0100
[RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Stephen Boyd <sboyd@codeaurora.org> - 2015-11-21 02:30 +0100
Re: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-21 11:20 +0100
Re: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Steven Rostedt <rostedt@goodmis.org> - 2015-11-23 22:00 +0100
Re: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 22:00 +0100
Re: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-23 22:10 +0100
Re: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 22:20 +0100
Re: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-23 22:40 +0100
Re: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Stephen Boyd <sboyd@codeaurora.org> - 2015-11-24 02:10 +0100
[RFC/PATCH 1/3] scripts: Allow recordmcount to be used without tracing enabled Stephen Boyd <sboyd@codeaurora.org> - 2015-11-21 02:30 +0100
[RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-21 02:30 +0100
Re: [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions Måns Rullgård <mans@mansr.com> - 2015-11-21 13:00 +0100
Re: [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 22:00 +0100
Re: [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions Måns Rullgård <mans@mansr.com> - 2015-11-23 22:00 +0100
Re: [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 22:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-21 21:50 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-21 22:10 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-21 23:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 00:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 00:30 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Peter Maydell <peter.maydell@linaro.org> - 2015-11-22 14:40 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 20:30 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-22 20:40 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-22 20:50 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 21:00 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-22 21:10 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 21:40 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-22 21:50 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 22:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Nicolas Pitre <nicolas.pitre@linaro.org> - 2015-11-23 03:40 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-23 09:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Christopher Covington <cov@codeaurora.org> - 2015-11-23 15:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-23 16:40 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 21:40 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-23 22:30 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 22:40 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-23 23:00 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-24 00:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-24 11:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-24 13:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-24 14:50 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-25 03:00 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-25 08:30 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-24 01:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-24 10:00 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-24 11:40 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 11:50 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-24 13:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-24 13:30 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-24 15:10 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 15:10 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 13:30 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 11:50 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-24 21:10 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 21:40 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-24 22:20 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 11:40 +0100
Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-21 21:50 +0100
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2015-11-24 14:50 +0100 |
| Message-ID | <qym8O-jw-13@gated-at.bofh.it> |
| In reply to | #1276379 |
On Tuesday 24 November 2015 12:15:13 Måns Rullgård wrote: > Arnd Bergmann <arnd@arndb.de> writes: > > On Monday 23 November 2015 15:13:52 Stephen Boyd wrote: > >> On 11/23, Arnd Bergmann wrote: > >> > On Monday 23 November 2015 13:32:06 Stephen Boyd wrote: > >> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig > >> > index b251013eef0a..bad6343c34d5 100644 > >> Do you have the information on these custom opcodes? I can work > >> that into the patches assuming the MIDR is different. > > > > Thomas Petazzoni said this in a private mail: > > > > | According to the datasheet, the PJ4B has integer signed and unsigned > > | divide, similar to the sdiv and udiv ARM instructions. But the way to > > | access it is by doing a MRC instruction. > > | > > | MRC<cond> p6, 1, Rd , CRn , CRm, 4 > > | > > |for PJ4B is the same as: > > | > > | SDIV Rd , Rn, Rm > > | > > | on ARM cores. > > | > > |And: > > | > > | MRC<cond> p6, 1, Rd , CRn , CRm, 0 > > | > > |for PJ4B is the same as: > > | > > | UDIV Rd , Rn, Rm > > | > > |on ARM cores. > > | > > |This is documented in the "Extended instructions" section of the > > |PJ4B datasheet. > > > > I assume what he meant was that this is true for both PJ4 and PJ4B > > but not for PJ4B-MP, which has the normal udiv/sdiv instructions. > > > > IOW, anything with CPU implementer 0x56 part 0x581 should use those, > > while part 0x584 can use the sdiv/udiv that it reports correctly. > > Or we could simply ignore those and they'd be no worse off than they are > now. Well, if we add all the infrastructure to do dynamic patching, we might as well use it here, that is a very little extra effort. I'm not convinced that the dynamic patching for idiv is actually needed but I'm not objecting either, and Stephen has done the work already. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stephen Boyd <sboyd@codeaurora.org> |
|---|---|
| Date | 2015-11-25 03:00 +0100 |
| Subject | Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions |
| Message-ID | <qyxxg-7M5-3@gated-at.bofh.it> |
| In reply to | #1276264 |
On 11/24, Arnd Bergmann wrote:
> On Monday 23 November 2015 15:13:52 Stephen Boyd wrote:
> > On 11/23, Arnd Bergmann wrote:
> > >
> > > - PJ4/PJ4B (not PJ4B-MP) has a different custom opcode for udiv and sdiv
> > > in ARM mode. We don't support that with true multiplatform kernels
> > > because those opcodes work nowhere else, though with your proposed
> > > series we could easily do that for dynamic patching.
> >
> > Do you have the information on these custom opcodes? I can work
> > that into the patches assuming the MIDR is different.
>
> Thomas Petazzoni said this in a private mail:
>
> | According to the datasheet, the PJ4B has integer signed and unsigned
> | divide, similar to the sdiv and udiv ARM instructions. But the way to
> | access it is by doing a MRC instruction.
> |
> | MRC<cond> p6, 1, Rd , CRn , CRm, 4
> |
> |for PJ4B is the same as:
> |
> | SDIV Rd , Rn, Rm
> |
> | on ARM cores.
> |
> |And:
> |
> | MRC<cond> p6, 1, Rd , CRn , CRm, 0
> |
> |for PJ4B is the same as:
> |
> | UDIV Rd , Rn, Rm
> |
> |on ARM cores.
> |
> |This is documented in the "Extended instructions" section of the
> |PJ4B datasheet.
>
> I assume what he meant was that this is true for both PJ4 and PJ4B
> but not for PJ4B-MP, which has the normal udiv/sdiv instructions.
>
> IOW, anything with CPU implementer 0x56 part 0x581 should use those,
> while part 0x584 can use the sdiv/udiv that it reports correctly.
>
It looks like we have some sort of function that mostly does
this, except it doesn't differentiate on that lower bit for 1 vs
4. I guess I'll write another one for that.
static inline int cpu_is_pj4(void)
{
unsigned int id;
id = read_cpuid_id();
if ((id & 0xff0fff00) == 0x560f5800)
return 1;
return 0;
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2015-11-25 08:30 +0100 |
| Message-ID | <qyCGC-2ZS-11@gated-at.bofh.it> |
| In reply to | #1276963 |
On Tuesday 24 November 2015 17:51:37 Stephen Boyd wrote:
> On 11/24, Arnd Bergmann wrote:
> > On Monday 23 November 2015 15:13:52 Stephen Boyd wrote:
> > IOW, anything with CPU implementer 0x56 part 0x581 should use those,
> > while part 0x584 can use the sdiv/udiv that it reports correctly.
> >
>
> It looks like we have some sort of function that mostly does
> this, except it doesn't differentiate on that lower bit for 1 vs
> 4. I guess I'll write another one for that.
>
> static inline int cpu_is_pj4(void)
> {
> unsigned int id;
>
> id = read_cpuid_id();
> if ((id & 0xff0fff00) == 0x560f5800)
> return 1;
>
> return 0;
> }
Correct, thanks.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stephen Boyd <sboyd@codeaurora.org> |
|---|---|
| Date | 2015-11-24 01:20 +0100 |
| Subject | Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions |
| Message-ID | <qy9uV-EF-15@gated-at.bofh.it> |
| In reply to | #1275898 |
On 11/23, Arnd Bergmann wrote: > > Ok, thanks for the confirmation. > > Summarizing what we've found, I think we can get away with just > introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE. > Most CPUs fall clearly into one category or the other, and then > we can allow LPAE to be selected for V7VE-only build but not > for plain V7, and we can unconditionally build the kernel with > > arch-$(CONFIG_CPU_32v7VE) = -D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7ve,-march=armv7-a -mcpu=cortex-a15) > This causes compiler spew for me: warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch Removing -march=armv7-a from there makes it quiet. Also, it's sort of feels wrong to have -mcpu in a place where we're exclusively doing -march. Perhaps the fallback should be bog standard -march=armv7-a? (or the fallback for that one "-march=armv5t -Wa$(comma)-march=armv7-a")? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stephen Boyd <sboyd@codeaurora.org> |
|---|---|
| Date | 2015-11-24 10:00 +0100 |
| Subject | Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions |
| Message-ID | <qyhC9-5Ot-1@gated-at.bofh.it> |
| In reply to | #1275981 |
On 11/23, Stephen Boyd wrote:
> On 11/23, Arnd Bergmann wrote:
> >
> > Ok, thanks for the confirmation.
> >
> > Summarizing what we've found, I think we can get away with just
> > introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE.
> > Most CPUs fall clearly into one category or the other, and then
> > we can allow LPAE to be selected for V7VE-only build but not
> > for plain V7, and we can unconditionally build the kernel with
> >
> > arch-$(CONFIG_CPU_32v7VE) = -D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7ve,-march=armv7-a -mcpu=cortex-a15)
> >
>
> This causes compiler spew for me:
>
> warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch
>
> Removing -march=armv7-a from there makes it quiet.
>
> Also, it's sort of feels wrong to have -mcpu in a place where
> we're exclusively doing -march. Perhaps the fallback should be
> bog standard -march=armv7-a? (or the fallback for that one
> "-march=armv5t -Wa$(comma)-march=armv7-a")?
>
And adding CPU_V7VE causes a cascade of changes to wherever
CPU_V7 is being used today. Here's the patch I currently have,
without the platform changes:
---8<----
arch/arm/Kconfig | 68 +++++++++++++++++++++-----------------
arch/arm/Kconfig-nommu | 2 +-
arch/arm/Makefile | 1 +
arch/arm/boot/compressed/head.S | 2 +-
arch/arm/boot/compressed/misc.c | 2 +-
arch/arm/include/asm/cacheflush.h | 2 +-
arch/arm/include/asm/glue-cache.h | 2 +-
arch/arm/include/asm/glue-proc.h | 2 +-
arch/arm/include/asm/switch_to.h | 2 +-
arch/arm/include/debug/icedcc.S | 2 +-
arch/arm/kernel/entry-armv.S | 6 ++--
arch/arm/kernel/perf_event_v7.c | 4 +--
arch/arm/kvm/Kconfig | 2 +-
arch/arm/mm/Kconfig | 41 ++++++++++++++++-------
arch/arm/mm/Makefile | 1 +
arch/arm/probes/kprobes/test-arm.c | 2 +-
drivers/bus/Kconfig | 6 ++--
17 files changed, 86 insertions(+), 61 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9e2d2adcc85b..ccd0d5553d38 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -32,7 +32,7 @@ config ARM
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
- select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
+ select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7 || CPU_32_v7VE) && !CPU_32v6
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32
select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32
select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
@@ -46,12 +46,12 @@ config ARM
select HAVE_DMA_ATTRS
select HAVE_DMA_CONTIGUOUS if MMU
select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) && !CPU_ENDIAN_BE32
- select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
+ select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7VE) && MMU
select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
select HAVE_FUNCTION_GRAPH_TRACER if (!THUMB2_KERNEL)
select HAVE_FUNCTION_TRACER if (!XIP_KERNEL)
select HAVE_GENERIC_DMA_COHERENT
- select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7))
+ select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7VE))
select HAVE_IDE if PCI || ISA || PCMCIA
select HAVE_IRQ_TIME_ACCOUNTING
select HAVE_KERNEL_GZIP
@@ -805,6 +805,12 @@ config ARCH_MULTI_V7
select CPU_V7
select HAVE_SMP
+config ARCH_MULTI_V7VE
+ bool "ARMv7 w/ virtualization extensions based platforms (Cortex-A, PJ4-MP, Krait)"
+ select ARCH_MULTI_V6_V7
+ select CPU_V7VE
+ select HAVE_SMP
+
config ARCH_MULTI_V6_V7
bool
select MIGHT_HAVE_CACHE_L2X0
@@ -1069,7 +1075,7 @@ config ARM_ERRATA_411920
config ARM_ERRATA_430973
bool "ARM errata: Stale prediction on replaced interworking branch"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
help
This option enables the workaround for the 430973 Cortex-A8
r1p* erratum. If a code sequence containing an ARM/Thumb
@@ -1085,7 +1091,7 @@ config ARM_ERRATA_430973
config ARM_ERRATA_458693
bool "ARM errata: Processor deadlock when a false hazard is created"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
depends on !ARCH_MULTIPLATFORM
help
This option enables the workaround for the 458693 Cortex-A8 (r2p0)
@@ -1099,7 +1105,7 @@ config ARM_ERRATA_458693
config ARM_ERRATA_460075
bool "ARM errata: Data written to the L2 cache can be overwritten with stale data"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
depends on !ARCH_MULTIPLATFORM
help
This option enables the workaround for the 460075 Cortex-A8 (r2p0)
@@ -1112,7 +1118,7 @@ config ARM_ERRATA_460075
config ARM_ERRATA_742230
bool "ARM errata: DMB operation may be faulty"
- depends on CPU_V7 && SMP
+ depends on (CPU_V7 || CPU_V7VE) && SMP
depends on !ARCH_MULTIPLATFORM
help
This option enables the workaround for the 742230 Cortex-A9
@@ -1125,7 +1131,7 @@ config ARM_ERRATA_742230
config ARM_ERRATA_742231
bool "ARM errata: Incorrect hazard handling in the SCU may lead to data corruption"
- depends on CPU_V7 && SMP
+ depends on (CPU_V7 || CPU_V7VE) && SMP
depends on !ARCH_MULTIPLATFORM
help
This option enables the workaround for the 742231 Cortex-A9
@@ -1140,7 +1146,7 @@ config ARM_ERRATA_742231
config ARM_ERRATA_643719
bool "ARM errata: LoUIS bit field in CLIDR register is incorrect"
- depends on CPU_V7 && SMP
+ depends on (CPU_V7 || CPU_V7VE) && SMP
default y
help
This option enables the workaround for the 643719 Cortex-A9 (prior to
@@ -1151,7 +1157,7 @@ config ARM_ERRATA_643719
config ARM_ERRATA_720789
bool "ARM errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
help
This option enables the workaround for the 720789 Cortex-A9 (prior to
r2p0) erratum. A faulty ASID can be sent to the other CPUs for the
@@ -1163,7 +1169,7 @@ config ARM_ERRATA_720789
config ARM_ERRATA_743622
bool "ARM errata: Faulty hazard checking in the Store Buffer may lead to data corruption"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
depends on !ARCH_MULTIPLATFORM
help
This option enables the workaround for the 743622 Cortex-A9
@@ -1177,7 +1183,7 @@ config ARM_ERRATA_743622
config ARM_ERRATA_751472
bool "ARM errata: Interrupted ICIALLUIS may prevent completion of broadcasted operation"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
depends on !ARCH_MULTIPLATFORM
help
This option enables the workaround for the 751472 Cortex-A9 (prior
@@ -1188,7 +1194,7 @@ config ARM_ERRATA_751472
config ARM_ERRATA_754322
bool "ARM errata: possible faulty MMU translations following an ASID switch"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
help
This option enables the workaround for the 754322 Cortex-A9 (r2p*,
r3p*) erratum. A speculative memory access may cause a page table walk
@@ -1199,7 +1205,7 @@ config ARM_ERRATA_754322
config ARM_ERRATA_754327
bool "ARM errata: no automatic Store Buffer drain"
- depends on CPU_V7 && SMP
+ depends on (CPU_V7 || CPU_V7VE) && SMP
help
This option enables the workaround for the 754327 Cortex-A9 (prior to
r2p0) erratum. The Store Buffer does not have any automatic draining
@@ -1222,7 +1228,7 @@ config ARM_ERRATA_364296
config ARM_ERRATA_764369
bool "ARM errata: Data cache line maintenance operation by MVA may not succeed"
- depends on CPU_V7 && SMP
+ depends on (CPU_V7 || CPU_V7VE) && SMP
help
This option enables the workaround for erratum 764369
affecting Cortex-A9 MPCore with two or more processors (all
@@ -1236,7 +1242,7 @@ config ARM_ERRATA_764369
config ARM_ERRATA_775420
bool "ARM errata: A data cache maintenance operation which aborts, might lead to deadlock"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
help
This option enables the workaround for the 775420 Cortex-A9 (r2p2,
r2p6,r2p8,r2p10,r3p0) erratum. In case a date cache maintenance
@@ -1246,7 +1252,7 @@ config ARM_ERRATA_775420
config ARM_ERRATA_798181
bool "ARM errata: TLBI/DSB failure on Cortex-A15"
- depends on CPU_V7 && SMP
+ depends on (CPU_V7 || CPU_V7VE) && SMP
help
On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not
adequately shooting down all use of the old entries. This
@@ -1256,7 +1262,7 @@ config ARM_ERRATA_798181
config ARM_ERRATA_773022
bool "ARM errata: incorrect instructions may be executed from loop buffer"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
help
This option enables the workaround for the 773022 Cortex-A15
(up to r0p4) erratum. In certain rare sequences of code, the
@@ -1337,7 +1343,7 @@ config HAVE_SMP
config SMP
bool "Symmetric Multi-Processing"
- depends on CPU_V6K || CPU_V7
+ depends on CPU_V6K || CPU_V7 || CPU_V7VE
depends on GENERIC_CLOCKEVENTS
depends on HAVE_SMP
depends on MMU || ARM_MPU
@@ -1373,7 +1379,7 @@ config SMP_ON_UP
config ARM_CPU_TOPOLOGY
bool "Support cpu topology definition"
- depends on SMP && CPU_V7
+ depends on SMP && (CPU_V7 || CPU_V7VE)
default y
help
Support ARM cpu topology definition. The MPIDR register defines
@@ -1403,7 +1409,7 @@ config HAVE_ARM_SCU
config HAVE_ARM_ARCH_TIMER
bool "Architected timer support"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
select ARM_ARCH_TIMER
select GENERIC_CLOCKEVENTS
help
@@ -1417,7 +1423,7 @@ config HAVE_ARM_TWD
config MCPM
bool "Multi-Cluster Power Management"
- depends on CPU_V7 && SMP
+ depends on (CPU_V7 || CPU_V7VE) && SMP
help
This option provides the common power management infrastructure
for (multi-)cluster based systems, such as big.LITTLE based
@@ -1434,7 +1440,7 @@ config MCPM_QUAD_CLUSTER
config BIG_LITTLE
bool "big.LITTLE support (Experimental)"
- depends on CPU_V7 && SMP
+ depends on (CPU_V7 || CPU_V7VE) && SMP
select MCPM
help
This option enables support selections for the big.LITTLE
@@ -1501,7 +1507,7 @@ config HOTPLUG_CPU
config ARM_PSCI
bool "Support for the ARM Power State Coordination Interface (PSCI)"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
select ARM_PSCI_FW
help
Say Y here if you want Linux to communicate with system firmware
@@ -1579,7 +1585,7 @@ config SCHED_HRTICK
config THUMB2_KERNEL
bool "Compile the kernel in Thumb-2 mode" if !CPU_THUMBONLY
- depends on (CPU_V7 || CPU_V7M) && !CPU_V6 && !CPU_V6K
+ depends on (CPU_V7 || CPU_V7VE || CPU_V7M) && !CPU_V6 && !CPU_V6K
default y if CPU_THUMBONLY
select AEABI
select ARM_ASM_UNIFIED
@@ -1642,7 +1648,7 @@ config AEABI
config ARM_PATCH_UIDIV
bool "Runtime patch calls to __aeabi_{u}idiv() with udiv/sdiv"
- depends on CPU_V7 && !XIP_KERNEL && AEABI
+ depends on CPU_32v7 && !XIP_KERNEL && AEABI
help
Some v7 CPUs have support for the udiv and sdiv instructions
that can be used in place of calls to __aeabi_uidiv and __aeabi_idiv
@@ -1843,7 +1849,7 @@ config XEN_DOM0
config XEN
bool "Xen guest support on ARM"
depends on ARM && AEABI && OF
- depends on CPU_V7 && !CPU_V6
+ depends on (CPU_V7 || CPU_V7VE) && !CPU_V6
depends on !GENERIC_ATOMIC64
depends on MMU
select ARCH_DMA_ADDR_T_64BIT
@@ -2132,7 +2138,7 @@ config FPE_FASTFPE
config VFP
bool "VFP-format floating point maths"
- depends on CPU_V6 || CPU_V6K || CPU_ARM926T || CPU_V7 || CPU_FEROCEON
+ depends on CPU_V6 || CPU_V6K || CPU_ARM926T || CPU_V7 || CPU_V7VE || CPU_FEROCEON
help
Say Y to include VFP support code in the kernel. This is needed
if your hardware includes a VFP unit.
@@ -2145,11 +2151,11 @@ config VFP
config VFPv3
bool
depends on VFP
- default y if CPU_V7
+ default y if CPU_V7 || CPU_V7VE
config NEON
bool "Advanced SIMD (NEON) Extension support"
- depends on VFPv3 && CPU_V7
+ depends on VFPv3 && (CPU_V7 || CPU_V7VE)
help
Say Y to include support code for NEON, the ARMv7 Advanced SIMD
Extension.
@@ -2174,7 +2180,7 @@ source "kernel/power/Kconfig"
config ARCH_SUSPEND_POSSIBLE
depends on CPU_ARM920T || CPU_ARM926T || CPU_FEROCEON || CPU_SA1100 || \
- CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7M || CPU_XSC3 || CPU_XSCALE || CPU_MOHAWK
+ CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7M || CPU_V7VE || CPU_XSC3 || CPU_XSCALE || CPU_MOHAWK
def_bool y
config ARM_CPU_SUSPEND
diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
index aed66d5df7f1..aa04be6b29b9 100644
--- a/arch/arm/Kconfig-nommu
+++ b/arch/arm/Kconfig-nommu
@@ -53,7 +53,7 @@ config REMAP_VECTORS_TO_RAM
config ARM_MPU
bool 'Use the ARM v7 PMSA Compliant MPU'
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
default y
help
Some ARM systems without an MMU have instead a Memory Protection
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 2c2b28ee4811..c553862e26c8 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -67,6 +67,7 @@ KBUILD_CFLAGS += $(call cc-option,-fno-ipa-sra)
# macro, but instead defines a whole series of macros which makes
# testing for a specific architecture or later rather impossible.
arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m
+arch-$(CONFIG_CPU_32v7VE) =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7ve,-mcpu=cortex-a15)
arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
# Only override the compiler option if ARMv6. The ARMv6K extensions are
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 06e983f59980..e51ef838947c 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -26,7 +26,7 @@
#if defined(CONFIG_DEBUG_ICEDCC)
-#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K) || defined(CONFIG_CPU_V7)
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K) || defined(CONFIG_CPU_V7) || defined (CONFIG_CPU_V7VE)
.macro loadsp, rb, tmp
.endm
.macro writeb, ch, rb
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index d4f891f56996..0e0300c25008 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -29,7 +29,7 @@ extern void error(char *x);
#ifdef CONFIG_DEBUG_ICEDCC
-#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K) || defined(CONFIG_CPU_V7)
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K) || defined(CONFIG_CPU_V7) || defined(CONFIG_CPU_V7VE)
static void icedcc_putc(int ch)
{
diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index d5525bfc7e3e..ff5e71c45809 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -193,7 +193,7 @@ extern void copy_to_user_page(struct vm_area_struct *, struct page *,
* Optimized __flush_icache_all for the common cases. Note that UP ARMv7
* will fall through to use __flush_icache_all_generic.
*/
-#if (defined(CONFIG_CPU_V7) && \
+#if ((defined(CONFIG_CPU_V7) || defined(CONFIG_CPU_V7VE)) && \
(defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K))) || \
defined(CONFIG_SMP_ON_UP)
#define __flush_icache_preferred __cpuc_flush_icache_all
diff --git a/arch/arm/include/asm/glue-cache.h b/arch/arm/include/asm/glue-cache.h
index cab07f69382d..4a2f076dbcc3 100644
--- a/arch/arm/include/asm/glue-cache.h
+++ b/arch/arm/include/asm/glue-cache.h
@@ -109,7 +109,7 @@
# endif
#endif
-#if defined(CONFIG_CPU_V7)
+#if defined(CONFIG_CPU_V7) || defined(CONFIG_CPU_V7VE)
# ifdef _CACHE
# define MULTI_CACHE 1
# else
diff --git a/arch/arm/include/asm/glue-proc.h b/arch/arm/include/asm/glue-proc.h
index 74be7c22035a..345a32137117 100644
--- a/arch/arm/include/asm/glue-proc.h
+++ b/arch/arm/include/asm/glue-proc.h
@@ -239,7 +239,7 @@
# endif
#endif
-#ifdef CONFIG_CPU_V7
+#if defined(CONFIG_CPU_V7) || defined(CONFIG_CPU_V7VE)
/*
* Cortex-A9 needs a different suspend/resume function, so we need
* multiple CPU support for ARMv7 anyway.
diff --git a/arch/arm/include/asm/switch_to.h b/arch/arm/include/asm/switch_to.h
index 12ebfcc1d539..79fd3fc09d45 100644
--- a/arch/arm/include/asm/switch_to.h
+++ b/arch/arm/include/asm/switch_to.h
@@ -9,7 +9,7 @@
* to ensure that the maintenance completes in case we migrate to another
* CPU.
*/
-#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP) && defined(CONFIG_CPU_V7)
+#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP) && (defined(CONFIG_CPU_V7) || defined(CONFIG_CPU_V7VE))
#define __complete_pending_tlbi() dsb(ish)
#else
#define __complete_pending_tlbi()
diff --git a/arch/arm/include/debug/icedcc.S b/arch/arm/include/debug/icedcc.S
index 43afcb021fa3..6b3b2d2f3694 100644
--- a/arch/arm/include/debug/icedcc.S
+++ b/arch/arm/include/debug/icedcc.S
@@ -14,7 +14,7 @@
.macro addruart, rp, rv, tmp
.endm
-#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K) || defined(CONFIG_CPU_V7)
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K) || defined(CONFIG_CPU_V7) || defined(CONFIG_CPU_V7VE)
.macro senduart, rd, rx
mcr p14, 0, \rd, c0, c5, 0
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 3ce377f7251f..317de38c357e 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -504,7 +504,7 @@ __und_usr:
__und_usr_thumb:
@ Thumb instruction
sub r4, r2, #2 @ First half of thumb instr at LR - 2
-#if CONFIG_ARM_THUMB && __LINUX_ARM_ARCH__ >= 6 && CONFIG_CPU_V7
+#if CONFIG_ARM_THUMB && __LINUX_ARM_ARCH__ >= 6 && (CONFIG_CPU_V7 || CONFIG_CPU_V7VE)
/*
* Thumb-2 instruction handling. Note that because pre-v6 and >= v6 platforms
* can never be supported in a single kernel, this code is not applicable at
@@ -549,7 +549,7 @@ ARM_BE8(rev16 r0, r0) @ little endian instruction
.arch armv6
#endif
#endif /* __LINUX_ARM_ARCH__ < 7 */
-#else /* !(CONFIG_ARM_THUMB && __LINUX_ARM_ARCH__ >= 6 && CONFIG_CPU_V7) */
+#else /* !(CONFIG_ARM_THUMB && __LINUX_ARM_ARCH__ >= 6 && (CONFIG_CPU_V7 || CONFIG_CPU_V7VE)) */
b __und_usr_fault_16
#endif
UNWIND(.fnend)
@@ -565,7 +565,7 @@ ENDPROC(__und_usr)
.popsection
.pushsection __ex_table,"a"
.long 1b, 4b
-#if CONFIG_ARM_THUMB && __LINUX_ARM_ARCH__ >= 6 && CONFIG_CPU_V7
+#if CONFIG_ARM_THUMB && __LINUX_ARM_ARCH__ >= 6 && (CONFIG_CPU_V7 || CONFIG_CPU_V7VE)
.long 2b, 4b
.long 3b, 4b
#endif
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 126dc679b230..6c3c4b269e90 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -16,7 +16,7 @@
* counter and all 4 performance counters together can be reset separately.
*/
-#ifdef CONFIG_CPU_V7
+#if defined(CONFIG_CPU_V7) || defined(CONFIG_CPU_V7VE)
#include <asm/cp15.h>
#include <asm/cputype.h>
@@ -1900,4 +1900,4 @@ static int __init register_armv7_pmu_driver(void)
return platform_driver_register(&armv7_pmu_driver);
}
device_initcall(register_armv7_pmu_driver);
-#endif /* CONFIG_CPU_V7 */
+#endif /* CONFIG_CPU_V7 || CONFIG_CPU_V7VE */
diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index 95a000515e43..ea62ada144b1 100644
--- a/arch/arm/kvm/Kconfig
+++ b/arch/arm/kvm/Kconfig
@@ -5,7 +5,7 @@
source "virt/kvm/Kconfig"
menuconfig VIRTUALIZATION
- bool "Virtualization"
+ bool "Virtualization" if CPU_V7VE
---help---
Say Y here to get to see options for using your Linux host to run
other operating systems inside virtual machines (guests).
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c21941349b3e..e4ff161da98f 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -407,6 +407,21 @@ config CPU_V7M
select CPU_PABRT_LEGACY
select CPU_THUMBONLY
+# ARMv7ve
+config CPU_V7VE
+ bool "Support ARM V7 processor w/ virtualization extensions" if (!ARCH_MULTIPLATFORM || ARCH_MULTI_V7VE) && (ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX)
+ select CPU_32v6K
+ select CPU_32v7VE
+ select CPU_ABRT_EV7
+ select CPU_CACHE_V7
+ select CPU_CACHE_VIPT
+ select CPU_COPY_V6 if MMU
+ select CPU_CP15_MMU if MMU
+ select CPU_CP15_MPU if !MMU
+ select CPU_HAS_ASID if MMU
+ select CPU_PABRT_V7
+ select CPU_TLB_V7 if MMU
+
config CPU_THUMBONLY
bool
# There are no CPUs available with MMU that don't implement an ARM ISA:
@@ -450,6 +465,9 @@ config CPU_32v6K
config CPU_32v7
bool
+config CPU_32v7VE
+ bool
+
config CPU_32v7M
bool
@@ -626,8 +644,7 @@ comment "Processor Features"
config ARM_LPAE
bool "Support for the Large Physical Address Extension"
- depends on MMU && CPU_32v7 && !CPU_32v6 && !CPU_32v5 && \
- !CPU_32v4 && !CPU_32v3
+ depends on MMU && CPU_32v7VE
help
Say Y if you have an ARMv7 processor supporting the LPAE page
table format and you would like to access memory beyond the
@@ -652,7 +669,7 @@ config ARM_THUMB
CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || \
CPU_ARM1020 || CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \
CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || CPU_V6K || \
- CPU_V7 || CPU_FEROCEON || CPU_V7M
+ CPU_V7 || CPU_FEROCEON || CPU_V7M || CPU_V7VE
default y
help
Say Y if you want to include kernel support for running user space
@@ -666,7 +683,7 @@ config ARM_THUMB
config ARM_THUMBEE
bool "Enable ThumbEE CPU extension"
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
help
Say Y here if you have a CPU with the ThumbEE extension and code to
make use of it. Say N for code that can run on CPUs without ThumbEE.
@@ -674,7 +691,7 @@ config ARM_THUMBEE
config ARM_VIRT_EXT
bool
depends on MMU
- default y if CPU_V7
+ default y if CPU_V7VE
help
Enable the kernel to make use of the ARM Virtualization
Extensions to install hypervisors without run-time firmware
@@ -686,7 +703,7 @@ config ARM_VIRT_EXT
config SWP_EMULATE
bool "Emulate SWP/SWPB instructions" if !SMP
- depends on CPU_V7
+ depends on CPU_V7 || CPU_V7VE
default y if SMP
select HAVE_PROC_CPU if PROC_FS
help
@@ -723,7 +740,7 @@ config CPU_BIG_ENDIAN
config CPU_ENDIAN_BE8
bool
depends on CPU_BIG_ENDIAN
- default CPU_V6 || CPU_V6K || CPU_V7
+ default CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7VE
help
Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
@@ -789,7 +806,7 @@ config CPU_CACHE_ROUND_ROBIN
config CPU_BPREDICT_DISABLE
bool "Disable branch prediction"
- depends on CPU_ARM1020 || CPU_V6 || CPU_V6K || CPU_MOHAWK || CPU_XSC3 || CPU_V7 || CPU_FA526
+ depends on CPU_ARM1020 || CPU_V6 || CPU_V6K || CPU_MOHAWK || CPU_XSC3 || CPU_V7 || CPU_V7VE || CPU_FA526
help
Say Y here to disable branch prediction. If unsure, say N.
@@ -835,7 +852,7 @@ config KUSER_HELPERS
config VDSO
bool "Enable VDSO for acceleration of some system calls"
- depends on AEABI && MMU && CPU_V7
+ depends on AEABI && MMU && (CPU_V7 || CPU_V7VE)
default y if ARM_ARCH_TIMER
select GENERIC_TIME_VSYSCALL
help
@@ -984,7 +1001,7 @@ config CACHE_XSC3L2
config ARM_L1_CACHE_SHIFT_6
bool
- default y if CPU_V7
+ default y if CPU_V7 || CPU_V7VE
help
Setting ARM L1 cache line size to 64 Bytes.
@@ -994,10 +1011,10 @@ config ARM_L1_CACHE_SHIFT
default 5
config ARM_DMA_MEM_BUFFERABLE
- bool "Use non-cacheable memory for DMA" if (CPU_V6 || CPU_V6K) && !CPU_V7
+ bool "Use non-cacheable memory for DMA" if (CPU_V6 || CPU_V6K) && !(CPU_V7 || CPU_V7VE)
depends on !(MACH_REALVIEW_PB1176 || REALVIEW_EB_ARM11MP || \
MACH_REALVIEW_PB11MP)
- default y if CPU_V6 || CPU_V6K || CPU_V7
+ default y if CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7VE
help
Historically, the kernel has used strongly ordered mappings to
provide DMA coherent memory. With the advent of ARMv7, mapping
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 57c8df500e8c..4f542b29137c 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_CPU_FEROCEON) += proc-feroceon.o
obj-$(CONFIG_CPU_V6) += proc-v6.o
obj-$(CONFIG_CPU_V6K) += proc-v6.o
obj-$(CONFIG_CPU_V7) += proc-v7.o
+obj-$(CONFIG_CPU_V7VE) += proc-v7.o
obj-$(CONFIG_CPU_V7M) += proc-v7m.o
AFLAGS_proc-v6.o :=-Wa,-march=armv6
diff --git a/arch/arm/probes/kprobes/test-arm.c b/arch/arm/probes/kprobes/test-arm.c
index 8866aedfdea2..c2591b8b8718 100644
--- a/arch/arm/probes/kprobes/test-arm.c
+++ b/arch/arm/probes/kprobes/test-arm.c
@@ -192,7 +192,7 @@ void kprobe_arm_test_cases(void)
TEST_BF_R ("mov pc, r",0,2f,"")
TEST_BF_R ("add pc, pc, r",14,(2f-1f-8)*2,", asr #1")
TEST_BB( "sub pc, pc, #1b-2b+8")
-#if __LINUX_ARM_ARCH__ == 6 && !defined(CONFIG_CPU_V7)
+#if __LINUX_ARM_ARCH__ == 6 && !(defined(CONFIG_CPU_V7) || defined(CONFIG_CPU_V7VE))
TEST_BB( "sub pc, pc, #1b-2b+8-2") /* UNPREDICTABLE before and after ARMv6 */
#endif
TEST_BB_R( "sub pc, pc, r",14, 1f-2f+8,"")
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 0ebca8ba7bc4..33fa47dc03a8 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -17,7 +17,7 @@ config ARM_CCI400_COMMON
config ARM_CCI400_PMU
bool "ARM CCI400 PMU support"
- depends on (ARM && CPU_V7) || ARM64
+ depends on (ARM && (CPU_V7 || CPU_V7VE)) || ARM64
depends on PERF_EVENTS
select ARM_CCI400_COMMON
select ARM_CCI_PMU
@@ -28,7 +28,7 @@ config ARM_CCI400_PMU
config ARM_CCI400_PORT_CTRL
bool
- depends on ARM && OF && CPU_V7
+ depends on ARM && OF && (CPU_V7 || CPU_V7VE)
select ARM_CCI400_COMMON
help
Low level power management driver for CCI400 cache coherent
@@ -36,7 +36,7 @@ config ARM_CCI400_PORT_CTRL
config ARM_CCI500_PMU
bool "ARM CCI500 PMU support"
- depends on (ARM && CPU_V7) || ARM64
+ depends on (ARM && (CPU_V7 || CPU_V7VE)) || ARM64
depends on PERF_EVENTS
select ARM_CCI_PMU
help
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2015-11-24 11:40 +0100 |
| Message-ID | <qyjaX-6V9-39@gated-at.bofh.it> |
| In reply to | #1276172 |
On Tuesday 24 November 2015 00:53:49 Stephen Boyd wrote:
> On 11/23, Stephen Boyd wrote:
> > On 11/23, Arnd Bergmann wrote:
> > >
> > > Ok, thanks for the confirmation.
> > >
> > > Summarizing what we've found, I think we can get away with just
> > > introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE.
> > > Most CPUs fall clearly into one category or the other, and then
> > > we can allow LPAE to be selected for V7VE-only build but not
> > > for plain V7, and we can unconditionally build the kernel with
> > >
> > > arch-$(CONFIG_CPU_32v7VE) = -D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7ve,-march=armv7-a -mcpu=cortex-a15)
> > >
> >
> > This causes compiler spew for me:
> >
> > warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch
> >
> > Removing -march=armv7-a from there makes it quiet.
> >
> > Also, it's sort of feels wrong to have -mcpu in a place where
> > we're exclusively doing -march. Perhaps the fallback should be
> > bog standard -march=armv7-a? (or the fallback for that one
> > "-march=armv5t -Wa$(comma)-march=armv7-a")?
I suggested using -mcpu=cortex-a15 because there are old gcc versions
that don't know about -march=armv7ve or -march=armv7-a+idiv yet, but
that do understand -mcpu=cortex-a15. I might be misremembering the
exact options we want though, and we could now just decided that if
your gcc is too old, you get no idiv even if it supports that on
Cortex-A15.
> And adding CPU_V7VE causes a cascade of changes to wherever
> CPU_V7 is being used today. Here's the patch I currently have,
> without the platform changes:
Thanks a lot for looking into this. I think we can simplify a couple
of them, as long as we also fix all the platforms to have the correct
dependencies:
> @@ -1069,7 +1075,7 @@ config ARM_ERRATA_411920
>
> config ARM_ERRATA_430973
> bool "ARM errata: Stale prediction on replaced interworking branch"
> - depends on CPU_V7
> + depends on CPU_V7 || CPU_V7VE
> help
> This option enables the workaround for the 430973 Cortex-A8
> r1p* erratum. If a code sequence containing an ARM/Thumb
If it's a Cortex-A8 erratum, we don't need the "|| CPU_V7VE". Same for
a lot of the following errata.
> @@ -1246,7 +1252,7 @@ config ARM_ERRATA_775420
>
> config ARM_ERRATA_798181
> bool "ARM errata: TLBI/DSB failure on Cortex-A15"
> - depends on CPU_V7 && SMP
> + depends on (CPU_V7 || CPU_V7VE) && SMP
> help
> On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not
> adequately shooting down all use of the old entries. This
> @@ -1256,7 +1262,7 @@ config ARM_ERRATA_798181
>
> config ARM_ERRATA_773022
> bool "ARM errata: incorrect instructions may be executed from loop buffer"
> - depends on CPU_V7
> + depends on CPU_V7 || CPU_V7VE
> help
> This option enables the workaround for the 773022 Cortex-A15
> (up to r0p4) erratum. In certain rare sequences of code, the
And conversely, these will only need to depend on CPU_V7VE.
> @@ -1373,7 +1379,7 @@ config SMP_ON_UP
>
> config ARM_CPU_TOPOLOGY
> bool "Support cpu topology definition"
> - depends on SMP && CPU_V7
> + depends on SMP && (CPU_V7 || CPU_V7VE)
> default y
> help
> Support ARM cpu topology definition. The MPIDR register defines
Does topology make sense with Cortex-A5/A9 or Scorpion?
Otherwise it can also be V7VE-only.
> @@ -1417,7 +1423,7 @@ config HAVE_ARM_TWD
>
> config MCPM
> bool "Multi-Cluster Power Management"
> - depends on CPU_V7 && SMP
> + depends on (CPU_V7 || CPU_V7VE) && SMP
> help
> This option provides the common power management infrastructure
> for (multi-)cluster based systems, such as big.LITTLE based
> @@ -1434,7 +1440,7 @@ config MCPM_QUAD_CLUSTER
>
> config BIG_LITTLE
> bool "big.LITTLE support (Experimental)"
> - depends on CPU_V7 && SMP
> + depends on (CPU_V7 || CPU_V7VE) && SMP
> select MCPM
> help
> This option enables support selections for the big.LITTLE
multi-cluster and big.little are also V7VE-only by definition,
as pre-VE ARMv7 cores are all limited to one cluster.
> @@ -1642,7 +1648,7 @@ config AEABI
>
> config ARM_PATCH_UIDIV
> bool "Runtime patch calls to __aeabi_{u}idiv() with udiv/sdiv"
> - depends on CPU_V7 && !XIP_KERNEL && AEABI
> + depends on CPU_32v7 && !XIP_KERNEL && AEABI
> help
> Some v7 CPUs have support for the udiv and sdiv instructions
> that can be used in place of calls to __aeabi_uidiv and __aeabi_idiv
How about making this
depends on (CPU_V6 || CPU_V6K || CPU_V7) && CPU_V7VE
> @@ -1843,7 +1849,7 @@ config XEN_DOM0
> config XEN
> bool "Xen guest support on ARM"
> depends on ARM && AEABI && OF
> - depends on CPU_V7 && !CPU_V6
> + depends on (CPU_V7 || CPU_V7VE) && !CPU_V6
> depends on !GENERIC_ATOMIC64
> depends on MMU
> select ARCH_DMA_ADDR_T_64BIT
This is also V7VE-only. The !CPU_V6 check is there to avoid a compile-time
bug with some instructions that are V7-only. I think this should
be
depends on CPU_V7VE && !CPU_V6
> diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
> index aed66d5df7f1..aa04be6b29b9 100644
> --- a/arch/arm/Kconfig-nommu
> +++ b/arch/arm/Kconfig-nommu
> @@ -53,7 +53,7 @@ config REMAP_VECTORS_TO_RAM
>
> config ARM_MPU
> bool 'Use the ARM v7 PMSA Compliant MPU'
> - depends on CPU_V7
> + depends on CPU_V7 || CPU_V7VE
> default y
> help
> Some ARM systems without an MMU have instead a Memory Protection
Not sure about this one. It's strictly speaking for V7-R, and we don't have
a Kconfig option for that at all.
> diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
> index 95a000515e43..ea62ada144b1 100644
> --- a/arch/arm/kvm/Kconfig
> +++ b/arch/arm/kvm/Kconfig
> @@ -5,7 +5,7 @@
> source "virt/kvm/Kconfig"
>
> menuconfig VIRTUALIZATION
> - bool "Virtualization"
> + bool "Virtualization" if CPU_V7VE
> ---help---
> Say Y here to get to see options for using your Linux host to run
> other operating systems inside virtual machines (guests).
We already have 'depends on ARM_VIRT_EXT' here. I guess we should instead
add the dependency on CPU_V7VE there.
> @@ -626,8 +644,7 @@ comment "Processor Features"
>
> config ARM_LPAE
> bool "Support for the Large Physical Address Extension"
> - depends on MMU && CPU_32v7 && !CPU_32v6 && !CPU_32v5 && \
> - !CPU_32v4 && !CPU_32v3
> + depends on MMU && CPU_32v7VE
This looks wrong, we have to ensure at least that CPU_32v6 and CPU_32v7
are not set, though we can get rid of the v5/v4/v3 checks.
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 0ebca8ba7bc4..33fa47dc03a8 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -17,7 +17,7 @@ config ARM_CCI400_COMMON
>
> config ARM_CCI400_PMU
> bool "ARM CCI400 PMU support"
> - depends on (ARM && CPU_V7) || ARM64
> + depends on (ARM && (CPU_V7 || CPU_V7VE)) || ARM64
> depends on PERF_EVENTS
> select ARM_CCI400_COMMON
> select ARM_CCI_PMU
> @@ -28,7 +28,7 @@ config ARM_CCI400_PMU
>
> config ARM_CCI400_PORT_CTRL
> bool
> - depends on ARM && OF && CPU_V7
> + depends on ARM && OF && (CPU_V7 || CPU_V7VE)
> select ARM_CCI400_COMMON
> help
> Low level power management driver for CCI400 cache coherent
> @@ -36,7 +36,7 @@ config ARM_CCI400_PORT_CTRL
>
> config ARM_CCI500_PMU
> bool "ARM CCI500 PMU support"
> - depends on (ARM && CPU_V7) || ARM64
> + depends on (ARM && (CPU_V7 || CPU_V7VE)) || ARM64
> depends on PERF_EVENTS
> select ARM_CCI_PMU
> help
Pretty sure that these only work with ARMv7VE capable cores, the older ones only
have one cluster.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-11-24 11:50 +0100 |
| Subject | Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions |
| Message-ID | <qyjkB-6ZF-5@gated-at.bofh.it> |
| In reply to | #1276303 |
On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote: > I suggested using -mcpu=cortex-a15 because there are old gcc versions > that don't know about -march=armv7ve or -march=armv7-a+idiv yet, but > that do understand -mcpu=cortex-a15. That's not all. The bigger problem is that there are toolchains out there which accept these options, but do _not_ support IDIV in either ARM or Thumb mode. I'm afraid that makes it impossible to add this feature to the mainline kernel in this form: we need to run a test build to check that -march=armv7ve or what-not really does work through both GCC and GAS. Given that Ubuntu 14.04 LTS suffers with this, it's something that must be resolved. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-11-24 13:20 +0100 |
| Message-ID | <qykJI-7YL-25@gated-at.bofh.it> |
| In reply to | #1276307 |
Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote: >> I suggested using -mcpu=cortex-a15 because there are old gcc versions >> that don't know about -march=armv7ve or -march=armv7-a+idiv yet, but >> that do understand -mcpu=cortex-a15. > > That's not all. The bigger problem is that there are toolchains out > there which accept these options, but do _not_ support IDIV in either > ARM or Thumb mode. I'm afraid that makes it impossible to add this > feature to the mainline kernel in this form: we need to run a test > build to check that -march=armv7ve or what-not really does work > through both GCC and GAS. If the compiler accepts the option but doesn't actually emit any div instructions, is there any real harm? -- Måns Rullgård mans@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-11-24 13:30 +0100 |
| Message-ID | <qykTn-82V-7@gated-at.bofh.it> |
| In reply to | #1276377 |
Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > On Tue, Nov 24, 2015 at 12:10:02PM +0000, Måns Rullgård wrote: >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes: >> >> > On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote: >> >> I suggested using -mcpu=cortex-a15 because there are old gcc versions >> >> that don't know about -march=armv7ve or -march=armv7-a+idiv yet, but >> >> that do understand -mcpu=cortex-a15. >> > >> > That's not all. The bigger problem is that there are toolchains out >> > there which accept these options, but do _not_ support IDIV in either >> > ARM or Thumb mode. I'm afraid that makes it impossible to add this >> > feature to the mainline kernel in this form: we need to run a test >> > build to check that -march=armv7ve or what-not really does work >> > through both GCC and GAS. >> >> If the compiler accepts the option but doesn't actually emit any div >> instructions, is there any real harm? > > That's not what I've found. I've found that asking the assembler > to accept idiv instructions appears to be ignored, which is something > completely different. > > Further to this, what it comes down to is the stupid idea that the > compiler should embed .arch / .cpu in the assembly output, which has > the effect of overriding the command line arguments given to it via > -Wa. So, giving -Wa,-mcpu=cortex-a15 is a total no-op, because the > first thing in the assembly output is: > > .arch armv7-a > > which kills off any attempt to set the assembly level ISA from the > command line. Oh, you mean the compiler knows about the instructions but the assembler doesn't or isn't passed the right options. It's infuriating when that happens. -- Måns Rullgård mans@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-11-24 15:10 +0100 |
| Message-ID | <qyms9-FQ-1@gated-at.bofh.it> |
| In reply to | #1276381 |
Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > On Tue, Nov 24, 2015 at 12:29:06PM +0000, Måns Rullgård wrote: >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes: >> >> > On Tue, Nov 24, 2015 at 12:10:02PM +0000, Måns Rullgård wrote: >> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes: >> >> >> >> > On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote: >> >> >> I suggested using -mcpu=cortex-a15 because there are old gcc versions >> >> >> that don't know about -march=armv7ve or -march=armv7-a+idiv yet, but >> >> >> that do understand -mcpu=cortex-a15. >> >> > >> >> > That's not all. The bigger problem is that there are toolchains out >> >> > there which accept these options, but do _not_ support IDIV in either >> >> > ARM or Thumb mode. I'm afraid that makes it impossible to add this >> >> > feature to the mainline kernel in this form: we need to run a test >> >> > build to check that -march=armv7ve or what-not really does work >> >> > through both GCC and GAS. >> >> >> >> If the compiler accepts the option but doesn't actually emit any div >> >> instructions, is there any real harm? >> > >> > That's not what I've found. I've found that asking the assembler >> > to accept idiv instructions appears to be ignored, which is something >> > completely different. >> > >> > Further to this, what it comes down to is the stupid idea that the >> > compiler should embed .arch / .cpu in the assembly output, which has >> > the effect of overriding the command line arguments given to it via >> > -Wa. So, giving -Wa,-mcpu=cortex-a15 is a total no-op, because the >> > first thing in the assembly output is: >> > >> > .arch armv7-a >> > >> > which kills off any attempt to set the assembly level ISA from the >> > command line. >> >> Oh, you mean the compiler knows about the instructions but the assembler >> doesn't or isn't passed the right options. It's infuriating when that >> happens. > > No, that isn't what I meant. Then what do you mean? The compiler either emits the instructions or it doesn't. If it doesn't, what the assembler accepts is irrelevant. -- Måns Rullgård mans@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-11-24 15:10 +0100 |
| Subject | Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions |
| Message-ID | <qyms9-FQ-3@gated-at.bofh.it> |
| In reply to | #1276381 |
On Tue, Nov 24, 2015 at 12:29:06PM +0000, Måns Rullgård wrote: > Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > > > On Tue, Nov 24, 2015 at 12:10:02PM +0000, Måns Rullgård wrote: > >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > >> > >> > On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote: > >> >> I suggested using -mcpu=cortex-a15 because there are old gcc versions > >> >> that don't know about -march=armv7ve or -march=armv7-a+idiv yet, but > >> >> that do understand -mcpu=cortex-a15. > >> > > >> > That's not all. The bigger problem is that there are toolchains out > >> > there which accept these options, but do _not_ support IDIV in either > >> > ARM or Thumb mode. I'm afraid that makes it impossible to add this > >> > feature to the mainline kernel in this form: we need to run a test > >> > build to check that -march=armv7ve or what-not really does work > >> > through both GCC and GAS. > >> > >> If the compiler accepts the option but doesn't actually emit any div > >> instructions, is there any real harm? > > > > That's not what I've found. I've found that asking the assembler > > to accept idiv instructions appears to be ignored, which is something > > completely different. > > > > Further to this, what it comes down to is the stupid idea that the > > compiler should embed .arch / .cpu in the assembly output, which has > > the effect of overriding the command line arguments given to it via > > -Wa. So, giving -Wa,-mcpu=cortex-a15 is a total no-op, because the > > first thing in the assembly output is: > > > > .arch armv7-a > > > > which kills off any attempt to set the assembly level ISA from the > > command line. > > Oh, you mean the compiler knows about the instructions but the assembler > doesn't or isn't passed the right options. It's infuriating when that > happens. No, that isn't what I meant. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-11-24 13:30 +0100 |
| Subject | Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions |
| Message-ID | <qykTn-82V-9@gated-at.bofh.it> |
| In reply to | #1276377 |
On Tue, Nov 24, 2015 at 12:10:02PM +0000, Måns Rullgård wrote: > Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > > > On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote: > >> I suggested using -mcpu=cortex-a15 because there are old gcc versions > >> that don't know about -march=armv7ve or -march=armv7-a+idiv yet, but > >> that do understand -mcpu=cortex-a15. > > > > That's not all. The bigger problem is that there are toolchains out > > there which accept these options, but do _not_ support IDIV in either > > ARM or Thumb mode. I'm afraid that makes it impossible to add this > > feature to the mainline kernel in this form: we need to run a test > > build to check that -march=armv7ve or what-not really does work > > through both GCC and GAS. > > If the compiler accepts the option but doesn't actually emit any div > instructions, is there any real harm? That's not what I've found. I've found that asking the assembler to accept idiv instructions appears to be ignored, which is something completely different. Further to this, what it comes down to is the stupid idea that the compiler should embed .arch / .cpu in the assembly output, which has the effect of overriding the command line arguments given to it via -Wa. So, giving -Wa,-mcpu=cortex-a15 is a total no-op, because the first thing in the assembly output is: .arch armv7-a which kills off any attempt to set the assembly level ISA from the command line. It does appear after all that Ubuntu 14.04 does support sdiv/idiv with -mcpu=cortex-a15, but there is no -march=armv7ve. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-11-24 11:50 +0100 |
| Subject | Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions |
| Message-ID | <qyjkB-6ZF-13@gated-at.bofh.it> |
| In reply to | #1276172 |
On Tue, Nov 24, 2015 at 12:53:49AM -0800, Stephen Boyd wrote: > On 11/23, Stephen Boyd wrote: > > On 11/23, Arnd Bergmann wrote: > > > > > > Ok, thanks for the confirmation. > > > > > > Summarizing what we've found, I think we can get away with just > > > introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE. > > > Most CPUs fall clearly into one category or the other, and then > > > we can allow LPAE to be selected for V7VE-only build but not > > > for plain V7, and we can unconditionally build the kernel with > > > > > > arch-$(CONFIG_CPU_32v7VE) = -D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7ve,-march=armv7-a -mcpu=cortex-a15) > > > > > > > This causes compiler spew for me: > > > > warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch > > > > Removing -march=armv7-a from there makes it quiet. > > > > Also, it's sort of feels wrong to have -mcpu in a place where > > we're exclusively doing -march. Perhaps the fallback should be > > bog standard -march=armv7-a? (or the fallback for that one > > "-march=armv5t -Wa$(comma)-march=armv7-a")? > > > > And adding CPU_V7VE causes a cascade of changes to wherever > CPU_V7 is being used today. Here's the patch I currently have, > without the platform changes: > > ---8<---- > arch/arm/Kconfig | 68 +++++++++++++++++++++----------------- > arch/arm/Kconfig-nommu | 2 +- > arch/arm/Makefile | 1 + > arch/arm/boot/compressed/head.S | 2 +- > arch/arm/boot/compressed/misc.c | 2 +- > arch/arm/include/asm/cacheflush.h | 2 +- > arch/arm/include/asm/glue-cache.h | 2 +- > arch/arm/include/asm/glue-proc.h | 2 +- > arch/arm/include/asm/switch_to.h | 2 +- > arch/arm/include/debug/icedcc.S | 2 +- > arch/arm/kernel/entry-armv.S | 6 ++-- > arch/arm/kernel/perf_event_v7.c | 4 +-- > arch/arm/kvm/Kconfig | 2 +- > arch/arm/mm/Kconfig | 41 ++++++++++++++++------- > arch/arm/mm/Makefile | 1 + > arch/arm/probes/kprobes/test-arm.c | 2 +- > drivers/bus/Kconfig | 6 ++-- > 17 files changed, 86 insertions(+), 61 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 9e2d2adcc85b..ccd0d5553d38 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -32,7 +32,7 @@ config ARM > select HANDLE_DOMAIN_IRQ > select HARDIRQS_SW_RESEND > select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT) > - select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6 > + select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7 || CPU_32_v7VE) && !CPU_32v6 > select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 > select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 > select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT) > @@ -46,12 +46,12 @@ config ARM > select HAVE_DMA_ATTRS > select HAVE_DMA_CONTIGUOUS if MMU > select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) && !CPU_ENDIAN_BE32 > - select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU > + select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7VE) && MMU > select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL) > select HAVE_FUNCTION_GRAPH_TRACER if (!THUMB2_KERNEL) > select HAVE_FUNCTION_TRACER if (!XIP_KERNEL) > select HAVE_GENERIC_DMA_COHERENT > - select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7)) > + select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7VE)) > select HAVE_IDE if PCI || ISA || PCMCIA > select HAVE_IRQ_TIME_ACCOUNTING > select HAVE_KERNEL_GZIP > @@ -805,6 +805,12 @@ config ARCH_MULTI_V7 > select CPU_V7 > select HAVE_SMP > > +config ARCH_MULTI_V7VE > + bool "ARMv7 w/ virtualization extensions based platforms (Cortex-A, PJ4-MP, Krait)" > + select ARCH_MULTI_V6_V7 > + select CPU_V7VE > + select HAVE_SMP > + > config ARCH_MULTI_V6_V7 > bool > select MIGHT_HAVE_CACHE_L2X0 > @@ -1069,7 +1075,7 @@ config ARM_ERRATA_411920 > > config ARM_ERRATA_430973 > bool "ARM errata: Stale prediction on replaced interworking branch" > - depends on CPU_V7 > + depends on CPU_V7 || CPU_V7VE NAK on all this. The fact that you're having to add CPU_V7VE at all sites which have CPU_V7 shows that this is a totally broken way of approaching this. Make CPU_V7VE be an _add-on_ to CPU_V7. In other words, when CPU_V7VE is enabled, CPU_V7 should also be enabled, just like we do for CPU_V6K. Note that v7M is different because that's not an add-on feature, it's a different CPU class from (what should be) v7A. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stephen Boyd <sboyd@codeaurora.org> |
|---|---|
| Date | 2015-11-24 21:10 +0100 |
| Subject | Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions |
| Message-ID | <qys4y-4mv-7@gated-at.bofh.it> |
| In reply to | #1276309 |
On 11/24, Russell King - ARM Linux wrote: > On Tue, Nov 24, 2015 at 12:53:49AM -0800, Stephen Boyd wrote: > > > > And adding CPU_V7VE causes a cascade of changes to wherever > > CPU_V7 is being used today. Here's the patch I currently have, > > without the platform changes: > > @@ -1069,7 +1075,7 @@ config ARM_ERRATA_411920 > > > > config ARM_ERRATA_430973 > > bool "ARM errata: Stale prediction on replaced interworking branch" > > - depends on CPU_V7 > > + depends on CPU_V7 || CPU_V7VE > > NAK on all this. The fact that you're having to add CPU_V7VE at all > sites which have CPU_V7 shows that this is a totally broken way of > approaching this. > > Make CPU_V7VE be an _add-on_ to CPU_V7. In other words, when CPU_V7VE > is enabled, CPU_V7 should also be enabled, just like we do for CPU_V6K. > > Note that v7M is different because that's not an add-on feature, it's > a different CPU class from (what should be) v7A. > Ok. Presumably the order of arch-$(CONFIG) lines in the Makefile are done in an order to allow the build to degrade to the lowest common denominator among architecture support. CPU_V7 selects CPU_32v7 and we're using that config to select -march=armv7-a in the Makefile. The patch currently uses CPU_32v7VE to select -march=armv7ve. If CPU_V7VE selects CPU_V7 we'll never be able to use -march=armv7ve because CPU_V7 will be selecting CPU_32v7 and that will come after CPU_32v7VE in the Makefile. 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. I suppose we can fix this by making CPU_V7 a hidden option? Or I need some coffee because I'm missing something. ---8<---- diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ccd0d5553d38..158ffb983387 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -626,7 +626,7 @@ config ARCH_SHMOBILE_LEGACY select ARCH_SHMOBILE select ARM_PATCH_PHYS_VIRT if MMU select CLKDEV_LOOKUP - select CPU_V7 + select CPU_V7_NOEXT select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU if SMP select HAVE_ARM_TWD if SMP @@ -802,7 +802,7 @@ config ARCH_MULTI_V7 bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)" default y select ARCH_MULTI_V6_V7 - select CPU_V7 + select CPU_V7_NOEXT select HAVE_SMP config ARCH_MULTI_V7VE diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig index 9ab8932403e5..7e1b36400e14 100644 --- a/arch/arm/mach-prima2/Kconfig +++ b/arch/arm/mach-prima2/Kconfig @@ -25,7 +25,7 @@ config ARCH_ATLAS7 bool "CSR SiRFSoC ATLAS7 ARM Cortex A7 Platform" default y select ARM_GIC - select CPU_V7 + select CPU_V7_NOEXT select HAVE_ARM_SCU if SMP select HAVE_SMP help diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig index 565925f37dc5..7e084c34071c 100644 --- a/arch/arm/mach-realview/Kconfig +++ b/arch/arm/mach-realview/Kconfig @@ -24,7 +24,7 @@ config MACH_REALVIEW_EB config REALVIEW_EB_A9MP bool "Support Multicore Cortex-A9 Tile" depends on MACH_REALVIEW_EB - select CPU_V7 + select CPU_V7_NOEXT select HAVE_ARM_SCU if SMP select HAVE_ARM_TWD if SMP select HAVE_SMP @@ -93,7 +93,7 @@ config REALVIEW_PB1176_SECURE_FLASH config MACH_REALVIEW_PBA8 bool "Support RealView(R) Platform Baseboard for Cortex(tm)-A8 platform" select ARM_GIC - select CPU_V7 + select CPU_V7_NOEXT select HAVE_PATA_PLATFORM help Include support for the ARM(R) RealView Platform Baseboard for diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index e4ff161da98f..02a887235155 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -350,11 +350,11 @@ config CPU_FEROCEON_OLD_ID config CPU_PJ4 bool select ARM_THUMBEE - select CPU_V7 + select CPU_V7_NOEXT config CPU_PJ4B bool - select CPU_V7 + select CPU_V7_NOEXT # ARMv6 config CPU_V6 @@ -383,11 +383,9 @@ config CPU_V6K select CPU_PABRT_V6 select CPU_TLB_V6 if MMU -# ARMv7 config CPU_V7 - bool "Support ARM V7 processor" if (!ARCH_MULTIPLATFORM || ARCH_MULTI_V7) && (ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX) + bool select CPU_32v6K - select CPU_32v7 select CPU_ABRT_EV7 select CPU_CACHE_V7 select CPU_CACHE_VIPT @@ -398,6 +396,12 @@ config CPU_V7 select CPU_PABRT_V7 select CPU_TLB_V7 if MMU +# ARMv7 +config CPU_V7_NOEXT + bool "Support ARM V7 processor" if (!ARCH_MULTIPLATFORM || ARCH_MULTI_V7) && (ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX) + select CPU_32v7 + select CPU_V7 + # ARMv7M config CPU_V7M bool @@ -410,17 +414,8 @@ config CPU_V7M # ARMv7ve config CPU_V7VE bool "Support ARM V7 processor w/ virtualization extensions" if (!ARCH_MULTIPLATFORM || ARCH_MULTI_V7VE) && (ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX) - select CPU_32v6K select CPU_32v7VE - select CPU_ABRT_EV7 - select CPU_CACHE_V7 - select CPU_CACHE_VIPT - select CPU_COPY_V6 if MMU - select CPU_CP15_MMU if MMU - select CPU_CP15_MPU if !MMU - select CPU_HAS_ASID if MMU - select CPU_PABRT_V7 - select CPU_TLB_V7 if MMU + select CPU_V7 config CPU_THUMBONLY bool -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-11-24 21:40 +0100 |
| Subject | Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions |
| Message-ID | <qysxA-4yx-7@gated-at.bofh.it> |
| In reply to | #1276735 |
On Tue, Nov 24, 2015 at 12:07:30PM -0800, Stephen Boyd wrote: > Ok. Presumably the order of arch-$(CONFIG) lines in the Makefile > are done in an order to allow the build to degrade to the lowest > common denominator among architecture support. Correct. Make processes the directives in the order listed in the makefile, which means that a variable final value results from its last assignment. > CPU_V7 selects > CPU_32v7 and we're using that config to select -march=armv7-a in > the Makefile. The patch currently uses CPU_32v7VE to select > -march=armv7ve. If CPU_V7VE selects CPU_V7 we'll never be able to > use -march=armv7ve because CPU_V7 will be selecting CPU_32v7 and > that will come after CPU_32v7VE in the Makefile. Right, but look at how the V6K stuff is handled: arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6) # Only override the compiler option if ARMv6. The ARMv6K extensions are # always available in ARMv7 ifeq ($(CONFIG_CPU_32v6),y) arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,-march=armv5t -Wa$(comma)-march=armv6k) endif 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) > 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... -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2015-11-24 22:20 +0100 |
| Message-ID | <qytai-52D-3@gated-at.bofh.it> |
| In reply to | #1276752 |
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-11-24 11:40 +0100 |
| Subject | Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions |
| Message-ID | <qyjaX-6V9-43@gated-at.bofh.it> |
| In reply to | #1275981 |
On Mon, Nov 23, 2015 at 04:13:06PM -0800, Stephen Boyd wrote: > On 11/23, Arnd Bergmann wrote: > > > > Ok, thanks for the confirmation. > > > > Summarizing what we've found, I think we can get away with just > > introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE. > > Most CPUs fall clearly into one category or the other, and then > > we can allow LPAE to be selected for V7VE-only build but not > > for plain V7, and we can unconditionally build the kernel with > > > > arch-$(CONFIG_CPU_32v7VE) = -D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7ve,-march=armv7-a -mcpu=cortex-a15) > > > > This causes compiler spew for me: > > warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch > > Removing -march=armv7-a from there makes it quiet. > > Also, it's sort of feels wrong to have -mcpu in a place where > we're exclusively doing -march. Perhaps the fallback should be > bog standard -march=armv7-a? (or the fallback for that one > "-march=armv5t -Wa$(comma)-march=armv7-a")? How it was explained to me years ago is that -march selects the instruction set, -mtune selects the instruction scheduling, and -mcpu selects both. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2015-11-21 21:50 +0100 |
| Message-ID | <qxngC-1ZX-5@gated-at.bofh.it> |
| In reply to | #1274584 |
On Friday 20 November 2015 17:23:14 Stephen Boyd wrote: > This is a respin of a patch series from about a year ago[1]. I realized > that we already had most of the code in recordmcount to figure out > where we make calls to particular functions, so recording where > we make calls to the integer division functions should be easy enough > to add support for in the same codepaths. Looking back on the thread > it seems like Mans was thinking along the same lines, although it wasn't > obvious to me back then or even over the last few days when I wrote this. Shouldn't we start by allowing to build the kernel for -march=armv7ve on platforms that allow it? That would seem like a simpler change and likely generate better code for most people, except when you actually care about running the same binary kernel on older platforms. I tried to get a complete list of CPU cores with idiv, lpae and virtualization support at some point, but I don't remember the details for all Qualcomm and Marvell cores any more, to create the complete configuration matrix. IIRC, all CPUs that support virtualization also do lpae (they have to) and all CPUs that do lpae also do idiv, but the opposite is not true. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web