Hmm, it turns out that I generated the patch for ivtv-0.10.x against an old ivtv version. Sorry about that. I've now committed the changes to the ivtv-0.10 branch, so you can also just download this link:
http://ivtvdriver.org/viewcvs/ivtv/branches/0.10.tar.gz?view=tar And for the 2.6.22 and up kernels you can get a v4l-dvb repository containing these changes here: http://www.linuxtv.org/hg/~hverkuil/ivtv-dma/archive/tip.tar.bz2 Regards, Hans On Saturday 28 July 2007 13:21, Hans Verkuil wrote: > Attached are two new patches: it turned out that an extra wait was > necessary, otherwise flickering could still occur even though > INITIALIZE_INPUT would no longer freeze. > > Regards, > > Hans > > On Saturday 28 July 2007 12:30, Hans Verkuil wrote: > > Hi all, > > > > There have been various bug reports lately regarding freezing of > > the PC when starting a capture or when changing channels. > > > > I've been stress testing this yesterday and today and I believe I > > have found and fixed the problem. And as an additional bonus I > > believe that this patch also fixes the bug that sometimes occurs > > where the top third of the captured screen is continuously > > flickering. > > > > I've attached two patches: ivtv-0.10.diff is against ivtv-0.10 and > > ivtv.diff is against the > > http://www.linuxtv.org/hg/~hverkuil/v4l-dvb repository (for kernels > > >= 2.6.22). > > > > These patches also make an important change in the behavior of the > > driver: if a capture is in progress, then it is no longer possible > > to change inputs or open the radio device. EBUSY is returned as an > > error. > > > > The underlying problem was the use of the > > CX2341X_ENC_INITIALIZE_INPUT firmware call. This call should be > > made whenever the digitizer (saa7115 or cx25840) has changed, > > either because the TV standard was changed, another input was > > chosen or the video format changes (e.g. capture size, VBI > > settings). But it turned out that the digitizer has to be turned > > off before calling this API and turned on afterwards. This is > > definitely the case for the saa7115, the cx25840 seems to be more > > forgiving. > > > > If the digitizer is NOT turned off, then this FW call can sometimes > > freeze your PC: it looks like the MPEG card crashes and freezes the > > PCI bus. Any PCI access simply freezes everything. > > > > The problem was that CX2341X_ENC_INITIALIZE_INPUT was called on > > every channel change, even though there was no need to call it at > > that time. So this call was removed. > > > > The CX2341X_ENC_INITIALIZE_INPUT was also called on the start of a > > capture and ensures that the MPEG encoder has the correct digitizer > > settings. If this is not called, then flickering may occur. > > > > Opening the radio device or changing input also requires a call to > > CX2341X_ENC_INITIALIZE_INPUT. However, testing showed that this > > call doesn't do anything when a capture is in progress, hence the > > new requirement that the radio device or changing inputs can only > > be done when no capture is running. Otherwise, changing inputs in > > midstream can cause flickering. > > > > While running a stress test app I also noticed that when recordings > > are stopped and started in quick succession the start of the > > capture can sometimes be garbled. It is actually a left-over from > > the previous capture. It turns out that stopping the capture needs > > to wait a bit (100 ms is enough) to make sure the last pending > > interrupts are handled. This actually makes for simpler code and > > works very well. > > > > Please test this patch, whether or not you have these problems. I'd > > like to get some feedback on this! > > > > Thanks, > > > > Hans > > > > The CX2341X_ENC_INITIALIZE_INPUT firmware call is very important _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
