I updated the patch docs and made the calls EXPORT_SYMBOL_GPL.
However the need for both khz and hz is due to high freq clocksources
like the TSC who's cycles/sec are close to the upper bound of a u32.
Let me know if you (or anyone else) have any further thoughts on the
interface, as again, it would be nice to have it ready for 2.6.35
so the per-arch conversions can be pushed.
How to pick good mult/shif pairs has always been difficult to describe
to folks writing clocksource drivers, since it requires careful tradeoffs
in adjustment accuracy vs overflow limits.
Now, with the clocks_calc_mult_shift function, its much easier. However,
not many clocksources have converted to using that function, and there is
still the issue of the max interval length assumption being made by
each clocksource driver independently.
So this patch simplifies the registration process by having clocksources
be registered with a hz/khz value and the the registration function taking
care of setting mult/shift.
This should take most of the confusion out of writing a clocksource driver.
Additionally it also keeps the shift size tradeoff (more accuracy vs longer
possible nohz times) centralized so the timekeeping core can keep track of the
assumptions being made.
CC: Thomas Gleixner <email@example.com>
Signed-off-by: John Stultz <firstname.lastname@example.org>
include/linux/clocksource.h | 3 ++
kernel/time/clocksource.c | 72 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 4bca8b6..1b0a5e0 100644
@@ -274,6 +274,9 @@ static inline s64 clocksource_cyc2ns(cycle_t cycles, u32 mult, u32 shift)
/* used to install a new clocksource */
+extern int clocksource_register_hz(struct clocksource*, u32);
+extern int clocksource_register_khz(struct clocksource*, u32);