Hi all,
Good news, it looks like I've cracked it, at least for the 'normal' use
of ivtv. I can still break it if I continuously change frequency (say
100 times a second or more), but that is outside the normal behavior of
linux.
If I run a script that changes frequency three times a second, then with
the current driver the driver stops working within 30 seconds. When
running with my fixes I was able to keep it running the whole night
with only one DMA error, after which it just kept working. This was
with the same script running, one continuous linux kernel compile, two
captures from my PVR500 to /dev/null and one 'cat /dev/video1
>/dev/video17' from my PVR350 (so encoding and decoding at the same
time).
Besides fixing several timing issues I've also added code to very
efficiently detect the offset at which the cards DMA engine placed the
data, so I can with almost no overhead just continue working after a
DMA error, automatically correcting for the (random) offset. I'm very
lucky that the offset is always between 0 and 128 bytes, otherwise
there probably wouldn't have been anything I could do.
I hope to have patches available later today for people to test.
I think I can do even better than what I have now, but that will require
some substantial work on the driver. And if the changes I have now work
out, then I'll probably will do these bigger changes only in the trunk
version of ivtv without backporting them.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
