Date: Mon, 1 Dec 2008 05:57:37 -0500
From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: ltt-dev@lists.casi.polymtl.ca, linux-kernel@vger.kernel.org
Subject: Re: [ltt-dev] keypad/touchscreen driver events latencies using
	LTTng on ARM?
Message-ID: <20081201105737.GE25340@Krystal>
References: <5d5443650811301000t58665a7j7aa93be52325a23b@mail.gmail.com> <20081201103502.GC25340@Krystal> <20081201104529.GB28971@flint.arm.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
In-Reply-To: <20081201104529.GB28971@flint.arm.linux.org.uk>
User-Agent: Mutt/1.5.16 (2007-06-11)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1924
Lines: 44

* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/