* Russell King <r...@arm.linux.org.uk> [110117 04:49]: > On Mon, Jan 17, 2011 at 06:05:36PM +0530, Santosh Shilimkar wrote: > > > -----Original Message----- > > > From: Aaro Koskinen [mailto:aaro.koski...@nokia.com] > > > Sent: Monday, January 17, 2011 5:52 PM > > > To: Santosh Shilimkar > > > Cc: Aaro Koskinen; Tony Lindgren; rmk+ker...@arm.linux.org.uk; > > > linux-omap@vger.kernel.org > > > Subject: RE: Open issues after 2.6.38 merge window > > > > > > Hi, > > > > > > On Mon, 17 Jan 2011, Santosh Shilimkar wrote: > > > >> Amstrad E3 fails during the boot. Bisection points to: > > > >> > > > >> commit 211baa7016894c02fc18693e21ca479cd08ac0c0 > > > >> Author: Russell King <rmk+ker...@arm.linux.org.uk> > > > >> 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. > > > > > I read patch again and omap15xx is skipped. Not sure > > why 15xx is skipped. > > EWW. This is horrible - and too far complicated. > > So if we build a kernel with OMAP730 or OMAP15xx support, the 32k > counter support is disabled for every platform, which also removes > sched_clock() support (as this uses the 32k timer). > > If CONFIG_OMAP_32K_TIMER is also true (eg, because you enabled > OMAP16xx) then we won't have the GP clocksource code. So a kernel > which is configured for OMAP15xx + OMAP16xx won't have any clocksource > code at all. > > In effect, all this being done by _negative_ dependencies. As has > been seen with deselecting the V6K configuration symbol, negative > dependencies are Bad News(tm). > > This code needs to be restructured for positive dependencies and > proper selection of the appopriate clock sources - which then > needs to be coupled into sched_clock() properly so OMAP15xx can also > benefit from sched_clock() support.
I'll take a look at fixing this. Sounds like we need both MPU timer and the 32K timer compiled in, then enable the right one based on runtime checks. Regards, Tony -- 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
