On Sun, 2008-11-16 at 00:00 -0500, Andy Walls wrote: > Hans, > > I've got a first cut at what I think is the way to handle interrupts in > cx18. I've split out the very time critical stuff from the deferable > stuff. It's a bit of an overhaul. > > http://linuxtv.org/hg/~awalls/cx18-bugfix > > > The CPU on the CX23418 really times out mailboxes it sends us rather > rapidly. There's still room for further optimization in the irq > handling to stay on timeline: removing MMIO read retries, removing MMIO > statistics logging, removing mmio_ndelay handling (it's useless now > anyway), and pulling some of the small functions into the large ones to > save a few microseconds seconds here and there. The cx18-io.[ch] MMIO > inefficiencies appear to be the only really low hanging fruit left in > the timeline. > > Right now, the IRQ handler still can't stay on timeline for a dual > capture and we end up processing the "stale" mailboxes anyway and hoping > for the best. That's what we did anyway, except with this change we > don't ack the stale ones. Most of the time the CPU hasn't started > overwriting those stale mailboxes when we get a copy of them. For the > times when the CPU has however, the results are not graceful. I have > some ideas to help those situations, but they're not refined enough yet. > > Hopefully slimming down the functions in cx18-io.[ch] will make it all > better. > > Comments, critiques, and suggestions welcome.
My first critical comment to myself: I need to use a single-threaded work queue handler (I think), instead of the kernel default work queue (which is a collection of threads). I'm getting occasional visual errors in mplayer decoding the stream which I'm guessing are incoming buffers handled out of order due to multiple kernel eventd/n threads processing the work orders. Regards, Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
