OMAP3 ISP & BT656
I have a number of boards with OMAP 3530/3730 that use the TVP5150AM1 video decoder. On most of these boards, I can capture reasonable quality video. However, I have some (more than a few which is reason for concern) where the video is either really bad or even the ISP doesn't seem to recognize the BT656 data stream. On the ones that have "bad" video, the data is all blown out and barely recognizable.
All the boards are running the same kernel (3.0+ with the YUV patches that Lennart and others proposed late last year). I've verified that the component registers (ISPCCDC and TVP5150) match. I can't see what could be the cause of such radically variable behaviour.
The one thing I've found is on the boards that don't work at all, the CCDC_SYN_MODE[FLDSTAT] bit is not toggling, which in turn causes no data to be pushed through the V4L2 pipeline.
Any ideas what can cause this? More importantly, what I can try to fix it? The really scary thing is that all the boards in my lab work great, but in the factory (some 6000 miles away), more than not don't work :-(
Would it be possible to configure the CCDC to capture the raw BT656 data? These boards are very small and it's impossible to get onto the video data lines going into the processor (they are all hidden within the circuit board).
Any help/ideas gladly accepted.
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 8 lines · Gary Thomas
I have a number of boards with OMAP 3530/3730 that use the TVP5150AM1 video decoder. On most of these boards, I can capture reasonable quality video. However, I have some (more than a few which is reason for concern) where the video is either really bad or even the ISP doesn't seem to recognize the BT656 data stream. On the ones that have "bad" video, the data is all blown out and barely recognizable.
Quoted 5 lines
All the boards are running the same kernel (3.0+ with the YUV patches that Lennart and others proposed late last year). I've verified that the component registers (ISPCCDC and TVP5150) match. I can't see what could be the cause of such radically variable behaviour.
Sorry, attribution should be to Laurent Pinchart :-)
Quoted 17 lines
The one thing I've found is on the boards that don't work at all, the CCDC_SYN_MODE[FLDSTAT] bit is not toggling, which in turn causes no data to be pushed through the V4L2 pipeline.
Any ideas what can cause this? More importantly, what I can try to fix it? The really scary thing is that all the boards in my lab work great, but in the factory (some 6000 miles away), more than not don't work :-(
Would it be possible to configure the CCDC to capture the raw BT656 data? These boards are very small and it's impossible to get onto the video data lines going into the processor (they are all hidden within the circuit board).
Any help/ideas gladly accepted.
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Hi Gary,
Quoted 23 lines · On Tuesday 17 January 2012 14:50:49 you wrote:
I have a number of boards with OMAP 3530/3730 that use the TVP5150AM1 video decoder. On most of these boards, I can capture reasonable quality video. However, I have some (more than a few which is reason for concern) where the video is either really bad or even the ISP doesn't seem to recognize the BT656 data stream. On the ones that have "bad" video, the data is all blown out and barely recognizable.
All the boards are running the same kernel (3.0+ with the YUV patches that Lennart and others proposed late last year). I've verified that the component registers (ISPCCDC and TVP5150) match. I can't see what could be the cause of such radically variable behaviour.
The one thing I've found is on the boards that don't work at all, the CCDC_SYN_MODE[FLDSTAT] bit is not toggling, which in turn causes no data to be pushed through the V4L2 pipeline.
Any ideas what can cause this? More importantly, what I can try to fix it? The really scary thing is that all the boards in my lab work great, but in the factory (some 6000 miles away), more than not don't work :-(
Quoted 6 lines
Would it be possible to configure the CCDC to capture the raw BT656 data? These boards are very small and it's impossible to get onto the video data lines going into the processor (they are all hidden within the circuit board).
Any help/ideas gladly accepted.
I realize this is a *really* late reply :-)
Just for your information, I've posted patches to the linux-media mailing list that add BT.656 support to the OMAP3 ISP driver. I've CC'ed you, in case you would find them useful and/or want to test them.
I'm also wondering whether you have been to fix the BT.656 issue you've described here.
Signature · 3 lines
Regards, Laurent Pinchart