[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1304123061.30215.38.camel@work-vm>
Date: Fri, 29 Apr 2011 17:24:21 -0700
From: John Stultz <john.stultz@...aro.org>
To: Arve Hjønnevåg <arve@...roid.com>
Cc: linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
arnd@...db.de, tglx@...utronix.de,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:timers/core] time: Add timekeeping_inject_sleeptime
On Fri, 2011-04-29 at 16:28 -0700, Arve Hjønnevåg wrote:
> On Fri, Apr 29, 2011 at 10:31 AM, tip-bot for John Stultz
> > @@ -85,15 +82,13 @@ static int rtc_resume(struct device *dev)
> > pr_debug("%s: time travel!\n", dev_name(&rtc->dev));
> > return 0;
> > }
> > + /* calculate the RTC time delta */
> > + set_normalized_timespec(&time, newtime - oldtime, 0);
> >
> > - /* restore wall clock using delta against this RTC;
> > - * adjust again for avg 1/2 second RTC sampling error
> > - */
> > - set_normalized_timespec(&time,
> > - newtime + delta.tv_sec,
> > - (NSEC_PER_SEC >> 1) + delta.tv_nsec);
> > - do_settimeofday(&time);
> > + /* subtract kernel time between rtc_suspend to rtc_resume */
> > + time = timespec_sub(time, timespec_sub(newts, oldts));
>
> The delta you got from the rtc can be almost a second to long or
> short. Do you do anything to prevent these errors from accumulating?
Indeed. Right now we don't do anything.
I'm hoping to extend the RTC interface to provide finer resolution where
possible, but that won't help on hardware that really only gives us
seconds.
We could maybe not only track the suspend time but the RTC time deltas
for when the system is running as well and utilize those values to avoid
accumulating the error long term. But then there can be other
complications between the NTP corrected system time and the uncorrected
RTC time.
Other ideas? I know you've got a patch in the Android tree to try to
address this, should I try to adapt it for use here?
thanks
-john
--
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