On Fri, Apr 29, 2011 at 11:27 PM, john stultz [off-list ref] wrote:

On Fri, 2011-04-29 at 19:05 +0200, Thomas Gleixner wrote:

quoted

On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:

quoted

On Fri, Apr 29, 2011 at 07:56:56PM +0530, Vikram Narayanan wrote:

quoted

Can you also give some idea on how the system's RTC is hooked up with
the generic timekeeping code.
Is it hooked up in someway so that the walltime is calculated wrt the
initial value of the RTC?

I'd like to pass you over to the RTC folk, but I don't think they're
very active anymore.

Suffice it to say that the RTC subsystem will set the system date/time
on initialization from the RTC device if one is provided. ?All I can
suggest is to look at drivers/rtc and include/linux/rtc.h for the
details. ?The MAINTAINERS file should list who is responsible for RTC
stuff as well as a mailing list for it.

read_persistant_clock() is used for boottime / resume time readouts of
a direct accessible RTC.

Right. read_persistent_clock has the benefit of being able to be read
with irqs off, which really is useful in reducing error in the
suspend/resume code. This makes it the preferred interface for
timekeeping.

quoted

If the RTC sits behind a slow bus which is not accessible in early
boot, then the RTC framework will take care of updating the time once
the RTC becomes available.

Right. I sent out a patch "Add timekeeping_inject_sleeptime" that
corrects the irqs-required RTC paths on suspend and resume, which Thomas
just pulled into -tip for 2.6.40. It should improve things on the
non-read_persistent_clock/irq-required RTC side of things.

With 2.6.39 and earlier, the RTC code basically just calls
settimeofday() fairly late in the resume step, which makes a window for
resume timestamps to show the suspend time, as well as not properly
allowing us to account for the amount of time the system was sleeping
(which mucks up the boot time).

Of course, another issue with the RTC interface is that it
isbottlenecked at second granularity, which also hurts suspend/resume
time accuracy. Where as read_persistent_clock() allows for finer grained
resolution (if possible).

Let me know if you have any more questions I can try to answer.

Thank you all for the explanations. I will update the thread, if I
have more questions. :)

-
Thanks,
Vikram