On Monday 30 March 2009, Kevin Hilman wrote: > "Mark A. Greer" <mgr...@mvista.com> 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.
Wouldn't be quite the same. Those don't actually have compare registers which work that way... > 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. The IRQ latency concern is just that the tick can't possibly even *arrive* until then (ignoring things like needing to finish the current irqs-disabled critical section, etc) ... so it's pointless trying to schedule it sooner. (And arguably wasteful to try cutting things that close. Twice the latency might be a better rule of thumb.) The "minimum of two ticks" addresses only one hardware race. With timers there can also be overhead due to the costs of needing to synch across clock domains ... not so much here, but for a 32 KiHz clock, such things can hurt badly. - Dave _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
