* Re: FW: [RFC PATCH v2 0/4] Add support for S3 non-stop TSC support.
[not found] <A74E4C03C808B649AF1F11527F2D4414034E0BE8@SHSMSX101.ccr.corp.intel.com>
@ 2013-03-05 3:20 ` Jason Gunthorpe
0 siblings, 0 replies; only message in thread
From: Jason Gunthorpe @ 2013-03-05 3:20 UTC (permalink / raw)
To: Tang, Feng; +Cc: John Stultz, linux-kernel
On Tue, Mar 05, 2013 at 02:34:25AM +0000, Tang, Feng wrote:
> Hi Jason,
>
> Sorry, I forgot to add you in cc list in the first place. Please
> help to review the patch series, thanks!
Sure, I didn't get CC'd on the patches, so this is an imperfect reply,
but..
Did you consider an approach closer to the function I outlined to
Jonh:
// 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);
}
Rather than the while loop, which, I suspect, drops more precision
that something like the above. (replace cyclecounter with clocksource)
At the very least, keeping it as a distinct inline will let someone
come by one day and implement a proper 128 bit multiply...
You may want to also CC the maintainers of all the ARM subsystems that
use read_persistent_clock and check with them to ensure this new
interface will let them migrate their implementations as well.
> * Solve the problem of judging S3/S4, as the clocksource
> counter will be reset after coming out S4.
Hrm, what if it wraps during suspend? This probably isn't a problem
for a 64 bit TSC though..
Is it impossible to track if S4 or S3 was entered in the clocksource?
Reagrds,
Jason
^ permalink raw reply [flat|nested] only message in thread