Re: [ltt-dev] keypad/touchscreen driver events latencies using LTTng on ARM?

[Mathieu Desnoyers <compudj@krystal.dyndns.org>]

* Russell King (rmk+lkml@arm.linux.org.uk) wrote:
> On Mon, Dec 01, 2008 at 05:35:02AM -0500, Mathieu Desnoyers wrote:
> > However, I wonder if some of the newer ARM boards would happen to have a
> > cycle counter (timestamp counter), so we could implement a get_cycles()
> > and trace clock for them ?
> 
> There continues to be nothing architected for that - it would be very
> SoC specific and the precision and resolution is very variable if it's
> provided at all.  About the best implementation is a 32-bit counter
> being clocked at various rates depending on the implementation.
> 
> Our best implementation is used for sched_clock() with all the
> cnt32_to_63() stuff to extend the size of the counter which as we've
> seen from other threads, may cause problems if used for other purposes.
> 
> The next best implementation is probably the hrtimer stuff.
> 

Ok, so for LTTng on ARM it would make sense to use the same clock source
as sched_clock for :
mach-pxa, mach-realview, mach-sa1100, mach-versatile, plat-omap.

We basically have, for each of these build scenarios, to take the mmio
clock used by sched_clock and use it through
kernel/trace/trace-clock-32-to-64 to extend it to 64-bits. Therefore we
won't suffer from any of the constrains linked to cnt32_to_63 and we
would be sure that the trace clock is correct wrt SMP wrt memory
barriers and cache line bouncing because it uses per-cpu data to keep
the counters.

That should be pretty much straightforward to do. Basically starting
from the MIPS trace clock I already have should make it trivial.

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68