[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
Tony Lindgren
tony at atomide.com
Fri Jan 14 19:12:55 EST 2011
* Russell King - ARM Linux <linux at arm.linux.org.uk> [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
More information about the linux-arm-kernel
mailing list