[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