Stop do_gettimeofday() on FRV from using tickadj, and model it after ARM
instead.
This patch also provides a placeholder macro for getting hardware timer data to
be filled in when such is available.
Signed-Off-By: David Howells <[email protected]>
---
warthog>diffstat -p1 frv-tickadj-2618rc5mm1.diff
arch/frv/kernel/time.c | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
diff -urp ../kernels/linux-2.6.18-rc5-mm1/arch/frv/kernel/time.c linux-2.6.18-rc5-mm1-frv/arch/frv/kernel/time.c
--- ../kernels/linux-2.6.18-rc5-mm1/arch/frv/kernel/time.c 2006-09-04 18:03:14.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/arch/frv/kernel/time.c 2006-09-05 15:44:42.000000000 +0100
@@ -31,6 +31,9 @@
#define TICK_SIZE (tick_nsec / 1000)
+/* H/W clock data if we can get it (in microseconds) */
+#define FRV_HW_CLOCK_DATA (0)
+
unsigned long __nongprelbss __clkin_clock_speed_HZ;
unsigned long __nongprelbss __ext_bus_clock_speed_HZ;
unsigned long __nongprelbss __res_bus_clock_speed_HZ;
@@ -148,23 +151,10 @@ void do_gettimeofday(struct timeval *tv)
{
unsigned long seq;
unsigned long usec, sec;
- unsigned long max_ntp_tick;
do {
seq = read_seqbegin(&xtime_lock);
-
- usec = 0;
-
- /*
- * If time_adjust is negative then NTP is slowing the clock
- * so make sure not to go into next possible interval.
- * Better to lose some accuracy than have time go backwards..
- */
- if (unlikely(time_adjust < 0)) {
- max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
- usec = min(usec, max_ntp_tick);
- }
-
+ usec = FRV_HW_CLOCK_DATA;
sec = xtime.tv_sec;
usec += (xtime.tv_nsec / 1000);
} while (read_seqretry(&xtime_lock, seq));
@@ -195,7 +185,7 @@ int do_settimeofday(struct timespec *tv)
* wall time. Discover what correction gettimeofday() would have
* made, and then undo it!
*/
- nsec -= 0 * NSEC_PER_USEC;
+ nsec -= FRV_HW_CLOCK_DATA * NSEC_PER_USEC;
wtm_sec = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
