[RFC PATCH] arm: move timer init to late_timer_init

Jean-Christophe PLAGNIOL-VILLARD plagnioj at jcrosoft.com
Mon May 2 19:27:01 EDT 2011


On 00:28 Tue 03 May     , Russell King - ARM Linux wrote:
> On Tue, May 03, 2011 at 01:17:14AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 00:19 Tue 03 May     , Russell King - ARM Linux wrote:
> > > On Tue, May 03, 2011 at 12:15:22AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 23:22 Mon 02 May     , Russell King - ARM Linux wrote:
> > > > > On Mon, May 02, 2011 at 10:42:20PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > > and add global early device init
> > > > > > this will init earlytimer and will try to probe 1 or 2 timers for clockevents
> > > > > > and clocksource
> > > > > 
> > > > > Why should this change the positioning of sched_clock initialization
> > > > > too?
> > > > > 
> > > > > You know, to spend time sorting out the sched_clock crap that platform
> > > > > people came up with, to get sched_clock working at the right point in
> > > > > the init sequence so that everything is happy, and then to have all
> > > > > that work undone one kernel version later... well, why did I even bother.
> > > > so is it ok to put the early init in time_init for you?
> > > 
> > > If it works there, then there's no problem.  I'm just left wondering why
> > > you decided to try the late_time_init() thing in the first place.  Was
> > > there a specific reason?
> >
> > sh-mobile and sh use it this way
> 
> Do we know why they do?
Magnus or Paul will answer better than me
IIRC on sh it's was because the timer init the IRQ too early

but on sh-mobile not sure

I test it on at91 with pit and st timers and I get no issue

Best Regards,
J.



More information about the linux-arm-kernel mailing list