Architecture specific implementations for tickless kernel and deferrable timers

[john stultz]

On Fri, 2011-04-29 at 19:05 +0200, Thomas Gleixner wrote:
> On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:
> 
> > On Fri, Apr 29, 2011 at 07:56:56PM +0530, Vikram Narayanan wrote:
> > > 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.


> 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.

thanks
-john