Hi all, As promised, here is the patch that should fix the DMA errors:
http://www.xs4all.nl/~hverkuil/ivtv-dma.0.4.diff http://www.xs4all.nl/~hverkuil/ivtv-dma.0.6.diff The first is the patch for ivtv-0.4.6, the second is the patch for ivtv-0.6.3 and ivtv-0.7.0 (and also applies to the ivtv trunk). The patches were made in the driver directory of the ivtv source, so you have to apply it there. I have personally only tested it for the trunk (bleeding edge development), but I expect no problems with the other versions since the code touched by this patch is pretty much unchanged since ivtv-0.2. Please test this thoroughly. Especially in combination with MythTV. If you can, also combine it with MPEG decoding, VBI recording, X-driver, etc. Some background information: There are several possible DMA errors. One in particular is causing all the problems. When a DMA write error occurs it seems the DMA engine of the card gets confused as to what the start address is of the card's buffers. After the DMA error the start of a buffer is set between 0 and 128 bytes before the actual start. Luckily for me it is not trashed, but always limited between 0 and 128 bytes. So my solution is to write a special 32-bit start marker value at the start of the buffer on the card (taking care to first read the original value), then start the DMA, but making the total size 256 bytes more than is strictly necessary. When the DMA is finished I check whether I detect the marker value at the expected place. If not, then I look for it in the first 128 bytes. The place where I find the marker is the new offset. I now replace the marker with the original value I saved earlier and I have a complete buffer. Because I actually DMA a bit more than is needed, I still have all data, even if it is shifted the maximum of 128 bytes. Without the extra DMA length the latter 128 bytes might never be copied by the DMA engine, so that's the reason for the extra length. This solution is very fast so there is no performance penalty. During stress testing (lots of CPU frequency changes) you will see these DMA errors occurring, but rather than giving you a broken MPEG stream the DMA will be retried and the new offset found to keep the MPEG stream uncorrupted. If you get a burst of these DMA errors (again, we're talking continuous CPU frequency changes here, not a normal situation), then some corruption may occur but it should be only for a few frames. As far as I can tell this particular DMA error is now handled correctly. Unfortunately there is still a 'ENC: REG_DMAXFER 2 wait failed' error where it looks like the complete DMA engine is stalled. Again, reboot is the only option. It only occurs during a very heavy load and I don't think it will happen during normal operation. I'm not sure whether this can be fixed at the moment. There are still some problems with the way the current DMA handling is done with possible race conditions. I need more research and testing to determine whether this is something that can be solved. Please keep me informed on how this works, if the test results are positive then I'll make new releases next week. Enjoy (I hope :-), Hans _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
