linux-toradex.git/kernel/time/timekeeping.c, branch v3.3.5

Merge branch 'fortglx/3.3/tip/timers/core' of git://git.linaro.org/people/jstultz/linux into timers/core

2011-12-05T21:13:49+00:00

time: Fix spelling mistakes in new comments

2011-11-22T03:00:55+00:00

Fixup spelling issues caught by Richard

CC: Richard Cochran 
CC: Chen Jie 
CC: Steven Rostedt 
CC: Thomas Gleixner 
Signed-off-by: John Stultz

time: fix bogus comment in timekeeping_get_ns_raw

2011-11-22T03:00:46+00:00

The whole point of this function is to return a value not touched by
NTP; unfortunately the comment got copied wholesale without adjustment
from the timekeeping_get_ns function above.

Signed-off-by: Dan McGee 
Signed-off-by: John Stultz

timekeeping: add arch_offset hook to ktime_get functions

2011-11-17T22:57:19+00:00

ktime_get and ktime_get_ts were calling timekeeping_get_ns()
but later they were not calling arch_gettimeoffset() so architectures
using this mechanism returned 0 ns when calling these functions.

This happened for example when running Busybox's ping which calls
syscall(__NR_clock_gettime, CLOCK_MONOTONIC, ts) which eventually
calls ktime_get. As a result the returned ping travel time was zero.

CC: stable@kernel.org
Signed-off-by: Hector Palacios 
Signed-off-by: John Stultz

Merge branch 'formingo/3.2/tip/timers/core' of git://git.linaro.org/people/jstultz/linux into timers/core

2011-11-11T07:10:42+00:00

Conflicts:
	kernel/time/timekeeping.c

clocksource: Avoid selecting mult values that might overflow when adjusted

2011-11-10T19:27:08+00:00

For some frequencies, the clocks_calc_mult_shift() function will
unfortunately select mult values very close to 0xffffffff.  This
has the potential to overflow when NTP adjusts the clock, adding
to the mult value.

This patch adds a clocksource.maxadj value, which provides
an approximation of an 11% adjustment(NTP limits adjustments to
500ppm and the tick adjustment is limited to 10%), which could
be made to the clocksource.mult value. This is then used to both
check that the current mult value won't overflow/underflow, as
well as warning us if the timekeeping_adjust() code pushes over
that 11% boundary.

v2: Fix max_adjustment calculation, and improve WARN_ONCE
messages.

v3: Don't warn before maxadj has actually been set

CC: Yong Zhang 
CC: David Daney 
CC: Thomas Gleixner 
CC: Chen Jie 
CC: zhangfx 
CC: stable@kernel.org
Reported-by: Chen Jie 
Reported-by: zhangfx 
Tested-by: Yong Zhang 
Signed-off-by: John Stultz

time: Improve documentation of timekeeeping_adjust()

2011-10-28T06:57:38+00:00

After getting a number of questions in private emails about the
math around admittedly very complex timekeeping_adjust() and
timekeeping_big_adjust(), I figure the code needs some better
comments.

Hopefully the explanations are clear enough and don't muddy the
water any worse.

Still needs documentation for ntp_error, but I couldn't recall
exactly the full explanation behind the code that's there
(although I do recall once working it out when Roman first
proposed it). Given a bit more time I can probably work it out,
but I don't want to hold back this documentation until then.

Signed-off-by: John Stultz 
Cc: Chen Jie 
Cc: Steven Rostedt 
Link: http://lkml.kernel.org/r/1319764362-32367-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar

time: Fix stupid KERN_WARN compile issue

2011-07-20T22:42:55+00:00

Terribly embarassing. Don't know how I committed this, but its
KERN_WARNING not KERN_WARN.

This fixes the following compile error:
kernel/time/timekeeping.c: In function ‘__timekeeping_inject_sleeptime’:
kernel/time/timekeeping.c:608: error: ‘KERN_WARN’ undeclared (first use in this function)
kernel/time/timekeeping.c:608: error: (Each undeclared identifier is reported only once
kernel/time/timekeeping.c:608: error: for each function it appears in.)
kernel/time/timekeeping.c:608: error: expected ‘)’ before string constant
make[2]: *** [kernel/time/timekeeping.o] Error 1

Reported-by: Ingo Molnar 
Signed-off-by: John Stultz

time: Avoid accumulating time drift in suspend/resume

2011-06-21T23:55:37+00:00

Because the read_persistent_clock interface is usually backed by
only a second granular interface, each time we read from the persistent
clock for suspend/resume, we introduce a half second (on average) of error.

In order to avoid this error accumulating as the system is suspended
over and over, this patch measures the time delta between the persistent
clock and the system CLOCK_REALTIME.

If the delta is less then 2 seconds from the last suspend, we compensate
by using the previous time delta (keeping it close). If it is larger
then 2 seconds, we assume the clock was set or has been changed, so we
do no correction and update the delta.

Note: If NTP is running, ths could seem to "fight" with the NTP corrected
time, where as if the system time was off by 1 second, and NTP slewed the
value in, a suspend/resume cycle could undo this correction, by trying to
restore the previous offset from the persistent clock.  However, without
this patch, since each read could cause almost a full second worth of
error, its possible to get almost 2 seconds of error just from the
suspend/resume cycle alone, so this about equal to any offset added by
the compensation.

Further on systems that suspend/resume frequently, this should keep time
closer then NTP could compensate for if the errors were allowed to
accumulate.

Credits to Arve Hjønnevåg for suggesting this solution.

CC: Arve Hjønnevåg 
CC: Thomas Gleixner 
Signed-off-by: John Stultz

time: Catch invalid timespec sleep values in __timekeeping_inject_sleeptime

2011-06-21T23:55:36+00:00

Arve suggested making sure we catch possible negative sleep time
intervals that could be passed into timekeeping_inject_sleeptime.

CC: Arve Hjønnevåg 
CC: Thomas Gleixner 
Signed-off-by: John Stultz