* Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> [110209 08:44]: > On Wed, 9 Feb 2011, Russell King - ARM Linux wrote: > > > On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote: > > > * Santosh Shilimkar <santosh.shilimkar@xxxxxx> [110209 01:59]: > > > > > From: Dave Martin [mailto:dave.martin@xxxxxxxxxx] > > > > > > > > > > You could also have a "v7+" unified kernel -- i.e., supporting > > > > > OMAP3+4+SMP. > > > > > This is what we currently do in Linaro, since we're focusing on v7 > > > > > and above. > > > > > > > > > This sounds good way forward considering future OMAP architectures > > > > as well. > > > > > > > > But I let Tony comment on this idea. > > > > > > AFAIK these issues will be hopefully sorted out by the time the > > > next merge window opens. For the -rc cycle, disabling SMP in > > > config if ARMv6 is selected should do the trick. > > > > That's not soo easy - as we don't know in the Kconfig whether we include > > ARMv6 rather than ARMv6K. It's exactly the same problem I ran into which > > inflated the v6v7 patchset. > > > > Maybe the best thing to do is: > > > > 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) > > > > drop the ' && !(ARCH_MX3 || ARCH_OMAP2)' and just let people run into the > > resulting undefined instruction traps if they try to run the kernel on > > V6 non-K hardware. Not ideal, but I don't see any other 'simple' solution > > to this. > > This should be good enough. We're looking for a temporary stopgate > solution to prevent people from corrupting their data, and the real fix > will be available in the next kernel. OK. This patch will be needed anyways for the real fixes. And no temporary apply-undo type patching needed. The only drawback is that omap2420 and 2430 won't boot with omap2plus_defconfig, but that will be only for a few weeks. Acked-by: Tony Lindgren <tony@xxxxxxxxxxx> -- 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
