On Tue, Jan 22, 2013 at 04:41:58PM -0800, John Stultz wrote:
Right but to calculate an suspend interval (since they are likelyYou are talking about overflow in cyclecounter_cyc2ns and the like
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
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 theDoes the difference matter? The clocksource to use is detected at
timekeeping clocksource is one clocksource and the suspend
clocksource is another. So I think to properly integrate this sort
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??