* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [101218 09:50]: > 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.) OK, sounds good. I'll give those a try next week too. Will update this patch based on your original comment and keep it in my series. Regards, Tony -- 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
