> I've just found that the delay changes partially break my patch. Full res > captures are fine with no ghosting or flickering, but the new delays > consistently break scaled captures, with ghosting every time. > > My patch only seems to work properly with the current kernel version, which > has a single 300ms delay before CX2341X_ENC_INITIALIZE_INPUT. (260ms also > seems to work, but 250ms does not). There must be no delay between the init > & capture start, as that also breaks things. > > I've reverted the delay changes on my test box, and it's now running the > following without problems. This is identical to the ivtv driver in 2.6.32. > > /* Avoid unpredictable PCI bus hang - disable video clocks */ > v4l2_subdev_call(itv->sd_video, video, s_stream, 0); > ivtv_msleep_timeout(300, 1); > ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0); > v4l2_subdev_call(itv->sd_video, video, s_stream, 1); > } > > Depending on what you found with your delay tests, it may be that the delay > required is different depending on the hardware in use.
This code should also be fine as long as it concerns the "black screen" problem. The summary of my testings (see table in http://ivtvdriver.org/pipermail/ivtv- devel/2010-January/006381.html) was that it is not important if we do a single sleep or split them. The only important thing is that we have a total delay of 300ms before starting capture. I can't say if this code still solves the audio problem (which was the original intention of Andys changes). I never had any audio problem, and I don't know if there is any final feedback from the original poster of the audio problem. Martin _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
