public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tim Bird <tim.bird@am.sony.com>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] new timeofday core subsystem (v. A2)
Date: Tue, 01 Feb 2005 15:53:14 -0800	[thread overview]
Message-ID: <4200166A.6050309@am.sony.com> (raw)
In-Reply-To: <1107298089.2040.184.camel@cog.beaverton.ibm.com>

john stultz wrote:
> I believe you're right. Although we don't call read_persistent_clock()
> very frequently, nor do we call it in ways we don't already call
> get_cmos_time(). So I'm not sure exactly what the concern is.

Sorry - I should have given more context.  I am worried about
suspend and resume times.  An extra (up-to-a) second delay on
suspend it pretty painful for CE devices.  (See my SIG for
my other hat in the forum.)

>
> Since we call read_persistent_clock(), it should return right as the
> second changes, thus we will be marking the new second as closely as
> possible with the timesource value. If the order was reversed, I think
> it would be a concern.
>

It sounds like for your code, this synchronization is a valuable.
For many CE products, the synchronization is not needed.  I have a
patch that removes the synchronization for i386 and ppc, but
I haven't submitted it because I didn't want to mess up
non-boot-context callers of get_cmos_time which have valid
synchronization needs.

As you can see below, the patch is pretty braindead.
I was wondering if this conflicted with your new timer system or
not.

diffstat:
 arch/ppc/kernel/time.c                    |   10 ++++++++--
 include/asm-i386/mach-default/mach_time.h |    6 +++++-
 init/Kconfig                              |   27 +++++++++++++++++++++++++++
 3 files changed, 40 insertions(+), 3 deletions(-)

Signed-off-by: Tim Bird <tim.bird@am.sony.com>

-----------------------
diff -pruN -X /home/tbird/dontdiff linux-2.6.10.orig/arch/ppc/kernel/time.c linux-2.6.10/arch/ppc/kernel/time.c
--- linux-2.6.10.orig/arch/ppc/kernel/time.c	2004-12-24 13:35:23.000000000 -0800
+++ linux-2.6.10/arch/ppc/kernel/time.c	2005-02-01 15:28:42.539108108 -0800
@@ -291,8 +291,12 @@ EXPORT_SYMBOL(do_settimeofday);
 /* This function is only called on the boot processor */
 void __init time_init(void)
 {
-	time_t sec, old_sec;
-	unsigned old_stamp, stamp, elapsed;
+	time_t sec;
+	unsigned stamp;
+#ifndef CONFIG_RTC_NO_SYNC
+	time_t old_sec;
+	unsigned old_stamp, elapsed;
+#endif

         if (ppc_md.time_init != NULL)
                 time_offset = ppc_md.time_init();
@@ -317,6 +321,7 @@ void __init time_init(void)
 	stamp = get_native_tbl();
 	if (ppc_md.get_rtc_time) {
 		sec = ppc_md.get_rtc_time();
+#ifndef CONFIG_RTC_NO_SYNC
 		elapsed = 0;
 		do {
 			old_stamp = stamp;
@@ -329,6 +334,7 @@ void __init time_init(void)
 		} while ( sec == old_sec && elapsed < 2*HZ*tb_ticks_per_jiffy);
 		if (sec==old_sec)
 			printk("Warning: real time clock seems stuck!\n");
+#endif
 		xtime.tv_sec = sec;
 		xtime.tv_nsec = 0;
 		/* No update now, we just read the time from the RTC ! */
diff -pruN -X /home/tbird/dontdiff linux-2.6.10.orig/include/asm-i386/mach-default/mach_time.h linux-2.6.10/include/asm-i386/mach-default/mach_time.h
--- linux-2.6.10.orig/include/asm-i386/mach-default/mach_time.h	2004-12-24 13:34:30.000000000 -0800
+++ linux-2.6.10/include/asm-i386/mach-default/mach_time.h	2005-02-01 15:28:48.245009070 -0800
@@ -89,6 +89,7 @@ static inline unsigned long mach_get_cmo
 	 * RTC registers show the second which has precisely just started.
 	 * Let's hope other operating systems interpret the RTC the same way.
 	 */
+#ifndef CONFIG_RTC_NO_SYNC_ON_READ
 	/* read RTC exactly on falling edge of update flag */
 	for (i = 0 ; i < 1000000 ; i++)	/* may take up to 1 second... */
 		if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)
@@ -96,7 +97,10 @@ static inline unsigned long mach_get_cmo
 	for (i = 0 ; i < 1000000 ; i++)	/* must try at least 2.228 ms */
 		if (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP))
 			break;
