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
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
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
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel