On Tue, Jul 17, 2018 at 12:55 AM, Baolin Wang <[email protected]> wrote: > On some hardware with multiple clocksources, we have coarse grained > clocksources that support the CLOCK_SOURCE_SUSPEND_NONSTOP flag, but > which are less than ideal for timekeeping whereas other clocksources > can be better candidates but halt on suspend. > > Currently, the timekeeping core only supports timing suspend using > CLOCK_SOURCE_SUSPEND_NONSTOP clocksources if that clocksource is the > current clocksource for timekeeping. > > As a result, some architectures try to implement read_persistent_clock64() > using those non-stop clocksources, but isn't really ideal, which will > introduce more duplicate code. To fix this, provide logic to allow a > registered SUSPEND_NONSTOP clocksource, which isn't the current > clocksource, to be used to calculate the suspend time. > > Suggested-by: Thomas Gleixner <[email protected]> > Signed-off-by: Baolin Wang <[email protected]> > --- > Changes from RFC v1: > - Improve commit message. > - Remove the WARN_ON_ONCE(). > - Fix some coding style issues. > - Do not force to select a replacement suspend clocksource.
Thanks again, I'll get this queued up for testing. thanks -john
