* 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. > 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? For the defconfigs, I have a branch where I occasionally compile all the old removed defconfigs too. And I believe Kevin test compiles various PM options. Tony -- 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
