Re: [PATCH 3/4] ARM: OMAP: Remove MPU-timer based sched_clock()

[Tony Lindgren <tony@atomide.com>]

* Kevin Hilman <khilman@mvista.com> [071126 11:30]:
> 
> On Mon, 2007-11-26 at 10:40 -0800, Tony Lindgren wrote:
> > * Kevin Hilman <khilman@mvista.com> [071126 07:59]:
> > > 
> > > On Fri, 2007-11-23 at 11:18 -0800, Tony Lindgren wrote:
> > > > * Kevin Hilman <khilman@mvista.com> [071112 15:25]:
> > > > > Remove MPU-timer based sched_clock() in favor of the common one based
> > > > > on 32k sync timer which works across all OMAP1/2/3 platforms.
> > > > > 
> > > > > Using 32k based one also gives a valid sched_clock() very early in the
> > > > > boot process.
> > > > 
> > > > AFAIK there is no 32k sync timer for 15xx, or have I missed something?
> > > > 
> > > 
> > > No there isn't.
> > > 
> > > But all this means is that 15xx has no higher resolution sched_clock().
> > > The ARM default jiffies-based one will be used.
> > 
> > I guess I don't understand what you're after by not using mpu timer 2
> > for proper sched_clock, some PM issues?
> 
> The main reason was for cleanup purposes.  There were various Kconfig
> combinations that would configure different sched_clock() sources based
> on MPU timers or 32k timers.  
> 
> I was after having a consistent sched_clock() no matter which MPU or 32k
> timers were enabled, and which could work on all/most platforms.  The
> result is that everything with a 32k sync timer gets a 32k
> sched_clock(), everyone else gets a jiffies-based one.

OK

> The secondary reason was to not have sched_clock() based on a timer that
> might stop during PM activity like suspend.
> 
> > Maybe for PM reasons not having mpu timer 2 running could make sense if
> > it blocks some sleep states. But then again there's no timesource during
> > sleep states unless mpu timer 2 can use the 32K clock as a source clock..
> 

OK, I'll apply that patch, let's let the 15xx users add it back if needed ;)

Regards,

Tony