Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

* Russell King - ARM Linux [off-list ref] [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