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

Tony Lindgren tony at atomide.com
Mon Jun 27 06:14:28 EDT 2011


* Paul Walmsley <paul at pwsan.com> [110625 15:42]:
> On Sun, 26 Jun 2011, Premi, Sanjeev wrote:
> 
> > [sp] I didn't include a reason - because the problem may not
> >      be reproducible on the public trees.
> > 
> >      During tests performed in internal development trees, the
> >      BogoMIPS calculations @ 1GHz wouldn't go beyond "830-850"
> >      range. While there was no such inconsistency on OMAP3EVM.
> 
> There are some other reasons to avoid GPTIMER12 when possible, which you 
> should probably put in the patch description.  The most important, in my 
> view, is that the clock source for GPTIMER12 is much less frequency-stable 
> than the clock sources for GPTIMER1.  So using GPTIMER12 can result in 
> major time skew over a fairly short interval.
> 
> I've been meaning to send a patch like this for some time, so I'm happy to 
> see this fixed.

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.

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.

Regards,

Tony



More information about the linux-arm-kernel mailing list