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. Mark -- _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
