[PATCHv2 0/3] clocksource: add db8500 PRCMU timer
mattias.wallin at stericsson.com
Thu Jun 2 08:10:02 EDT 2011
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?
> 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.
> /* 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
> 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
>> 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
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
Am I on the wrong track here or how should I solve it?
More information about the linux-arm-kernel