Hans Verkuil wrote: > 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. > Hans this is awesome. More than happy to test the 0.4.x patches asap as I'm also able to readily reproduce the problem. Great work.
Steve _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
