[RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

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.

quoted

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