[Maverick][PATCH] UBUNTU: ARM: Turning off CONFIG_CPU_IDLE on omap

[Mathieu Poirier]

On Tue, 2010-06-22 at 08:20 -0700, Leann Ogasawara wrote:
> On Tue, 2010-06-22 at 10:58 +0100, Andy Whitcroft wrote:
> > On Mon, Jun 21, 2010 at 05:30:41PM -0600, Mathieu Poirier wrote:
> > > >From 7cb2de99fb596c2e9d9abe6fd6273344e397f7d2 Mon Sep 17 00:00:00 2001
> > > From: Mathieu J. Poirier <mathieu.poirier at canonical.com>
> > > Date: Mon, 21 Jun 2010 17:19:46 -0600
> > > Subject: [PATCH] UBUNTU: ARM: Turning off CONFIG_CPU_IDLE on omap
> > > 
> > > This is a temperary fix that allow the system to be usable.  The real fix,
> > > the one that really correct what seems to be an issue with retreiving
> > > the value of the PM_WKST_WKUP register should follow shortly.
> > 
> > You really should include which releases patches are destined for.  Here
> > I assume this is destined for maverick so you should include that in the
> > subject.  Something like this.
> > 
> >   Subject: [PATCH] [Maverick] UBUNTU: ARM: ....
> > 
> > Also is this critical for Alpha-2?  If so you need to make sure Leann is
> > aware, contact her direct to ensure its not missed.
> 
> I'd be willing to carry this temporarily if this is critical for
> Maverick's Alpha2 release, let me know.  Ideally we would want to get
> the "real fix" you mention.  Is this fix already in the form of a patch
> somewhere where we can track it, ie on it's way upstream?  I'd like to
> make a direct reference to it in the commit message for tracking
> purposes.
> 
> > -apw
> > 
> 
> 
Yes, this is critical for Alpha2.  Without it, the beagleboard is
unusable - please carry forward.

I haven't found the real solution nor do I know where it is...  But I
know disabling CONFIG_CPU_IDLE will just hide the problem.  

Fair enough, upstream has the flag disabled.  Since we share the same
codebase one would logically assume that turning the flag on would also
render upstream inoperable, but it doesn't. 

When CONFIG_CPU_IDLE is set in both upstream and maverick, the path
through the code is the same.  The problem occurs when reading a HW
registers in the ARM core - on maverick the "__raw_readl" fails whereas
in upstream, it works properly.  

If (in maverick) I introduce a small delay, the read operation goes
through properly and the problem is fixed.  Randomly delaying kernel
processes are not the solution - I need to introduce a memory barrier of
some kind that will guarantee a proper read.  Cking set me on the right
track this morning.  Amit also pointed out an upstream power management
branch that has fixes in that area.