[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1239760286.6064.44.camel@localhost>
Date: Tue, 14 Apr 2009 18:51:26 -0700
From: john stultz <johnstul@...ibm.com>
To: lkml <linux-kernel@...r.kernel.org>, davem@...emloft.net
Cc: rmk+lkml@....linux.org.uk, cooloney@...nel.org, starvik@...s.com,
takata@...ux-m32r.org, geert@...ux-m68k.org,
Roman Zippel <zippel@...ux-m68k.org>, lethal@...ux-sh.org,
Magnus Damm <magnus.damm@...il.com>, wli@...omorphy.com,
rth@...ddle.net
Subject: Re: [RFC][PATCH 7/8] Convert sparc to use arch_getoffset()
infrastructure.
Hey Dave,
You acked this patch earlier, but I've just tried building with a
cross-compiler environment I had access to and had problems getting it
to build.
It seems the pci_do_get/settimeofday() and the bus_do_get/settimeofday()
redirection code is causing some trouble. I'm really not sure how the
BTFIXUPSET_CALL code works, so I don't want to just kill it off.
Any advice here on how to do this right?
thanks
-john
This patch converts sparc to use GENERIC_TIME via the arch_getoffset()
infrastructure
NOT FOR INCLUSION
Signed-off-by: John Stultz <johnstul@...ibm.com>
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index cc12cd4..1358aab 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -55,8 +55,11 @@ config BITS
default 64 if SPARC64
config GENERIC_TIME
+ def_bool y
+
+config ARCH_USES_GETTIMEOFFSET
bool
- default y if SPARC64
+ default y if SPARC32
config GENERIC_CMOS_UPDATE
bool
diff --git a/arch/sparc/kernel/time_32.c b/arch/sparc/kernel/time_32.c
index 614ac7b..e946b55 100644
--- a/arch/sparc/kernel/time_32.c
+++ b/arch/sparc/kernel/time_32.c
@@ -227,7 +227,7 @@ void __init time_init(void)
sbus_time_init();
}
-static inline unsigned long do_gettimeoffset(void)
+u32 arch_gettimeoffset(void)
{
unsigned long val = *master_l10_counter;
unsigned long usec = (val >> 10) & 0x1fffff;
@@ -236,84 +236,7 @@ static inline unsigned long do_gettimeoffset(void)
if (val & 0x80000000)
usec += 1000000 / HZ;
- return usec;
-}
-
-/* Ok, my cute asm atomicity trick doesn't work anymore.
- * There are just too many variables that need to be protected
- * now (both members of xtime, et al.)
- */
-void do_gettimeofday(struct timeval *tv)
-{
- unsigned long flags;
- unsigned long seq;
- unsigned long usec, sec;
- unsigned long max_ntp_tick = tick_usec - tickadj;
-
- do {
- seq = read_seqbegin_irqsave(&xtime_lock, flags);
- usec = do_gettimeoffset();
-
- /*
- * 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))
- usec = min(usec, max_ntp_tick);
-
- sec = xtime.tv_sec;
- usec += (xtime.tv_nsec / 1000);
- } while (read_seqretry_irqrestore(&xtime_lock, seq, flags));
-
- while (usec >= 1000000) {
- usec -= 1000000;
- sec++;
- }
-
- tv->tv_sec = sec;
- tv->tv_usec = usec;
-}
-
-EXPORT_SYMBOL(do_gettimeofday);
-
-int do_settimeofday(struct timespec *tv)
-{
- int ret;
-
- write_seqlock_irq(&xtime_lock);
- ret = bus_do_settimeofday(tv);
- write_sequnlock_irq(&xtime_lock);
- clock_was_set();
- return ret;
-}
-
-EXPORT_SYMBOL(do_settimeofday);
-
-static int sbus_do_settimeofday(struct timespec *tv)
-{
- time_t wtm_sec, sec = tv->tv_sec;
- long wtm_nsec, nsec = tv->tv_nsec;
-
- if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
- return -EINVAL;
-
- /*
- * This is revolting. We need to set "xtime" correctly. However, the
- * value in this location is the value at the most recent update of
- * wall time. Discover what correction gettimeofday() would have
- * made, and then undo it!
- */
- nsec -= 1000 * do_gettimeoffset();
-
- wtm_sec = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
- wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);
-
- set_normalized_timespec(&xtime, sec, nsec);
- set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec);
-
- ntp_clear();
- return 0;
+ return usec * 1000;
}
static int set_rtc_mmss(unsigned long secs)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists