* Paul Walmsley <paul@xxxxxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
