patch-2.3.38 linux/Documentation/video4linux/zr36120.txt

• Lines: 35
• Date: Thu Jan 6 14:46:18 2000
• Orig file: v2.3.37/linux/Documentation/video4linux/zr36120.txt
• Orig date: Tue Dec 7 09:32:39 1999

diff -u --recursive --new-file v2.3.37/linux/Documentation/video4linux/zr36120.txt linux/Documentation/video4linux/zr36120.txt
@@ -31,20 +31,20 @@
 on the I2C interface. The Zoran chip includes 2 lines SDA and SCL
 which (s)he connected reversely. So we have to clock on the SDA
 and r/w data on the SCL pin. Life is fun... Each cardtype now has
-a bit which signifies if you have a card with the same deficiancy.
+a bit which signifies if you have a card with the same deficiency.
 
-Oh, for the completness of this story I must mention that my
+Oh, for the completeness of this story I must mention that my
 card delivers the VSYNC pulse of the SAA chip to GIRQ1, not
-GIRQ0 as some other cards have. This is also incorperated in
+GIRQ0 as some other cards have. This is also incorporated in
 the driver be clearing/setting the 'useirq1' bit in the tvcard
 description.
 
-Another problems of contingious capturing data with a Zoran chip
+Another problems of continuous capturing data with a Zoran chip
 is something nasty inside the chip. It effectively halves the
 fps we ought to get... Here is the scenario: capturing frames
 to memory is done in the so-called snapshot mode. In this mode
 the Zoran stops after capturing a frame worth of data and wait
-till the application set GRAB bit to indicate readyness for the
+till the application set GRAB bit to indicate readiness for the
 next frame. After detecting a set bit, the chip neetly waits
 till the start of a frame, captures it and it goes back to off.
 Smart ppl will notice the problem here. Its the waiting on the
@@ -101,7 +101,7 @@
 	mknod /dev/video3 c 81 3
 	mknod /dev/video4 c 81 4
 
-After makeing/checking the devices do:
+After making/checking the devices do:
 	modprobe i2c
 	modprobe videodev
 	modprobe saa7110	(optional)