From: pgaikwad@nvidia•com (Prashant Gaikwad)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] arch_timer: Move delay timer to drivers clocksource
Date: Fri, 17 Jan 2014 17:07:23 +0530 [thread overview]
Message-ID: <52D915F3.3030500@nvidia.com> (raw)
In-Reply-To: <52D902D6.3090208@linaro.org>
On Friday 17 January 2014 03:45 PM, Daniel Lezcano wrote:
> On 01/17/2014 11:11 AM, Prashant Gaikwad wrote:
>> On Friday 17 January 2014 02:42 PM, Daniel Lezcano wrote:
>>> On 01/17/2014 10:07 AM, Antti Miettinen wrote:
>>>> Will Deacon <will.deacon@arm•com> writes:
>>>>> Why can't you use the C3STOP feature so that the arch-timer isn't
>>>>> used when
>>>>> you go idle?
>>>> That would mean falling back to broadcast timer, right? That's not
>>>> necessarily on the local CPU so wakeups would often wake two CPUs.
>>> You can prevent that if the hardware supports it with the
>>> CLOCK_EVT_DYNIRQ flag on the broadcast timer.
>> Instead of falling back on broadcast timer, is it possible to fall back
>> on other per-CPU timer which is preserved across idle state?
> Is it what you are looking for ?
>
> http://lwn.net/Articles/580568/
>
If I understand correctly these patches enables us to use per-CPU timers
as broadcast timers. I do not want to use broadcast timer.
If I have 2 per-CPU timers T1 and T2, T1 is not preserved across idle
state and T2 is preserved. And I want to use T1 as scheduler timer.
Can I do following for idle state?
Idle entry:
clockevents_shutdown(T1);
clockevents_set_mode(T2, ONESHOT);
clockevents_program_event(T2, next_event);
Idle exit:
clockevents_shutdown(T2);
clockevents_set_mode(T1, ONESHOT);
>>>> Does
>>>> anyone have patches for using a CPU local timer as a fallback for
>>>> C3STOP timers?
>>>
>
next prev parent reply other threads:[~2014-01-17 11:37 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 [this message]
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
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=52D915F3.3030500@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