From mboxrd@z Thu Jan  1 00:00:00 1970
From: mmcternan@airvana.com (Mike McTernan)
Date: Tue, 9 Feb 2010 10:19:23 -0000
Subject: [ltt-dev] trace_clock_update() spinning
In-Reply-To: <20100209003026.GA23755@Krystal>
References: <4B3F8896E1733D4787DDB0EA1C7FF91F0108CDD1@ukmail.uk.wirelessworld.airvananet.com>
	<20100202194228.GA24026@Krystal>
	<4B3F8896E1733D4787DDB0EA1C7FF91F0108D2E4@ukmail.uk.wirelessworld.airvananet.com>
	<20100205151613.GA4516@Krystal>
	<4B3F8896E1733D4787DDB0EA1C7FF91F0108D4E2@ukmail.uk.wirelessworld.airvananet.com>
	<20100209003026.GA23755@Krystal>
Message-ID: <4B3F8896E1733D4787DDB0EA1C7FF91F0108D839@ukmail.uk.wirelessworld.airvananet.com>

* Mathieu Desnoyers wrote:
> * Mike McTernan (mmcternan at airvana.com) wrote:
> > Luckily in my application we disable DVFS and power management so
this
> > is ok.
> 
> Could you update the patch so it uses the generic timestamp if DVFS or
PM
> are enabled in the kernel config ?

I would like to say yes, but in truth I have neither the time or means
to test this.  Note I didn't submit the patch requesting inclusion,
merely to perhaps help others considering use of LTTng on iMX51's and
similar.

That said, I passed the patch to Freescale and asked that they consider
getting LTTng supported in their BSP as it is such an excellent tool.

> > Alternatively i.MX51 has a programmable timer that runs reasonably
fast
> > (66.5MHz on my setup) and is independent of power saving.  It's
called
> > the EPIT, and I had that working too, but used the cycle count for
> > greater resolution and for it's similarities with OMAP3.
> 
> Usually, anything that is outside of the CPU is terribly slow to read
> (memory mapped I/O). So using the TSC seems to be the best solution.

I agree that the TSC is better, also because its use could be
generalised for all ARM Cortex A8's and probably later ARMs.

> Well, I'm happy with whatever is the less trouble for everyone and
ensures
> that the code stays open. So GPLv2/LGPLv2.1 is fine. 

That's a good outlook & keeping it GPL or LGPL is cool.  My only worry
about reassignment would be that a future version could be under a less
permissive license. 

> Just as a thought, if you copy-pasted code from the other
architectures
> into these headers, perharps it would be better to leave the copyright
> notices already in place in addition to yours. That would help
copyright
> traceability. ;)

The assembly is derivative from the ARM reference, which will be the
same on every Cortex A8 (bar chip errata like the broken bit 31 on
OMAP):

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344j/Bgb
deggf.html

The empty functions to complete the interface follow from the generic
implementation, as they must in order to compile.  The mutex & reference
count to safely enable/disable the clock is the same as the generic
code; I should probably credit you for those 8 lines.

Regards,

Mike