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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
