"Mark A. Greer" <[email protected]> writes: > On Sat, Mar 28, 2009 at 09:20:46PM -0700, David Brownell wrote: >> On Saturday 28 March 2009, Mark A. Greer wrote: >> > When enabled, the clocksource remains a continuous >> > 32-bit counter but the clock event will no longer >> > support periodic interrupts. Instead only oneshot >> > timers will be supported and implemented by setting >> > the compare register to the current timer value plus >> > the period that the clock event subsystem is requesting. >> >> How well stress tested is that mode? >> >> Thing is, it's inherently racey because the "current" >> timer is counting up while you're setting the compare >> register. Maybe it incremented just after you read it. >> That normally means min_delta_ns for the clockevent needs >> to be at least two ticks ... ideally several more than >> that, on the order of an IRQ latency, > > Yes, it is racey and I ran into the race when I had some > printk's in it during debugging. I bumped up > clockevent_davinci.min_delta_ns until they went away. > The printk's added so many artifacts that it wasn't valid > testing, though. > >> For the record this is quite like HPET on x86, where >> there's one counter (used in 32-bit mode even though >> it may well support 64-bits) and a bunch of compare >> registers (32 bit, almost always) to generate IRQs. > > I did test it doing more-or-less "normal" things but > I don't believe the true min is 1ns. :) > > I'll do some experimenting and come up with a better > value. >
Maybe a test patch that converts dm644x, dm355, and dm646x to use a single timer would allow broader testing of this as well. IIRC, timer-to-task latency measuredy using cyclictest a while back was on the order of a 200 usecs on average. I don't recall measuring the actual IRQ latency of hard IRQ to ISR though. Kevin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
