[ltt-dev] trace_clock_update() spinning
Mike McTernan
mmcternan at airvana.com
Tue Feb 9 05:19:23 EST 2010
* 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
More information about the lttng-dev
mailing list