redonkable/alistair23-linux
redonkable/alistair23-linux
1
0
Fork 0
Code Releases Activity

V4L/DVB (10854): cx18: Correct comments about vertical and horizontal blanking timings

Browse source 
This change only affects comments.

Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This commit is contained in:
Andy Walls 2009-02-28 20:13:50 -03:00 committed by Mauro Carvalho Chehab
parent 583803d135
commit af7c58b1f5
3 changed files with 30 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
drivers/media/video/cx18/cx18-av-core.c
View file

@ -292,23 +292,29 @@ void cx18_av_std_setup(struct cx18 *cx)
*
* vsync: always 6 half-lines of vsync pulses
* vactive: half lines of active video
* vblank656: half lines, after line 3, of blanked video
* vblank: half lines, after line 9, of blanked video
* vblank656: half lines, after line 3/mid-266, of blanked video
* vblank: half lines, after line 9/272, of blanked video
*
* As far as I can tell:
* vblank656 starts counting from the falling edge of the first
* vsync pulse (start of line 4)
* vsync pulse (start of line 4 or mid-266)
* vblank starts counting from the after the 6 vsync pulses and
* 6 equalization pulses (start of line 10)
* 6 or 5 equalization pulses (start of line 10 or 272)
*
* For 525 line systems the driver will extract VBI information
* from lines 10 through 21. To avoid the EAV RP code from
* toggling at the start of hblank at line 22, where sliced VBI
* data from line 21 is stuffed, also treat line 22 as blanked.
* from lines 10-21 and lines 273-284.
*/
vblank656 = 38; /* lines 4 through 22 */
vblank = 26; /* lines 10 through 22 */
vactive = 481; /* lines 23 through 262.5 */
vblank656 = 38; /* lines 4 - 22 & 266 - 284 */
vblank = 26; /* lines 10 - 22 & 272 - 284 */
vactive = 481; /* lines 23 - 263 & 285 - 525 */
/*
* For a 13.5 Mpps clock and 15,734.26 Hz line rate, a line is
* is 858 pixels = 720 active + 138 blanking. The Hsync leading
* edge should happen 1.2 us * 13.5 Mpps ~= 16 pixels after the
* end of active video, leaving 122 pixels of hblank to ignore
* before active video starts.
*/
hactive = 720;
hblank = 122;
luma_lpf = 1;

19
drivers/media/video/cx18/cx18-av-core.h
View file

@ -89,16 +89,21 @@ struct cx18_av_state {
/*
* The VBI slicer starts operating and counting lines, begining at
* slicer line count of 1, at D lines after the deassertion of VRESET
* This staring field line, S, is 6 or 10 for 625 or 525 line systems.
* Sliced ancillary data captured on VBI slicer line M is sent at the
* beginning of the next VBI slicer line, VBI slicer line count N = M+1.
* Thus when the VBI slicer reports a VBI slicer line number with
* ancillary data, the IDID0 byte indicates VBI slicer line N.
* The actual field line that the captured data comes from is
* slicer line count of 1, at D lines after the deassertion of VRESET.
* This staring field line, S, is 6 (& 319) or 10 (& 273) for 625 or 525
* line systems respectively. Sliced ancillary data captured on VBI
* slicer line M is inserted after the VBI slicer is done with line M,
* when VBI slicer line count is N = M+1. Thus when the VBI slicer
* reports a VBI slicer line number with ancillary data, the IDID0 byte
* indicates VBI slicer line N. The actual field line that the captured
* data comes from is
*
* L = M+(S+D-1) = N-1+(S+D-1) = N + (S+D-2).
*
* L is the line in the field, not frame, from which the VBI data came.
* N is the line reported by the slicer in the ancillary data.
* D is the slicer_line_delay value programmed into register 0x47f.
* S is 6 for 625 line systems or 10 for 525 line systems
* (S+D-2) is the slicer_line_offset used to convert slicer reported
* line counts to actual field lines.
*/

5
drivers/media/video/cx18/cx18-streams.c
View file

@ -413,9 +413,8 @@ static void cx18_vbi_setup(struct cx18_stream *s)
* 0x90 (Task HorizontalBlank)
* 0xd0 (Task EvenField HorizontalBlank)
*
* We have set the digitzer to consider the first active line
* as part of VerticalBlank as well so we don't have to look for
* these problem codes nor lose the last line of sliced data.
* We have set the digitzer such that we don't have to worry
* about these problem codes.
*/
data[4] = 0xB0F0B0F0;
/*