Minor spelling fix, and a question.
john stultz wrote:
> linux-2.6.11-rc2_timeofday-core_A2.patch
> ========================================
> diff -Nru a/drivers/Makefile b/drivers/Makefile
> --- a/drivers/Makefile 2005-01-24 13:30:06 -08:00
> +++ b/drivers/Makefile 2005-01-24 13:30:06 -08:00
...
> + * all systems. It has the same course resolution as
should be "coarse"
Do you replace get_cmos_time() - it doesn't look like it.
You use it in your patch here...
> diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
> --- a/arch/i386/kernel/time.c 2005-01-24 13:33:59 -08:00
> +++ b/arch/i386/kernel/time.c 2005-01-24 13:33:59 -08:00
...
> +/* arch specific timeofday hooks */
> +nsec_t read_persistent_clock(void)
> +{
> + return (nsec_t)get_cmos_time() * NSEC_PER_SEC;
> +}
> +
I didn't scan for all uses of read_persistent_clock, but
in my experience get_cmos_time() has a latency of up to
1 second on x86 because it synchronizes with the rollover
of the RTC seconds.
This comment in timeofday.c:timeofday_suspend_hook
worries me:
> + /* First off, save suspend start time
> + * then quickly read the time source.
> + * These two calls hopefully occur quickly
> + * because the difference will accumulate as
> + * time drift on resume.
> + */
> + suspend_start = read_persistent_clock();
Do you know if the sync problem is an issue here?
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
-
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/
