Hi Mike, On Sun, Feb 26, 2012 at 6:56 AM, R.M. Thomas <rmthomas@xxxxxxxxxxx> wrote: > Hi Ezequiel, > > As you probably know, I originally developed the driver on the Sourceforge > site. Before uploading any new version of the driver I carried out > extensive automated testing using various scripts I had written for this > purpose. I attach the tarball for the final version of the Sourceforge > driver in order to explain what I mean. When you unpack the tarball you > will find the script ./tools/checktestPAL.sh, and you will see that this > runs the script ./testPAL.sh unattended for 36 test cases. > > Early versions of the driver did not have the extra reset() calls, and I > found that when I carried out the automated testing with > ./tools/checktestPAL.sh and similar scripts the EasyCAP would sometimes fail > to initialize correctly. In these cases no video stream was visible, with > mplayer then displaying an unchanging green or black window. On average, I > would see this failure in 5-10% of the test cases, but the behavior was not > reproducible: failure would occur randomly on different test cases when I > ran ./tools/checktestPAL.sh again. > > I never discovered what caused the failures. I assumed (without any > evidence) that one of the EasyCAP chips was prone to latch-up or some > similar hardware problem, but I may have been wrong about this. The > practical workaround which I found was to forcibly reset the hardware > registers whenever the driver detected problems at initialization. This is > the reason for the time-consuming repeated use of the function reset(). > > It would certainly be desirable to remove the extra reset() calls if > possible, and I hope you will be able to do so. However, I suggest that > driver modifications involving reset() should be subjected to automated > testing, because any resulting problems may not be apparent if testing is > limited to one or two cases. > I see. I'll pospone the reset() patch until further testing shows it is stable enough. Thanks a lot for the test scripts, they'll be of much help. > On a more general point, I believe the easycap driver would benefit from > some radical rewriting. At present it is not integrated with the V4L2 > mainstream (for historical reasons), and this needs to be corrected: > > https://lkml.org/lkml/2010/11/29/376 That's true. However, the driver works fine and I'm not sure a complete rewrite is a good option. > > Unfortunately I cannot contribute to this myself, not only because I am > fully committed now to an entirely different project, but also because I > know so little about the V4L2 infrastructure that I could not be of much > use. I do hope you will be able to make some progress with it. > I understand. I also hope we make some progress with it :) If it is at all possible I would like to ask you to send me any information about the driver you have, I mean datasheets and that sort of stuff. Thanks a lot for your feedback, Ezequiel. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