-	do { /* Isn't this overkill ? UIP above should guarantee consistency */
+/* The following is probably overkill because
+ * UIP above should guarantee consistency */
+#endif
+	do {
 		sec = CMOS_READ(RTC_SECONDS);
 		min = CMOS_READ(RTC_MINUTES);
 		hour = CMOS_READ(RTC_HOURS);
diff -pruN -X /home/tbird/dontdiff linux-2.6.10.orig/init/Kconfig linux-2.6.10/init/Kconfig
--- linux-2.6.10.orig/init/Kconfig	2004-12-24 13:35:24.000000000 -0800
+++ linux-2.6.10/init/Kconfig	2005-02-01 15:28:48.281002137 -0800
@@ -248,6 +248,33 @@ config IKCONFIG_PROC
 	  This option enables access to the kernel configuration file
 	  through /proc/config.gz.

+menuconfig FASTBOOT
+	bool "Fast boot options"
+	help
+	  Say Y here to select among various options that can decrease
+	  kernel boot time.  These options may involve providing
+	  hardcoded values for some parameters that the kernel usually
+	  determines automatically.
+
+	  This option is useful primarily on embedded systems.
+
+	  If unsure, say N.
+
+config RTC_NO_SYNC
+	bool "Disable synch on read of Real Time Clock" if FASTBOOT
+	default n
+	help
+	  The Real Time Clock is read aligned by default. That means a
+	  series of reads of the RTC are done until it's verified that
+	  the RTC's state has just changed.  If you enable this feature,
+	  this synchronization will not be performed.  The result is that
+	  the machine will boot up to 1 second faster.
+
+	  A drawback is that, with this option enabled, your system
+	  clock may drift from the correct value over the course
+	  of several boot cycles (under certain circumstances).
+
+	  If unsure, say N.

 menuconfig EMBEDDED
 	bool "Configure standard kernel features (for small systems)"


  parent reply	other threads:[~2005-02-01 23:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-24 22:51 [RFC][PATCH] new timeofday core subsystem (v. A2) john stultz
2005-01-24 22:52 ` [RFC][PATCH] new timeofday arch specific hooks " john stultz
2005-01-24 22:53   ` [RFC][PATCH] new timeofday arch specific timesources " john stultz
2005-01-24 23:29     ` Christoph Lameter
2005-01-25  0:04       ` john stultz
2005-01-25  2:28   ` [RFC][PATCH] new timeofday arch specific hooks " Benjamin Herrenschmidt
2005-01-25 23:09     ` john stultz
2005-01-25 23:53       ` Benjamin Herrenschmidt
2005-01-26  0:17         ` john stultz
2005-01-26  0:34           ` Christoph Lameter
2005-01-26  3:29             ` Benjamin Herrenschmidt
2005-01-26 16:51               ` Christoph Lameter
2005-01-26  3:14           ` Benjamin Herrenschmidt
2005-01-24 23:24 ` [RFC][PATCH] new timeofday core subsystem " Christoph Lameter
2005-01-25  0:03   ` john stultz
2005-01-25  0:08     ` Christoph Lameter
2005-01-25  0:33       ` john stultz
2005-01-25  1:54         ` Christoph Lameter
2005-01-25  7:50           ` Ulrich Windl
2005-01-25 12:25           ` Tim Schmielau
2005-01-25  7:41   ` Ulrich Windl
2005-01-25  8:17 ` Andi Kleen
2005-01-25 23:18   ` john stultz
2005-02-01 22:06 ` Tim Bird
2005-02-01 22:48   ` john stultz
2005-02-01 23:14     ` Nigel Cunningham
2005-02-01 23:32       ` john stultz
2005-02-02  0:04         ` Nigel Cunningham
2005-02-02  0:27           ` john stultz
2005-02-02  0:36             ` Nigel Cunningham
2005-02-01 23:53     ` Tim Bird [this message]
2005-02-02  0:19       ` john stultz
2005-02-02  1:48         ` Tim Bird
2005-02-02  2:00           ` john stultz
2005-02-02  2:23             ` Nigel Cunningham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4200166A.6050309@am.sony.com \
    --to=tim.bird@am.sony.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox