On Wed, Jul 25, 2012 at 4:49 AM, Colin Cross <ccr...@android.com> wrote:
> Many clocks that are used to provide sched_clock will reset during > suspend. If read_sched_clock returns 0 after suspend, sched_clock will > appear to jump forward. This patch resets cd.epoch_cyc to the current > value of read_sched_clock during resume, which causes sched_clock() just > after suspend to return the same value as sched_clock() just before > suspend. > > In addition, during the window where epoch_ns has been updated before > suspend, but epoch_cyc has not been updated after suspend, it is unknown > whether the clock has reset or not, and sched_clock() could return a > bogus value. Add a suspended flag, and return the pre-suspend epoch_ns > value during this period. > > The new behavior is triggered by calling setup_sched_clock_needs_suspend > instead of setup_sched_clock. > > Signed-off-by: Colin Cross <ccr...@android.com> Sweet! Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
