[ltt-dev] LTT for ARM

[Ali Günhan Akyürek]

Hi,

I've checked omap patch, and i'm trying to do something similar to it.

trace_clock_read32 of omap:
static inline u32 trace_clock_read32(void)
{
    u32 val;

    isb();
    val = read_ccnt();
    isb();
    return val;
}

trace_clock_read32 of mine:
static inline u32 trace_clock_read32(void)
{
    u32 val;

    /*isb();*/
    val = DEV_MEM_READ_LE(SOCTIMER1_VAL_REG)
    /*isb();*/
    return val;
}


Sorry, It can be a dumb question, but my timer is 32-bits. Suppose the
following case:
trace_clock_read32 is called for a trace_mark and it returned 0xfffffff1 at
second 3. In the same second 3, it's called again for the next
trace_mark,and now returned 0x00000002
So the second event occured later, but the clock value read at the second
event is 0x00000002. How can LTTng understand the right order?,via an
interrupt which is fired when timer is overflowed?

Best regards,
Ali




On Wed, Mar 2, 2011 at 2:22 PM, Mathieu Desnoyers <
compudj at krystal.dyndns.org> wrote:

> * Ali Günhan Akyürek (aliakyurek at gmail.com) wrote:
> > Hi all,
> >
> > Two years ago, I've integrated LTTng to a device with ARM platform and
> with
> > kernel 2.6.22. LTTng version was 0.9.10.
> > I used a sub-arch specific clock source for timestamps, based on the
> > discussion below:
> >
> > http://lttng.org/pipermail/ltt-dev/2009-January/000771.html
> >
> > My sub-arch specific code in asm-arm/ltt.h was the following:
> >
> > +#ifndef _ASM_ARM_LTT_H
> > +#define _ASM_ARM_LTT_H
> > +
> > +#include <linux/jiffies.h>
> > +#include <linux/seqlock.h>
> > +
> > +#define LTT_ARCH_TYPE LTT_ARCH_TYPE_ARM
> > +#define LTT_ARCH_VARIANT LTT_ARCH_VARIANT_NONE
> > +
> > +#define DEV_MEM_READ_LE(addr)  ((*((volatile unsigned int*)(addr))))
> > +
> > +#define SOCTIMER1_VAL_REG 0xF102031C
> > +#define TIMER1_VAL ((0xffffffff - DEV_MEM_READ_LE(SOCTIMER1_VAL_REG)))
> > +
> > +#define TCLK_200MHZ    200000000
> > +
> > +u64 ltt_heartbeat_read_synthetic_tsc(void);
> > +#undef LTT_HAS_TSC
> > +
> > +
> > +static inline u32 ltt_get_timestamp32(void)
> > +{
> > +    return TIMER1_VAL;
> > +}
> > +
> > +/* The shift overflow doesn't matter */
> > +static inline u64 ltt_get_timestamp64(void)
> > +{
> > +    return ltt_heartbeat_read_synthetic_tsc();
> > +}
> > +
> > +/* this has to be called with the write seqlock held */
> > +static inline void ltt_reset_timestamp(void)
> > +{
> > +    //atomic_set(&lttng_logical_clock, 0);
> > +}
> > +
> > +
> > +static inline unsigned int ltt_frequency(void)
> > +{
> > +    return TCLK_200MHZ;    //number of timer ticks in a second.
> > +}
> > +
> > +
> > +static inline u32 ltt_freq_scale(void)
> > +{
> > +  return 1;
> > +}
> >
> > This worked great for me at that time. However as today, I have to use
> > kernel 2.6.31 and LTTng 0.178 on same device.
> > Now, nor asm-arm/ltt.h, neither ltt_get_timestamp32 function exists. How
> > must I proceed?
> > Thanks in advance.
>
> The best way to understand the ARM trace clock is to look at the lttng
> "development snapshot" patchset, which includes the LTTng trace clocks
> patches all folded into about one patch per architecture. See
>
> http://lists.casi.polymtl.ca/pipermail/ltt-dev/2011-January/003751.html
>
> Once you see how the trace clock code works, and how to create your own
> patch to add your own support, you can then move to the "lttng stable"
> tree, which are still the versions you should use as an end user (until
> we complete the current development phase).
>
> Thanks,
>
> Mathieu
>
> >
> > Best regards,
> > Ali
>
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev at lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
>
> --
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110302/8f4630c4/attachment-0003.htm>