Re: Enabling DBGEN signal in GP OMAP3

[Tony Lindgren <tony@atomide.com>]

* Matthijs van Duin <matthijsvanduin@gmail.com> [150218 10:32]:
> On 18 February 2015 at 15:54, Tony Lindgren <tony@atomide.com> wrote:
> > From memory.. I believe the issue was that for anything needing to
> > set the counter and rely on the counter interrupt things would fail
> > as the counter interrupts would not always happen.
> 
> Correct, but the interrupt is just used to indicate when counters
> overflow, intended to be used to correctly keep track of the counters
> when they exceed 2^32 (which can happen easily when measuring across a
> timespan of more than a few seconds).
> 
> However, no performance counter can increment more than twice per cpu
> cycle, which means it takes at least 2^31 cpu cycles to completely
> wrap a counter around.  If you make sure you update local copies
> (untested code below) more often than once per 2^31 cycles they should
> therefore keep accurate track.
> 
> void update_perf_counters( u64 ctr[4] )
> {
>         for( int i = 0; i < 4; i++ ) {
>                 u32 val;
>                 asm volatile( "mcr p15, 0, %0, c9, c12, 5" :: "r"(i) );
>                 asm volatile( "mrc p15, 0, %0, c9, c13, 2" : "=r"(val) );
>                 ctr[i] += (u32)( val - ctr[i] );
>         }
> }

Hmm yeah maybe oprofile/perf whatever has maximum value that can be
specified for the counter length that allows working around it.

Regards,

Tony