lkml.org 
[lkml]   [2011]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv2 0/3] clocksource: add db8500 PRCMU timer
On 06/02/2011 01:01 PM, Russell King - ARM Linux wrote:
> On Thu, Jun 02, 2011 at 12:18:35PM +0200, Mattias Wallin wrote:
>> On 06/02/2011 11:46 AM, Russell King - ARM Linux wrote:
>>> Why don't we just find a way of fixing sched_clock so that the value
>>> doesn't reset over a suspend/resume cycle?
>> Even if the value isn't reset during suspend/resume we want the
>> clocksource to keep counting. Or is it ok to have the clocksource stop
>> or freeze during suspend?
>
> kernel/time/timekeeping.c:timekeeping_suspend():
>
> timekeeping_forward_now();
>
> which does:
> cycle_now = clock->read(clock);
> cycle_delta = (cycle_now - clock->cycle_last)& clock->mask;
> clock->cycle_last = cycle_now;
>
> So that updates the time with the current offset between cycle_last and
> the current value.
>
> kernel/time/timekeeping.c:timekeeping_resume():
> /* re-base the last cycle value */
> timekeeper.clock->cycle_last = timekeeper.clock->read(timekeeper.clock);
>
> So this re-sets cycle_last to the current value of the clocksource. This
> means that on resume, the clocksource can start counting from any value it
> likes.
>
> So, without any additional external inputs, time resumes incrementing at
> the point where the suspend occurred without any jump backwards or forwards.
>
> The code accounts for the sleep time by using read_persistent_clock() read
> a timer which continues running during sleep to calculate the delta between
> suspend and resume, and injects the delta between them to wind the time
> forward.
>
>> Then we have cpuidle. Is it ok to stop/freeze the timer during cpuidle
>> sleep states?
>
> During _idle_ (iow, no task running) sched_clock and the clocksource
> should both continue to run - the scheduler needs to know how long the
> system has been idle for, and the clocksource can't stop because we'll
> lose track of time.
>
> Remember that the clockevent stuff is used as a trigger to the timekeeping
> code to read the clocksource, and update the current time. Time is moved
> forward by the delta between a previous clocksource read and the current
> clocksource read. So stopping or resetting the clocksource in unexpected
> ways (other than over suspend/resume as mentioned above) will result in
> time going weird.

Hmm, I have missed the existence of the read_persistent_clock(). It
sounds like I should keep the MTU as my clocksource / sched_clock and
have the PRCMU Timer as a persistent_clock instead.

Then one problem remains. The MTU will be powered during cstates:
running, wfi, ApIdle (arm retenetion). The MTU will loose power during
cstates ApSleep and ApDeepSleep. So I need to do a similar sync as
suspend does against the persistent_clock but when leaving and enter the
deeper cstates.

Should I solve it in the clocksource framework with a flag telling which
cstates the timer will stop/freeze and then inject time from the
persistent_clock for those cstates? (I am thinking something like the
CLOCK_EVT_FEAT_C3STOP flag)

Am I on the wrong track here or how should I solve it?


\
 
 \ /
  Last update: 2011-06-02 14:13    [W:0.095 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site