On Sat, Jan 15, 2011 at 06:05:24PM -0600, Woodruff, Richard wrote: > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > > Sent: Saturday, January 15, 2011 5:38 PM > > Why does OMAP initialize its clock sources soo late, outside of > > the timer initialization? This means you have no counter in place > > (except for the jiffies counter) during early boot. > > > > Is there a reason why OMAP uniquely does this? > > Not any good reason. I'm aware of historic porting issue and the missed/ > hidden need for early init for some time services. > > 1st attempts to do really early init (like 7 years back) were messed as > not all kernel services used to be available when the time early time > init functions happened.
The background here is: We now have common generic sched_clock() support which provides true full 64-bit nanosecond time measurements, as required by the scheduler code. We need sched_clock() initialized before the first use which matters - which is inside sched_init(). As sched_init() is called by generic code, we don't have much choice over where it happens during the kernel boot - any change will need a very good justification because it's risking breaking other architectures. The only preceding hook we have into generic code is setup_arch(), and I now provide a .init_early platform callback to setup sched_clock(). The point at which init_sched_clock*() is called defines the sched_clock() time zero. However, this is too early to setup the sched_clock() keep-alive soft timer - this is delayed until the time_init() callback. This happens after sched_init(), so we expect that init_sched_clock() will have been called by this point - and given that it's already been used, this is not an unreasonable assumption. This is fine as we expect that the counter backing the sched_clock() implementation will not wrap between these two calls - and to make sure we kick off an update at this point. So, as a platform, there are two places where init_sched_clock() is callable - either .init_early (preferred) or the sys_timer .init method (if it must be late). If sched_clock() support is enabled, then init_sched_clock() must have been called no later than the return of sys_timer .init method otherwise you will get an oops (which is what is happening) when the first update cycle is kicked off. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
