Re: [PATCH] atmel_tc clocksource/clockevent code

[David Brownell <david-b@pacbell.net>]

On Tuesday 04 March 2008, Remy Bohmer wrote:
> >  +/* For now, we always use the 32K clock ... this optimizes for NO_HZ,
> >  + * because using one of the divided clocks would usually mean the
> >  + * tick rate can never be less than several dozen Hz (vs 0.5 Hz).
> >  + *
> >  + * A divided clock could be good for high resolution timers, since
> >  + * 30.5 usec resolution can seem "low".
> 
> I want to comment on that.
>
> I noticed that on rm9200 the timer interrupt handler itself can cost
> about 50us to more than 100usec in itself (measured through ETM
> trace), combined with a worst case interrupt latency of about 75us.

Could you elaborate on where that 50-100 usec gets spent?  Does
the same issue happpen with the $SUBJECT patch (if you tweak the
clocksource ratings to use its clockevents on rm9200)?

I'd not think the timer IRQ logic accounts for much of that time,
and the rest of the instruction cycles would seem to be either
in genirq or gentime.  Unless the issue is that accessing that
particular hardware is slow, with clockdomain crossing etc ...
or that AT91 has way too many handlers sitting on IRQ-1.

If it's a gentime or genirq issue, that's somewhat amenable to
fixing ... and it would also impact the $SUBJECT patch both on
other AT91 ARM9 cores and on the AVR32 AP7 cores.


> So, a higher resolution than 30usec is useless on these cores, and
> setting timers on a frequency that high will just choke the processor
> in only handling timers...

Should the min_delta_ns be increased in at91rm9200_time.c then?
Right now, as you probably recall, it's at the lowest value
needed for correctness:  a smidgeon over two ticks (~ 72 nsec).

- Dave