[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
Russell King - ARM Linux
linux at arm.linux.org.uk
Fri Jan 14 19:25:31 EST 2011
On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> * 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
For spinlocks, the important thing is the barrier. The wfe/sev are an
optimization. The barrier contained with the ifdef is a valid V6
> > 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?
The bitops code is quite different between the two versions, and I doubt
the smp_on_up rewriting will look at all pretty. I think it needs an
alternative idea - like not using the 'byte' operations at all.
Whether we have any code which passes non-word aligned pointers to bitops
isn't particularly known - in theory they should all be unsigned long *'s,
so should be word-aligned. Who knows what filesystems do though... and
such a change could be disasterous to peoples data if the block/inode
bitmaps get corrupted.
IOW, such a change needs testing on a box where a range of filesystems are
used, and the filesystems can be thrown away if corrupted.
More information about the linux-arm-kernel