diff options
| author | Paul Walmsley <paul@booyaka.com> | 2010-10-09 01:31:40 -0300 |
|---|---|---|
| committer | Mauro Carvalho Chehab <mchehab@redhat.com> | 2010-10-21 07:54:24 -0200 |
| commit | 2962fc0120dc73a17fdf350754c9a3c15726baaa (patch) | |
| tree | 0e13d3ed90c90fc105505fd8e7ec1909961a0a83 /drivers/media/video/tvp5150.c | |
| parent | a06423c9a264d99345e1b5a04d5ced1168c609b8 (diff) | |
[media] tvp5150: COMPOSITE0 input should not force-enable TV mode
When digitizing composite video from a analog videotape source using the
TVP5150's first composite input channel, the captured stream exhibits
tearing and synchronization problems[1].
It turns out that commit c0477ad9feca01bd8eff95d7482c33753d05c700 caused
"TV mode" (as opposed to "VCR mode" or "auto-detect") to be forcibly
enabled for both composite inputs. According to the chip
documentation[2], "TV mode" disables a "chrominance trap" input filter,
which appears to be necessary for high-quality video capture from an
analog videotape source. [ Commit
c7c0b34c27bbf0671807e902fbfea6270c8f138d subsequently restricted the
problem to the first composite input, apparently inadvertently. ]
Since any type of composite signal source can be connected to the
TVP5150's first composite input, unconditionally forcing "TV mode" isn't
correct. There doesn't appear to be a good way for applications to tell
the driver what is connected. Fortunately, the TVP5150 has an operating
mode auto-detection feature, which, when enabled, should cause the TVP5150
to auto-detect whether it should use "VCR mode" or "TV mode". Enabling
operating mode auto-detection improved video capture quality
significantly[3].
Therefore, fix this bug by using operating mode auto-detection. (Also,
while here, fix a CodingStyle issue.)
For those users who may find this patch via a mailing list archive but who
are not able to upgrade to a kernel with a fixed driver: the TVP5150's
S-Video and second composite input sources have auto-detection enabled, so
you may wish to try using those -- if available on your device -- until
this fix makes it a downstream distribution near you.
1. Pre-patch tvtime snapshot using a Pinnacle PCTV HD Pro as the
capture device and a Sony EV-S2000 as a video source:
http://www.booyaka.com/~paul/tvp5150/1a.png
2. Section 3.21.3, "Operation Mode Control Register", _TVP5150AM1
Ultralow-Power NTSC/PAL/SECAM Video Decoder (Rev. D)_ [SLES209D],
downloaded 8 October 2010, available via
http://focus.ti.com/lit/ds/symlink/tvp5150am1.pdf
3. Post-patch tvtime snapshot (same signal chain as #1, above):
http://www.booyaka.com/~paul/tvp5150/1b.png
Signed-off-by: Paul Walmsley <paul@booyaka.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'drivers/media/video/tvp5150.c')
| -rw-r--r-- | drivers/media/video/tvp5150.c | 4 |
1 files changed, 1 insertions, 3 deletions
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c index d62a78688b08..58927664d3ea 100644 --- a/drivers/media/video/tvp5150.c +++ b/drivers/media/video/tvp5150.c @@ -276,7 +276,7 @@ static int tvp5150_log_status(struct v4l2_subdev *sd) static inline void tvp5150_selmux(struct v4l2_subdev *sd) { - int opmode=0; + int opmode = 0; struct tvp5150 *decoder = to_tvp5150(sd); int input = 0; unsigned char val; @@ -289,12 +289,10 @@ static inline void tvp5150_selmux(struct v4l2_subdev *sd) input |= 2; /* fall through */ case TVP5150_COMPOSITE0: - opmode=0x30; /* TV Mode */ break; case TVP5150_SVIDEO: default: input |= 1; - opmode=0; /* Auto Mode */ break; } |