]> www.pilppa.org Git - linux-2.6-omap-h63xx.git/commitdiff
V4L/DVB (4380): Bttv: Revert VBI_OFFSET to previous value, it works better
authorTrent Piepho <xyzzy@speakeasy.org>
Wed, 26 Jul 2006 20:08:29 +0000 (17:08 -0300)
committerMauro Carvalho Chehab <mchehab@infradead.org>
Sat, 29 Jul 2006 20:22:39 +0000 (17:22 -0300)
A previous patch changed VBI_OFFSET to match what the datasheets say it
should be.  However, the bt8x8 datasheets are wrong.  The old value of
244 is closer to what is actually observed.  The real value appears to
not be constant and is different for different chip revisions.
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
drivers/media/video/bt8xx/bttv-vbi.c

index 8c9f0f7cf467734b1ef69e252f8ce6a86f3f1199..63676e7bd635f6b403a69be86e0e24d602c56337 100644 (file)
 #include <asm/io.h>
 #include "bttvp.h"
 
-/* Offset from line sync pulse leading edge (0H) in 1 / sampling_rate:
-   bt8x8 /HRESET pulse starts at 0H and has length 64 / fCLKx1 (E|O_VTC
-   HSFMT = 0). VBI_HDELAY (always 0) is an offset from the trailing edge
-   of /HRESET in 1 / fCLKx1, and the sampling_rate tvnorm->Fsc is fCLKx2. */
-#define VBI_OFFSET ((64 + 0) * 2)
+/* Offset from line sync pulse leading edge (0H) to start of VBI capture,
+   in fCLKx2 pixels.  According to the datasheet, VBI capture starts
+   VBI_HDELAY fCLKx1 pixels from the tailing edgeof /HRESET, and /HRESET
+   is 64 fCLKx1 pixels wide.  VBI_HDELAY is set to 0, so this should be
+   (64 + 0) * 2 = 128 fCLKx2 pixels.  But it's not!  The datasheet is
+   Just Plain Wrong.  The real value appears to be different for
+   different revisions of the bt8x8 chips, and to be affected by the
+   horizontal scaling factor.  Experimentally, the value is measured
+   to be about 244.  */
+#define VBI_OFFSET 244
 
 #define VBI_DEFLINES 16
 #define VBI_MAXLINES 32