[PATCH] arch_timer: Move delay timer to drivers clocksource

Prashant Gaikwad pgaikwad at nvidia.com
Tue Jan 21 03:20:05 EST 2014


On Monday 20 January 2014 08:12 PM, Daniel Lezcano wrote:
> On 01/17/2014 07:36 PM, Stephen Boyd wrote:
>> On 01/17/14 05:40, Prashant Gaikwad wrote:
>>> Another requirement:
>>>
>>> We have 3 timers T1, T2, T3 used as wake events for 3 idle states C1,
>>> C2, C3 respectively.
>>>
>>> Rating of T2 is better than T3. If I register T2 and T3 both as
>>> broadcast timers then T3 will not be used. But ...
>>>       - T2 is not preserved in C3 idle state.
>>>       - T3 resolution is very poor (ms) and can not be used as wake
>>> event for C2.
>>>
>>> Possible solution, register only T3 as broadcast device and use T2 as
>>> per-CPU fallback timer.
>> We have the same situation on MSM. I've been thinking about proposing we
>> allow multiple broadcast timers to exist in the system and then have the
>> clockevents_notify() caller indicate which C state is being entered. The
>> broadcast timers would need to indicate which C state they don't work in
>> though.
> IMO, there are different solutions:
>
> 1. extend the C3STOP to C1STOP, C2STOP, etc ... and pass the idle state
> to the time framework where these flags are checked against. I don't
> like this approach but it is feasible.
>
> 2. use the generic power domain. When the power domain is shutdown via
> the cpuidle backend driver, it switches the timer.

I am aware of a way to attach idle state to GenPD where we enable an 
idle state when that power domain is turned off but not the other way 
where domain is shutdown via CPU idle driver. How do we do it?

Even though we shutdown power domain via cpuidle driver this still has 
to happen from CPU idle state, is that correct assumption? and we switch 
the timer here. So we still need a way to switch timer from CPU idle 
state. Hence the question remains is how to switch timers from idle state?

>
>




More information about the linux-arm-kernel mailing list