lkml.org 
[lkml]   [2013]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/5] Add support for S3 non-stop TSC support.
On 03/30/2013 11:14 AM, Pavel Machek wrote:
> Hi!
>
>>> On some new Intel Atom processors (Penwell and Cloverview), there is
>>> a feature that the TSC won't stop S3, say the TSC value won't be
>>> reset to 0 after resume. This feature makes TSC a more reliable
>>> clocksource and could benefit the timekeeping code during system
>>> suspend/resume cycles.
>>>
>>> The enabling efforts include adding new flags for this feature,
>>> modifying clocksource.c and timekeeping.c to support and utilizing
>>> it.
>>>
>>> One remaining question is inside the timekeeping_resume(), we don't
>>> know if it is called by resuming from suspend(s2ram) or from
>>> hibernate(s2disk), as there is no easy way to check it currently.
>>> But it doesn't hurt as these Penwell/Cloverview platforms only have
>>> S3 state, and no S4.
>>>
>>> Please help to review them, thanks!
>> The patches look reasonable to me.
> Not sure... what are advantages? TSC is high resolution, but not
> exactly precise time source... and this only makes resume more
> complex.
Providing sub-second granularity for suspend time measurement is a
pretty compelling use, which greatly reduces time error across
suspend/resume.

I agree that the code logic is more complex, but the TSC path should be
a good bit faster then hitting the CMOS.
And overall, I'm hoping we can eventually move the RTC based
read_persistent_clock() implementations into the rtc core, then allow
for clocksource based suspend timing where available (since ARM boards
are already basically doing this, but hiding it behind
read_persistent_clock() calls).

There is the open concern that given their history, x86 designers will
find yet another way to break the TSC in some future chip and we'll end
up with non-stop TSCs that run at different frequencies in suspend or
some other such nonsense. But we'll just have to detect that and disable
functionality where appropriate, much as we do with the TSC now.

thanks
-john




\
 
 \ /
  Last update: 2013-04-01 21:41    [W:0.097 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site