[PATCH 2/6] OMAP4: Pandaboard: Add omap_reserve functionality

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

On Sat, Dec 18, 2010 at 09:41:36AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 09:36]:
> > On Sat, Dec 18, 2010 at 09:20:56AM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 00:26]:
> > > > On Fri, Dec 17, 2010 at 07:05:21PM -0800, Tony Lindgren wrote:
> > > > >  	/* Maintainer: David Anders - Texas Instruments Inc */
> > > > >  	.boot_params	= 0x80000100,
> > > > >  	.map_io		= omap4_panda_map_io,
> > > > > +	.reserve	= omap_reserve,
> > > > 
> > > > Please put .reserve before .map_io.
> > > 
> > > Hmm, that's the way it should be.. But we should also correct the
> > > earlier changes too?
> > 
> > Strangely that's what I've been doing in my init_early patches.  My
> > comment was aimed to ensure that no new instances are introduced.
> 
> OK, do you want to merge this one into your patches too?

Well, the main purpose of init_early is to provide a hook to allow
platforms to initialize their sched_clock() implementation before the
scheduler comes up.

init_early is already in my misc branch, and should appear in linux-next
during the next update, if it isn't there already.  The patch for using
this new hook is still work in progress (SMP issues has overtaken it
again today.)

However, the problem I currently have is that the sched_clock() patchset
depends on the ftrace changes from Rabin (in devel-stable) and the
init_early stuff is in the misc branch, and I'm trying to avoid merging
those two branches until the patches for using the new hook have been
finalized and reviewed.

Once that's happened there's another pile of work to sort out the
initialization of sched_clock(), especially as almost every machine
class is completely different in this regard (due to dependencies with
things like clk API.)

I think this is going to be rather hit and miss, so I'm probably going
to do this relatively slowly - let's do the init_early support and
moving stuff there for this merge window, and leave resolving the
sched_clock() initialization issue until the following merge window.
(The rest of the sched_clock() stuff can go in as-is because it's no
worse than what we do today.)