[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Premi, Sanjeev]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com] 
> Sent: Monday, June 27, 2011 9:00 PM
> To: Premi, Sanjeev; Tony Lindgren
> Cc: Koen Kooi; linux-omap at vger.kernel.org List; linux-arm-kernel
> Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
> 
> On Mon, 27 Jun 2011, Tony Lindgren wrote:
> 
> > This fix will cause bad dependency issues with sys_timer.
> > 
> > This patch has a dependency to omap3_beagle_init_rev, which 
> depends on
> > the mux framework and gpio framework. Not cool for 
> init_early. We just
> > want to initialize sys_timer early without any complicated 
> dependencies.
> > 
> > The best way to fix this is to set a separate machine ID 
> for the properly
> > working beagle boards like xm, then just set the .timer 
> entry to omap3_timer
> > for working beagle boards and omap3_secure_timer for 
> non-working beagle
> > boards. The rest of the board-*.c file can be shared.
> 
> Sanjeev, want to take care of this?  Machine ID update info is in 
> linux/arch/arm/tools/mach-types.  
> 
> This strategy will unfortunately involve patching 
> bootloaders.  But if the 
> default is to use GPT12, it should work out okay.

[sp] Just sent another query to Tony on this specific issue.
     But, if different mach-type is the way forward, then
     I will take it forward.

> 
> Hopefully we won't have to do the same thing for the other 
> Beagle-derived 
> boards, Devkit8000, Touchbook, etc. etc.  Then again, I 
> suppose this will 
> eventually just be another property passed in via DT, with a single 
> machine ID.

[sp] Can you look at my query to Tony? Will that be an acceptable
     workaround until DT. Going to two machine IDs and then unifying
     back again could cause confusion - esp. during transition times.

~sanjeev

> 
> > The above assumes the patches in devel-timer branch where 
> we no longer
> > have the non-standard timer interface, but use the sys_timer entries
> > instead like we should.
> 
> 
> - Paul
>