From mboxrd@z Thu Jan  1 00:00:00 1970
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Date: Tue, 9 Feb 2010 09:42:37 -0500
Subject: [ltt-dev] trace_clock_update() spinning
In-Reply-To: <4B3F8896E1733D4787DDB0EA1C7FF91F0108D839@ukmail.uk.wirelessworld.airvananet.com>
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>
	<4B3F8896E1733D4787DDB0EA1C7FF91F0108D839@ukmail.uk.wirelessworld.airvananet.com>
Message-ID: <20100209144237.GA3756@Krystal>

* Mike McTernan (mmcternan at airvana.com) wrote:
> * 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.

Yep, I understand your time constraints. Thanks for passing this on to
Freescale.

> 
> > > 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.

Well, if it's "trivial", then credits are unnecessary, but I've always stayed on
the safe side license-wise. It makes it easier in the future if we have to dig
back into these patches.

Thanks !

Mathieu

> 
> Regards,
> 
> Mike
>