From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
Date: Fri, 14 Jan 2011 16:37:34 -0800 [thread overview]
Message-ID: <20110115003734.GV4957@atomide.com> (raw)
In-Reply-To: <20110115002531.GF22505@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 16:24]:
> 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.
OK, great it's just drain WB. Then we can do the ussual iffdeffery
on it for multi-arm builds as it does not depend on the 6K extensions.
I can do a patch for this on Monday, gotta run now.
> > > 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.
Hmm, how about emulation of those instructions for non-v6K ARMv6 processors?
I guess we could do some address checking in the bitops functions too for
multi-arm builds..
> 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.
Or we could patch in the address checking first and only disable it
later if now warnings.
Tony
next prev parent reply other threads:[~2011-01-15 0:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110106170805.GE1198@n2100.arm.linux.org.uk>
[not found] ` <20110106180030.GA8249@n2100.arm.linux.org.uk>
[not found] ` <20110106182023.GV7771@atomide.com>
[not found] ` <20110106203238.GH1198@n2100.arm.linux.org.uk>
[not found] ` <20110106204053.GA7771@atomide.com>
[not found] ` <20110107161230.GR1198@n2100.arm.linux.org.uk>
[not found] ` <20110110185209.GC4957@atomide.com>
2011-01-11 23:16 ` [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure) Tony Lindgren
2011-01-13 8:52 ` Anand Gadiyar
2011-01-13 9:15 ` Russell King - ARM Linux
2011-01-13 15:51 ` Tony Lindgren
2011-01-13 16:49 ` Russell King - ARM Linux
2011-01-14 17:29 ` Tony Lindgren
2011-01-14 19:18 ` Paul Walmsley
2011-01-14 21:20 ` Russell King - ARM Linux
2011-01-14 22:07 ` Paul Walmsley
2011-01-14 23:10 ` Paul Walmsley
2011-01-14 23:58 ` Russell King - ARM Linux
2011-01-15 0:12 ` Tony Lindgren
2011-01-15 0:25 ` Russell King - ARM Linux
2011-01-15 0:37 ` Tony Lindgren [this message]
2011-01-15 17:04 ` Russell King - ARM Linux
2011-01-17 8:35 ` Sascha Hauer
2011-02-01 12:55 ` Anand Gadiyar
2011-02-02 1:10 ` Tony Lindgren
2011-02-02 6:05 ` Santosh Shilimkar
2011-02-02 19:48 ` Tony Lindgren
2011-02-03 8:43 ` Santosh Shilimkar
2011-02-12 8:46 ` Santosh Shilimkar
2011-02-24 17:38 ` Tony Lindgren
2011-02-25 5:33 ` Santosh Shilimkar
2011-02-25 17:49 ` Tony Lindgren
2011-02-02 18:43 ` Anand Gadiyar
2011-02-02 19:50 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110115003734.GV4957@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).