Hello Javier, Mauro, Laurent, I hope all is well with you. Mauro, Laurent: you guys going to ELC/Portland in February? Looks like the refactoring done to tvp5150 in January 2016 for s_stream() to support some embedded platform caused breakage in the 30+ em28xx products that also use the chip. Problem confirmed on both the Startech SVIDUSB2 board Steve Preston was nice enough to ship me (after adding a board profile), as well as on my original HVR-950 which has worked fine since 2008. The implementation tramples the TVP5150_MISC_CTL register, blowing into it a hard-coded value based on one of two scenarios, neither of which matches what is expected by em28xx devices. At least in the case of NTSC, this results in chroma cycling. This was also reported by Alexandre-Xavier Labonté-Lamoureux back in August, although in the video below he's also having some other issue related to progressive video because he's using an old gaming console as the source (i.e. pay attention to the chroma effects in the top half of the video rather than the fact that only the first field is being rendered). https://youtu.be/WLlqJ7T3y4g The s_stream implementation writes 0x09 or 0x0d into TVP5150_MISC_CTL (overriding whatever was written by tvp5150_init_default and tvp5150_selmux(). In fact, just as a test I was able to start up video, see the corruption, and write the correct value back into the register via v4l2-dbg in order to get it working again: sudo v4l2-dbg --chip=subdev0 --set-register=0x03 0x6f There's no easy fix for this without extending the driver to support proper configuration of the output pin muxing, which it isn't clear to me what the right approach is and I don't have the embedded hardware platform that prompted the refactoring in order to do regression testing anyway. Feel free to take it upon yourselves to fix the regression you introduced. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
