On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [110114 15:58]: > > > > # ARMv6k > > config CPU_32v6K > > bool "Support ARM V6K processor extensions" if !SMP > > depends on CPU_V6 || CPU_V7 > > default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) > > > > OMAP2 prevents the selection of armv6k support. This is probably a very > > bad idea if you want to run the resulting kernel on SMP hardware as it > > removes a barrier in the spinlock code and disables the SMP-safe bitops. > > I have some ideas to fix this. Unfortunately it will be inefficient > as spinlock.h can be included from modules too :( I was thinking we can > implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm > builds. For spinlocks, the important thing is the barrier. The wfe/sev are an optimization. The barrier contained with the ifdef is a valid V6 instruction. > > The original patch which started turning this off was from the MX3 stuff, > > but without explaination. > > > > However, OMAP extended this to disabling the select statement for CPU_32v6K > > even if CPU_V7 is set: > > > > config CPU_V7 > > bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |- select CPU_32v6K > > + select CPU_32v6K if !ARCH_OMAP2 > > > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this > > patch should not have been merged. > > The only way we can fix that is do smp_on_up style rewriting of the assembly > during init between CPUv6 and v6K. Want me to do a patch for that? The bitops code is quite different between the two versions, and I doubt the smp_on_up rewriting will look at all pretty. I think it needs an alternative idea - like not using the 'byte' operations at all. Whether we have any code which passes non-word aligned pointers to bitops isn't particularly known - in theory they should all be unsigned long *'s, so should be word-aligned. Who knows what filesystems do though... and such a change could be disasterous to peoples data if the block/inode bitmaps get corrupted. IOW, such a change needs testing on a box where a range of filesystems are used, and the filesystems can be thrown away if corrupted. -- 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
