On Mon, Jan 17, 2011 at 01:31:47PM -0700, Paul Walmsley wrote: > On Mon, 17 Jan 2011, Aaro Koskinen wrote: > > > On Mon, 17 Jan 2011, Santosh Shilimkar wrote: > > > > Amstrad E3 fails during the boot. Bisection points to: > > > > > > > > commit 211baa7016894c02fc18693e21ca479cd08ac0c0 > > > > Author: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> > > > > Date: Tue Jan 11 16:23:04 2011 +0000 > > > > > > > > ARM: sched_clock: allow init_sched_clock() to be called > > > > early > > > > > > > > The board does not have sched_clock(), although HAVE_SCHED_CLOCK is > > > > defined for all OMAP. > > > > > > > I guess above is sorted out by the attached patch from Paul. > > > > I don't see how it could help? Amstrad E3 is OMAP 15xx. > > OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't > have GPTIMERs or the 32k sync timer, and the MPU timer code in > mach-omap1/time.c wasn't updated for sched_clock() support. > > Adding an init_fixed_sched_clock() into omap_init_clocksource() should > fix the boot on OMAP15xx/7xx. No, it needs fixing properly. There's no reason the gpt clocksource can't be used for sched_clock. We just need to switch to the variable rate implementation rather than the fixed rate if we include OMAP15xx/7xx support. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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
