summaryrefslogtreecommitdiffstats
path: root/Documentation/video4linux
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/video4linux')
-rw-r--r--Documentation/video4linux/README.pvrusb22
-rw-r--r--Documentation/video4linux/bttv/Insmod-options2
-rw-r--r--Documentation/video4linux/bttv/README2
-rw-r--r--Documentation/video4linux/bttv/README.freeze2
-rw-r--r--Documentation/video4linux/bttv/Sound-FAQ4
-rw-r--r--Documentation/video4linux/et61x251.txt4
-rw-r--r--Documentation/video4linux/pxa_camera.txt8
-rw-r--r--Documentation/video4linux/sh_mobile_ceu_camera.txt6
-rw-r--r--Documentation/video4linux/sn9c102.txt4
-rw-r--r--Documentation/video4linux/v4l2-framework.txt2
-rw-r--r--Documentation/video4linux/w9968cf.txt2
-rw-r--r--Documentation/video4linux/zc0301.txt6
12 files changed, 22 insertions, 22 deletions
diff --git a/Documentation/video4linux/README.pvrusb2 b/Documentation/video4linux/README.pvrusb2
index a747200fe67..2137b589276 100644
--- a/Documentation/video4linux/README.pvrusb2
+++ b/Documentation/video4linux/README.pvrusb2
@@ -172,7 +172,7 @@ Source file list / functional overview:
to provide a streaming API usable by a read() system call style of
I/O. Right now this is the only layer on top of pvrusb2-io.[ch],
however the underlying architecture here was intended to allow for
- other styles of I/O to be implemented with additonal modules, like
+ other styles of I/O to be implemented with additional modules, like
mmap()'ed buffers or something even more exotic.
pvrusb2-main.c - This is the top level of the driver. Module level
diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options
index bbe3ed667d9..14c065fa23e 100644
--- a/Documentation/video4linux/bttv/Insmod-options
+++ b/Documentation/video4linux/bttv/Insmod-options
@@ -1,5 +1,5 @@
-Note: "modinfo <module>" prints various informations about a kernel
+Note: "modinfo <module>" prints various information about a kernel
module, among them a complete and up-to-date list of insmod options.
This list tends to be outdated because it is updated manually ...
diff --git a/Documentation/video4linux/bttv/README b/Documentation/video4linux/bttv/README
index 3a367cdb664..7cbf4fb6cf3 100644
--- a/Documentation/video4linux/bttv/README
+++ b/Documentation/video4linux/bttv/README
@@ -70,7 +70,7 @@ If you have trouble with some specific TV card, try to ask there
instead of mailing me directly. The chance that someone with the
same card listens there is much higher...
-For problems with sound: There are alot of different systems used
+For problems with sound: There are a lot of different systems used
for TV sound all over the world. And there are also different chips
which decode the audio signal. Reports about sound problems ("stereo
does'nt work") are pretty useless unless you include some details
diff --git a/Documentation/video4linux/bttv/README.freeze b/Documentation/video4linux/bttv/README.freeze
index 4259dccc828..5eddfa076cf 100644
--- a/Documentation/video4linux/bttv/README.freeze
+++ b/Documentation/video4linux/bttv/README.freeze
@@ -33,7 +33,7 @@ state is stuck.
I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid
for some people. Thus probably a small buglet left somewhere in bttv
-0.7.x. I have no idea where exactly, it works stable for me and alot of
+0.7.x. I have no idea where exactly, it works stable for me and a lot of
other people. But in case you have problems with the 0.7.x versions you
can give 0.8.x a try ...
diff --git a/Documentation/video4linux/bttv/Sound-FAQ b/Documentation/video4linux/bttv/Sound-FAQ
index 1e6328f9108..395f6c6fdd9 100644
--- a/Documentation/video4linux/bttv/Sound-FAQ
+++ b/Documentation/video4linux/bttv/Sound-FAQ
@@ -2,13 +2,13 @@
bttv and sound mini howto
=========================
-There are alot of different bt848/849/878/879 based boards available.
+There are a lot of different bt848/849/878/879 based boards available.
Making video work often is not a big deal, because this is handled
completely by the bt8xx chip, which is common on all boards. But
sound is handled in slightly different ways on each board.
To handle the grabber boards correctly, there is a array tvcards[] in
-bttv-cards.c, which holds the informations required for each board.
+bttv-cards.c, which holds the information required for each board.
Sound will work only, if the correct entry is used (for video it often
makes no difference). The bttv driver prints a line to the kernel
log, telling which card type is used. Like this one:
diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt
index 1247566c4de..e0cdae49185 100644
--- a/Documentation/video4linux/et61x251.txt
+++ b/Documentation/video4linux/et61x251.txt
@@ -191,10 +191,10 @@ Syntax: <n>
Description: Debugging information level, from 0 to 3:
0 = none (use carefully)
1 = critical errors
- 2 = significant informations
+ 2 = significant information
3 = more verbose messages
Level 3 is useful for testing only, when only one device
- is used at the same time. It also shows some more informations
+ is used at the same time. It also shows some more information
about the hardware being detected. This module parameter can be
changed at runtime thanks to the /sys filesystem interface.
Default: 2
diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt
index 4f6d0ca0195..51ed1578b0e 100644
--- a/Documentation/video4linux/pxa_camera.txt
+++ b/Documentation/video4linux/pxa_camera.txt
@@ -84,12 +84,12 @@ DMA usage
transfer is not started. On "End Of Frame" interrupt, the irq handler
starts the DMA chain.
- capture of one videobuffer
- The DMA chain starts transfering data into videobuffer RAM pages.
- When all pages are transfered, the DMA irq is raised on "ENDINTR" status
+ The DMA chain starts transferring data into videobuffer RAM pages.
+ When all pages are transferred, the DMA irq is raised on "ENDINTR" status
- finishing one videobuffer
The DMA irq handler marks the videobuffer as "done", and removes it from
the active running queue
- Meanwhile, the next videobuffer (if there is one), is transfered by DMA
+ Meanwhile, the next videobuffer (if there is one), is transferred by DMA
- finishing the last videobuffer
On the DMA irq of the last videobuffer, the QCI is stopped.
@@ -101,7 +101,7 @@ DMA usage
This structure is pointed by dma->sg_cpu.
The descriptors are used as follows :
- - desc-sg[i]: i-th descriptor, transfering the i-th sg
+ - desc-sg[i]: i-th descriptor, transferring the i-th sg
element to the video buffer scatter gather
- finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
- linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0
diff --git a/Documentation/video4linux/sh_mobile_ceu_camera.txt b/Documentation/video4linux/sh_mobile_ceu_camera.txt
index cb47e723af7..1e96ce6e2d2 100644
--- a/Documentation/video4linux/sh_mobile_ceu_camera.txt
+++ b/Documentation/video4linux/sh_mobile_ceu_camera.txt
@@ -37,7 +37,7 @@ Generic scaling / cropping scheme
-1'-
In the above chart minuses and slashes represent "real" data amounts, points and
-accents represent "useful" data, basically, CEU scaled amd cropped output,
+accents represent "useful" data, basically, CEU scaled and cropped output,
mapped back onto the client's source plane.
Such a configuration can be produced by user requests:
@@ -65,7 +65,7 @@ Do not touch input rectangle - it is already optimal.
1. Calculate current sensor scales:
- scale_s = ((3') - (3)) / ((2') - (2))
+ scale_s = ((2') - (2)) / ((3') - (3))
2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
current sensor scales onto input window - this is user S_CROP:
@@ -80,7 +80,7 @@ window:
4. Calculate sensor output window by applying combined scales to real input
window:
- width_s_out = ((2') - (2)) / scale_comb
+ width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
5. Apply iterative sensor S_FMT for sensor output window.
diff --git a/Documentation/video4linux/sn9c102.txt b/Documentation/video4linux/sn9c102.txt
index 73de4050d63..b4f67040403 100644
--- a/Documentation/video4linux/sn9c102.txt
+++ b/Documentation/video4linux/sn9c102.txt
@@ -214,10 +214,10 @@ Syntax: <n>
Description: Debugging information level, from 0 to 3:
0 = none (use carefully)
1 = critical errors
- 2 = significant informations
+ 2 = significant information
3 = more verbose messages
Level 3 is useful for testing only. It also shows some more
- informations about the hardware being detected.
+ information about the hardware being detected.
This parameter can be changed at runtime thanks to the /sys
filesystem interface.
Default: 2
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index 3b15608ee07..cf21f7aae97 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -343,7 +343,7 @@ ignored. If you want to check for errors use this:
err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip);
Any error except -ENOIOCTLCMD will exit the loop with that error. If no
-errors (except -ENOIOCTLCMD) occured, then 0 is returned.
+errors (except -ENOIOCTLCMD) occurred, then 0 is returned.
The second argument to both calls is a group ID. If 0, then all subdevs are
called. If non-zero, then only those whose group ID match that value will
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt
index 05138e8aea0..9649450f3b9 100644
--- a/Documentation/video4linux/w9968cf.txt
+++ b/Documentation/video4linux/w9968cf.txt
@@ -413,7 +413,7 @@ Syntax: <n>
Description: Debugging information level, from 0 to 6:
0 = none (use carefully)
1 = critical errors
- 2 = significant informations
+ 2 = significant information
3 = configuration or general messages
4 = warnings
5 = called functions
diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt
index befdfdacdc5..b41c83cf09f 100644
--- a/Documentation/video4linux/zc0301.txt
+++ b/Documentation/video4linux/zc0301.txt
@@ -181,10 +181,10 @@ Syntax: <n>
Description: Debugging information level, from 0 to 3:
0 = none (use carefully)
1 = critical errors
- 2 = significant informations
+ 2 = significant information
3 = more verbose messages
Level 3 is useful for testing only, when only one device
- is used at the same time. It also shows some more informations
+ is used at the same time. It also shows some information
about the hardware being detected. This module parameter can be
changed at runtime thanks to the /sys filesystem interface.
Default: 2
@@ -261,7 +261,7 @@ the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'.
11. Credits
===========
-- Informations about the chip internals needed to enable the I2C protocol have
+- Information about the chip internals needed to enable the I2C protocol have
been taken from the documentation of the ZC030x Video4Linux1 driver written
by Andrew Birkett <andy@nobugs.org>;
- The initialization values of the ZC0301 controller connected to the PAS202BCB