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

[Dave Martin]

On Tue, Feb 8, 2011 at 3:15 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> 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.

Why not have macros for these cases?  (Which kinda brings the
discussion full-circle...)

My immediate concern is that too often, the Thumb-2 case will be
handled incorrectly or not at all ... and the kernel will silently
build without flagging any error.  Macros would allow the fragile
definitions to go in one place.

Cheers
---Dave