[PATCH v2] ARM: Define wfi() macro for v6 processors

On Tuesday 08 February 2011, Dave Martin wrote:

I guess there are two problems we're trying to solve here:

1) a lowest-common denominator implementation of things like wfi(),
for use in common code.  This must be based on __LINUX_ARM_ARCH__
(which IIUC gives the lowest arch supported by all the CPUs being
built for -- am I correct?)
2) definitions for specific CPUs, for non-generic code which may be
bundled together in a single kernel build.

For (1), We can sensibly try to define a generic macro.  If building
for ARMv6 and ARMv7 CPUs in the same kernel, then we have to use the
lowest-common-denominator definition, i.e., the MCR form.  For ARMv7,
we can use WFI.

But that doesn't work if you build a combined v5/v6/v7 kernel, because
v5 supports neither form, right? I think to do that, it needs the
same kind of abstraction that we have for a number of other things
like cache management in arch/arm/mm/.

For (2), I think the best approach is to use the actual "wfi"
instruction and build the affected files with the appropriate -march=
flag (omap already does that) - since those CPU-specific files should
by definition never be run if running on another CPU.  We only support
new enough tools these days that this should be supported; so "wfi"
should be preferable to ".long 0xdeadbeef" - otherwise we need lots of
#ifdef CONFIG_THUMB2_KERNEL, or a macro.  If we have a macro, it would
be better for that to be generically implemented somewhere, becasue
the requirements are the same for every BSP supporting v7.

Makes sense.

I don't like the practice of pre-assembling bits of code with .long,
in order to allow a file to be built with wrong -march= flags, and I
would favour migrating away from this where possible ... but I accept
it's a pragmatic solution to a problem for which gcc/binutils provide
no good alternative.

Yes. Moreover, new instructions may always have to be that way for
a while, before they can be moved over to the proper inline
assembly.

So, for v6K we should either always use MCR for wfi(), or we need to
define wfi() using ALT_SMP(wfi) ALT_UP(mcr).  But whether that's a
common enough case to care about, I can't say.


Any thoughts on all that?

I think that having all instances of wfi in per-CPU source files is
good enough, because it's not performance critical, and this method
is well-supported already.

	Arnd