Re: [RFC PATCH 0/5] Add support for S3 non-stop TSC support.

[Jason Gunthorpe <jgunthorpe@obsidianresearch.com>]

On Tue, Jan 22, 2013 at 04:41:58PM -0800, John Stultz wrote:

> Right but to calculate an suspend interval (since they are likely
> many orders of magnitude larger then the intervals between timer
> interrupts), you need different mult/shift selection.  Its splitting
> out the mult/shift management into a per-subsystem level that is the

You are talking about overflow in cyclecounter_cyc2ns and the like
right? The 64 bit cycle_t and the underlying hw counter (eg 64 bit
rdtsc) are not going to overflow..

An alternate version of cyclecounter_cyc2ns for use by the suspend
code that handles overflow during the mult/shift operation solves that
problem:

// Drops some small precision along the way but is simple..
static inline u64 cyclecounter_cyc2ns_128(const struct cyclecounter *cc,
                                          cycle_t cycles)
{
    u64 max = U64_MAX/cc->mult;
    u64 num = cycles/max;
    u64 result = num * ((max * cc->mult) >> cc->shift);
    return result + cyclecounter_cyc2ns(cc, cycles - num*cc->mult);
}

Or am I missing the issue?

> complicated part. Additionally, there may be cases where the
> timekeeping clocksource is one clocksource and the suspend
> clocksource is another. So I think to properly integrate this sort

Does the difference matter? The clocksource to use is detected at
runtime, if the timekeeping clocksource is no good for suspend time
keeping then it just won't be used. With a distinct
read_persistent_clock API then they are already seperate??

Jason