[ltt-dev] trace_clock_update() spinning

[mmcternan@airvana.com (Mike McTernan)]

* 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