public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: pgaikwad@nvidia•com (Prashant Gaikwad)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] arch_timer: Move delay timer to drivers clocksource
Date: Tue, 21 Jan 2014 14:23:38 +0530	[thread overview]
Message-ID: <52DE3592.2090103@nvidia.com> (raw)
In-Reply-To: <52DE326F.40105@linaro.org>

On Tuesday 21 January 2014 02:10 PM, Daniel Lezcano wrote:
> On 01/21/2014 09:20 AM, Prashant Gaikwad wrote:
>> 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?
> You can effectively attach a power domain to a cpuidle state but that
> wasn't the point.
>
> What I meant is to create a generic power domain which maps the power
> domain of the idle state. When the power domain is shutdown, the
> callback of the genpd will switch to the timer.
>
> I can't give too much details because I am not used to this code but
> maybe it is a good solution for your specific case.
>

Somehow this is not mapping to my use case. We are using generic power 
domains with CPU idle states.

  reply	other threads:[~2014-01-21  8:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-15 13:07 [PATCH] arch_timer: Move delay timer to drivers clocksource Prashant Gaikwad
2014-01-15 15:41 ` Rob Herring
2014-01-16  4:45   ` Prashant Gaikwad
2014-01-15 15:45 ` Will Deacon
2014-01-16  5:19   ` Prashant Gaikwad
2014-01-16 12:16     ` Will Deacon
2014-01-17  9:07       ` Antti Miettinen
2014-01-17  9:12         ` Daniel Lezcano
2014-01-17 10:11           ` Prashant Gaikwad
2014-01-17 10:15             ` Daniel Lezcano
2014-01-17 11:37               ` Prashant Gaikwad
2014-01-17 12:08                 ` Daniel Lezcano
2014-01-17 13:40                   ` Prashant Gaikwad
2014-01-17 18:36                     ` Stephen Boyd
2014-01-20 14:42                       ` Daniel Lezcano
2014-01-20 14:56                         ` Lorenzo Pieralisi
2014-01-20 15:28                           ` Daniel Lezcano
2014-01-21  8:20                         ` Prashant Gaikwad
2014-01-21  8:40                           ` Daniel Lezcano
2014-01-21  8:53                             ` Prashant Gaikwad [this message]
2014-01-19  5:20                     ` Antti Miettinen
2014-01-20 14:41                     ` Daniel Lezcano
2014-01-21  8:10                       ` Prashant Gaikwad
2014-01-21  8:25                         ` Daniel Lezcano
2014-01-17 10:30           ` Antti Miettinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52DE3592.2090103@nvidia.com \
    --to=pgaikwad@nvidia$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox