Delays, clocks, timers, hrtimers, etc

[mpeg.blue@free.fr (Mason)]

Stefan Agner wrote:

> On 2015-02-06 22:17, Mason wrote:
>
>> Do you also use the ARM local timers in your port?
>> Is there generic code to handle them?
>
> It seems that there has been support for local timers once, but has been
> removed. But I'm not aware of the details:
> https://lkml.org/lkml/2013/2/22/49

The equivalent gmane link would be:
http://thread.gmane.org/gmane.linux.kernel/1445799

The description used to say:

-config LOCAL_TIMERS
-	bool "Use local timer interrupts"
-	depends on SMP
-	default y
-	select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
-	help
-	  Enable support for local timers on SMP platforms, rather then the
-	  legacy IPI broadcast method.  Local timers allows the system
-	  accounting to be spread across the timer interval, preventing a
-	  "thundering herd" at every timer tick.

which seems to have been replaced with HAVE_ARM_TWD

TWD stands for "Timer Watch Dog".
https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/twd.txt

"ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core
Timer-Watchdog (aka TWD), which provides both a per-cpu local timer
and watchdog.

The TWD is usually attached to a GIC to deliver its two per-processor
interrupts."


config HAVE_ARM_TWD
   bool
   depends on SMP
   select CLKSRC_OF if OF
   help
     This options enables support for the ARM timer and watchdog unit

One problem I see is that HAVE_ARM_TWD depends on SMP...

One of the systems I want to support is UP (single-core Cortex A9).
Does that mean I should use an SMP kernel even for that system?
Or is there a different subsystem for UP systems?

Also, reading arch/arm/kernel/smp_twd.c, I see that frequency changes
due to cpufreq are properly accounted for. (Although I imagine they do
introduce a small error in time-keeping because moving from freq_A to
freq_B is not instantaneous, so the exact time elapsed in-between is
impossible to determine.)

Regards.