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. Regards, Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
