Russell King - ARM Linux wrote:
Mason wrote:
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?)
Correct.
The sched_clock itself is about providing the scheduler with a stable,
monotonically increasing 64-bit nanosecond value which it can use to
account for the passing of time (so it can accurately measure how long
a thread is running for, and make a decision when to pre-empt it.)
Local timers are used to set "alarms" to cause an interrupt at a certain
point in time to do something (like, run the scheduler to switch from
the current thread to another thread.) It can also be used to update
the current time of day as well.
Global timers are used as a fallback when local timers are not available,
and are less efficient - the CPU receiving the global timer interrupt
has to broadcast the interrupt to other CPUs, and it also has to take
account of the earliest event across all CPUs.
There is a fourth "timer" which is used as a monotonically incrementing
counter - this is called the "clocksource". This is used to maintain
the kernel's time-of-day. This may be the same as the sched_clock.
Where is this sched_clock set up?
I see sched_clock_register() in kernel/time/sched_clock.c
setup_sched_clock() wraps sched_clock_register() but I only see one
user of setup_sched_clock() -- arch/arm/mach-footbridge
sched_clock_postinit() is used to set up an acceptable default,
I suppose? (i.e. jiffy_sched_clock_read)
But this still needs a time source (an actual crystal). I must be
missing something important from the big picture.
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?
Yes and no. You can use that for local timers and/or a global timer, but
you really don't want to use that for the sched_clock nor clocksource as
these are really the fundamentals of time keeping. I'd advise against
using a timer derived from the CPU clock in general though, but if you
have no other possible timers, then it has to do.
I do have several platform-specific timers available, but I was
considering using "standard" architected resources to minimize
the code needed for the port.
Also, reading Cortex-A9 MPCore Technical Reference Manual, section
5.1 Clocks, I see that, by definition, PERIPHCLK is tied to CLK
(the main clock). This means that, by definition, when using cpufreq,
CLK will change, thus PERIPHCLK will necessarily be variable too.
So the question I am trying to answer is: how do other SoCs use the
Cortex A9 global timer and local timers, along with cpufreq, and
make everything work correctly?
Regards.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
