From: Mason <mpeg.blue@free.fr>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
cpufreq <cpufreq@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Michal Simek <michal.simek@xilinx.com>,
Mike Turquette <mturquette@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
John Stultz <john.stultz@linaro.org>
Subject: Re: Delays, clocks, timers, hrtimers, etc
Date: Fri, 06 Feb 2015 10:37:32 -0800 [thread overview]
Message-ID: <54D509EC.7020708@free.fr> (raw)
In-Reply-To: <20150203120925.GM8656@n2100.arm.linux.org.uk>
Hello Russell,
First of all, thanks for the insight you've been providing. It helps a lot.
(And thanks to everyone who's been answering some of my questions.)
Russell King - ARM Linux wrote:
> On Wed, Jan 28, 2015 at 02:16:21PM +0100, Mason wrote:
>
>> [snip udelay discussion]
>>
>> Q2. Cortex A9 global and private timers
>>
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/CIHGECHJ.html
>>
>> (What are private timers used for?)
>
> The per-cpu private timers are mostly scheduling of threads.
Hmmm, I'm confused (again).
CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK means "use the global timer
for the scheduler clock", right? In that case, are the local timers
unused by Linux?
#ifdef CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
sched_clock_register(gt_sched_clock_read, 64, gt_clk_rate);
#endif
Is there generic code to set up local timers? (If so, where?)
sched_clock_register only seems to appear in machine-specific code.
What are the pros/cons of global timer vs local timers?
Or is such a question irrelevant?
(Because they are used for different purposes?)
>> In my platform-specific code, there is a config option to choose between
>>
>> 1) the ARM global timer
>> 2) a platform-specific timer (timer0)
>
> Most platforms implement their own timer, because its really sexy for
> hardware engineers to create yet another different timer implementation
> which is soo much better than every other timer implementation that has
> already been created. You wouldn't believe how many different ways that
> there are to create a timer - and we still have people coming up with
> new novel implementations!
There is trouble in paradise. I was planning to give the global timer a try,
instead of the platform-specific timer, until I noticed: "The global timer
is clocked by PERIPHCLK." And it turns PERIPHCLK is connected to the SoC's
CPU_CLK (the clock that drives the CPU cores); the same clock that is managed
by cpufreq. I imagine it's double plus ungood for precise time-keeping to
have frequency changes of the clocksource input?
>> Q3. Using the generic global timer implementation
>>
>> So, how do I use that implementation?
>> (Is someone other than STMicro using it?)
To answer that question:
$ grep -rn ARM_GLOBAL_TIMER | grep -v SCHED_CLOCK
arch/arm/mach-vexpress/Kconfig:7: select ARM_GLOBAL_TIMER
arch/arm/mach-bcm/Kconfig:87: select ARM_GLOBAL_TIMER
arch/arm/mach-bcm/Kconfig:108: select ARM_GLOBAL_TIMER
arch/arm/mach-rockchip/Kconfig:14: select ARM_GLOBAL_TIMER
arch/arm/mach-sti/Kconfig:4: select ARM_GLOBAL_TIMER
arch/arm/mach-zynq/Kconfig:6: select ARM_GLOBAL_TIMER if !CPU_FREQ
There are indeed a few users; also I wonder why mach-zynq enables
ARM_GLOBAL_TIMER only if !CPU_FREQ. (Could it be that they have
the CPU CLOCK driving PERIPHCLK?)
Regards.
next prev parent reply other threads:[~2015-02-06 18:37 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 13:16 Delays, clocks, timers, hrtimers, etc Mason
2015-01-29 13:57 ` Mason
2015-02-03 12:09 ` Russell King - ARM Linux
2015-02-06 18:37 ` Mason [this message]
2015-02-06 19:14 ` Russell King - ARM Linux
2015-02-06 21:03 ` Mason
2015-02-07 10:42 ` Russell King - ARM Linux
2015-02-09 7:45 ` Michal Simek
2015-02-09 16:10 ` Sören Brinkmann
2015-02-09 23:27 ` Mason
2015-02-06 20:25 ` Stefan Agner
2015-02-06 21:17 ` Mason
2015-02-06 21:31 ` Stefan Agner
2015-02-07 2:21 ` Mason
2015-02-07 9:51 ` Russell King - ARM Linux
2015-02-09 19:01 ` Stephen Boyd
2015-02-09 22:31 ` Mason
2015-02-09 23:17 ` Stephen Boyd
2015-02-09 23:50 ` Mason
2015-02-11 17:43 ` Mason
2015-02-11 18:45 ` Stephen Boyd
2015-02-11 21:58 ` Mason
2015-02-11 23:26 ` Stephen Boyd
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=54D509EC.7020708@free.fr \
--to=mpeg.blue@free.fr \
--cc=cpufreq@vger.kernel.org \
--cc=john.stultz@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=michal.simek@xilinx.com \
--cc=mturquette@linaro.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).