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

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> * 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.

For spinlocks, the important thing is the barrier.  The wfe/sev are an
optimization.  The barrier contained with the ifdef is a valid V6
instruction.

> > 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.