On Fri, Jul 13, 2012 at 01:40:03PM +0100, Arnd Bergmann wrote: > 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.
Would something like below be enough? Also, are there any implications if we boot with clocksource=jiffies? --- a/include/linux/jiffies.h +++ b/include/linux/jiffies.h @@ -55,7 +55,11 @@ + ((((NOM) % (DEN)) << (LSH)) + (DEN) / 2) / (DEN)) /* HZ is the requested value. ACTHZ is actual HZ ("<< 8" is for accuracy) */ +#ifdef CLOCK_TICK_RATE #define ACTHZ (SH_DIV (CLOCK_TICK_RATE, LATCH, 8)) +#else +#define ACTHZ (HZ << 8) +#endif /* TICK_NSEC is the time between ticks in nsec assuming real ACTHZ */ #define TICK_NSEC (SH_DIV (1000000UL * 1000, ACTHZ, 8)) -- Catalin -- 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/