On Mon, Jan 21, 2013 at 10:46:31AM -0800, John Stultz wrote:
What I'd propose is that we break the read_persistent_clock()How big of an issue is this? Could the RTCTOSYS function be moved to
functionality up. So we need two interfaces:
1) An interface to access a time value we used to initialize the
system's CLOCK_REALTIME time.
2) An interface to measure the length of suspend.
Interface #1 could be possibly just replaced with the RTCTOSYS
functionality. Although the downside there is that for some time at
bootup between the timekeeping_init() function running (prior to
interrupts being enabled) and the RTC driver being available (after
interrupts are enabled), where we'd have an incorrect system clock.
So we may want to preserve something like the existing
read_persistent_clock() interface, but as Jason suggested, we could
push that access into the RTC driver itself.
the moment the RTC driver is registered rather than using a
late_initcall?
Interface #2 could then be either RTC based, or countinuous counterCould the counter version of this be bundled into the clocksource
based. Since we still want to do this measurement with interrupts
off, we still would need that interrupt-free RTC method like
read_persistent_clock() where supported (falling back to the RTC
driver's suspend/resume handler to try to fix things up as best it
can if that's not available).
framework? It already has generic APIs for handling cycle counters and
things. Isn't there a TSC driver for clocksource already? Is all that
is missing is a way to tell if the counter survived suspend?
clocksource already has suspend/resume callbacks stuff, so the counterBut at that point you've lost time. If this was all centrally controlled, you have to know before hand what the bounds would be. With the TSC, we know it won't wrap around our starting measurement for at least 10 years. That's a reasonable range for suspend. We don't want to resume and just get a "oh, bad call, you picked the wrong clocksource for such a long suspend", and really without the clocksource checking with the RTC I don't think it can even know if its been too long itself (since maybe the counter wrapped, but maybe not).
driver could sense if the sleep was too deep and mark itself as
invalid.
This would help solve the problem on ARM with muxing persistent clock
on multi-platform.
A RTC device flag 'readable with interrupts off' still seems like a
good idea for the RTC case..