On Thursday 12 July 2012, John Stultz wrote: > > On 07/12/2012 10:31 AM, Marc Zyngier wrote: > > On Thu, 12 Jul 2012 09:57:33 -0700, John Stultz <john.stu...@linaro.org> > > wrote: > > > >> So following ia64's method is probably better then copying the 8253's > >> rate if you're not concerned about tick-granularity error. > > The 8253 is completely meaningless in our case (though I'm sure someone > > could try and bold one on the side of an Aarch64 CPU...), so going the ia64 > > way is probably best (erm... this last bit doesn't sound quite right, > > doesn't it?). > > Sorry, the "copying the 8253's" bit didn't come out sarcastic enough. :) > > The best solution would be to include the actual tick-granularity, but > given its not really an architecture constant (which CLOCK_TICK_RATE > assumes), that probably wouldn't be appropriate.
Hmm, in the quest to eliminate CLOCK_TICK_RATE entirely, could we make a Kconfig symbol that is selected for all architectures that (may) rely on a periodic timer tick and require this to be set? Architectures that always have a working clock source would then just not include the timex.h header and #define ACT_HZ HZ in common code. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/