On Tuesday 22 January 2013, Santosh Shilimkar wrote:Sorry for not being clear enough. On OMAP, 32KHz is the only clock whichOn Tuesday 22 January 2013 04:53 AM, Tony Lindgren wrote:* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [130121 13:07]:This is right. It was only because of the drift associated when clocked
As for Samsung and the rest I can't comment. The original reason OMAP
used this though was because the 32768Hz counter can't produce 100Hz
without a .1% error - too much error under pre-clocksource
implementations for timekeeping. Whether that's changed with the
clocksource/clockevent support needs to be checked.
Yes that's why HZ was originally set to 128. That value (or some multiple)
still makes sense when the 32 KiHZ clock source is being used. Of course
we should rely on the local timer when running for the SoCs that have
them.
with 32KHz. Even on SOCs where local timers are available for power
management reasons we need to switch to 32KHz clocked device in
low power states. Hence the HZ value should be multiple of 32 on
OMAP.
I need some help understanding what the two of you are saying, because
it sounds to me that you imply we cannot have a multiplatform kernel
that includes OMAP and another platform that needs (or wants) a different
HZ value.
However, I also thought that when using a proper clocksource driver,I am not too sure about this. I was under impression that tick (clock
the HZ setting has absolutely no impact on the drift of the wall clock,
because those two are decoupled.
Even when using the HZ based clocksource (for whatever reason youThe issue is with hardware timer frequency itself since with HZ = 100 or
would want to do that), I thought there should be no drift as long
as the CLOCK_TICK_RATE (in older kernels) or the register_refined_jiffies()
(in older kernels) setting matches the hardware timer frequency.
What am I missing?