On Sat, Dec 18, 2010 at 09:41:36AM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [101218 09:36]: > > On Sat, Dec 18, 2010 at 09:20:56AM -0800, Tony Lindgren wrote: > > > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [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.) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html