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

Tony Lindgren
2011-01-15T00:13:15Z

* Russell King - ARM Linux <linux@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