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)"
next prev 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.