Merge branch 'mpi-master' into wip-k-fmlpwip-k-fmlp

Conflicts:
	litmus/sched_cedf.c

28 files changed, 840 insertions, 565 deletions

diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88
index f2510541373b..42517d9121de 100644
--- a/Documentation/video4linux/CARDLIST.cx88
+++ b/Documentation/video4linux/CARDLIST.cx88
@@ -83,3 +83,4 @@
  82 -> WinFast DTV2000 H rev. J                            [107d:6f2b]
  83 -> Prof 7301 DVB-S/S2                                  [b034:3034]
  84 -> Samsung SMT 7020 DVB-S                              [18ac:dc00,18ac:dccd]
+ 85 -> Twinhan VP-1027 DVB-S                               [1822:0023]
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index 5c568757c301..9aae449440dc 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -1,5 +1,5 @@
   0 -> Unknown EM2800 video grabber             (em2800)        [eb1a:2800]
-  1 -> Unknown EM2750/28xx video grabber        (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2862,eb1a:2863,eb1a:2870,eb1a:2881,eb1a:2883,eb1a:2868]
+  1 -> Unknown EM2750/28xx video grabber        (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2862,eb1a:2863,eb1a:2870,eb1a:2881,eb1a:2883,eb1a:2868,eb1a:2875]
   2 -> Terratec Cinergy 250 USB                 (em2820/em2840) [0ccd:0036]
   3 -> Pinnacle PCTV USB 2                      (em2820/em2840) [2304:0208]
   4 -> Hauppauge WinTV USB 2                    (em2820/em2840) [2040:4200,2040:4201]
@@ -9,7 +9,7 @@
   8 -> Kworld USB2800                           (em2800)
   9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker  (em2820/em2840) [1b80:e302,1b80:e304,2304:0207,2304:021a]
  10 -> Hauppauge WinTV HVR 900                  (em2880)        [2040:6500]
- 11 -> Terratec Hybrid XS                       (em2880)        [0ccd:0042]
+ 11 -> Terratec Hybrid XS                       (em2880)
  12 -> Kworld PVR TV 2800 RF                    (em2820/em2840)
  13 -> Terratec Prodigy XS                      (em2880)        [0ccd:0047]
  14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 (em2820/em2840)
@@ -31,6 +31,7 @@
  30 -> Videology 20K14XUSB USB2.0               (em2820/em2840)
  31 -> Usbgear VD204v9                          (em2821)
  32 -> Supercomp USB 2.0 TV                     (em2821)
+ 33 -> Elgato Video Capture                     (em2860)        [0fd9:0033]
  34 -> Terratec Cinergy A Hybrid XS             (em2860)        [0ccd:004f]
  35 -> Typhoon DVD Maker                        (em2860)
  36 -> NetGMBH Cam                              (em2860)
@@ -45,15 +46,15 @@
  45 -> Pinnacle PCTV DVB-T                      (em2870)
  46 -> Compro, VideoMate U3                     (em2870)        [185b:2870]
  47 -> KWorld DVB-T 305U                        (em2880)        [eb1a:e305]
- 48 -> KWorld DVB-T 310U                        (em2880)        [eb1a:e310]
+ 48 -> KWorld DVB-T 310U                        (em2880)
  49 -> MSI DigiVox A/D                          (em2880)        [eb1a:e310]
  50 -> MSI DigiVox A/D II                       (em2880)        [eb1a:e320]
  51 -> Terratec Hybrid XS Secam                 (em2880)        [0ccd:004c]
  52 -> DNT DA2 Hybrid                           (em2881)
  53 -> Pinnacle Hybrid Pro                      (em2881)
  54 -> Kworld VS-DVB-T 323UR                    (em2882)        [eb1a:e323]
- 55 -> Terratec Hybrid XS (em2882)              (em2882)        [0ccd:005e]
- 56 -> Pinnacle Hybrid Pro (2)                  (em2882)        [2304:0226]
+ 55 -> Terratec Cinnergy Hybrid T USB XS (em2882) (em2882)        [0ccd:005e,0ccd:0042]
+ 56 -> Pinnacle Hybrid Pro (330e)               (em2882)        [2304:0226]
  57 -> Kworld PlusTV HD Hybrid 330              (em2883)        [eb1a:a316]
  58 -> Compro VideoMate ForYou/Stereo           (em2820/em2840) [185b:2041]
  60 -> Hauppauge WinTV HVR 850                  (em2883)        [2040:651f]
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 4000c29fcfb6..6b4c72d8862d 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -126,7 +126,7 @@
 125 -> Beholder BeholdTV 409                    [0000:4090]
 126 -> Beholder BeholdTV 505 FM                 [5ace:5050]
 127 -> Beholder BeholdTV 507 FM / BeholdTV 509 FM [5ace:5070,5ace:5090]
-128 -> Beholder BeholdTV Columbus TVFM          [0000:5201]
+128 -> Beholder BeholdTV Columbus TV/FM         [0000:5201]
 129 -> Beholder BeholdTV 607 FM                 [5ace:6070]
 130 -> Beholder BeholdTV M6                     [5ace:6190]
 131 -> Twinhan Hybrid DTV-DVB 3056 PCI          [1822:0022]
@@ -180,3 +180,5 @@
 179 -> Beholder BeholdTV A7                     [5ace:7090]
 180 -> Avermedia PCI M733A                      [1461:4155,1461:4255]
 181 -> TechoTrend TT-budget T-3000              [13c2:2804]
+182 -> Kworld PCI SBTVD/ISDB-T Full-Seg Hybrid  [17de:b136]
+183 -> Compro VideoMate Vista M1F               [185b:c900]
diff --git a/Documentation/video4linux/Makefile b/Documentation/video4linux/Makefile
deleted file mode 100644
index 1ed0e98d057d..000000000000
--- a/Documentation/video4linux/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-# kbuild trick to avoid linker error. Can be omitted if a module is built.
-obj- := dummy.o
-
-# List of programs to build
-hostprogs-y := v4lgrab
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
diff --git a/Documentation/video4linux/README.cpia b/Documentation/video4linux/README.cpia
deleted file mode 100644
index 8a747fee661f..000000000000
--- a/Documentation/video4linux/README.cpia
+++ /dev/null
@@ -1,191 +0,0 @@
-This is a driver for the CPiA PPC2 driven parallel connected
-Camera. For example the Creative WebcamII is CPiA driven.
-
-   ) [1]Peter Pregler, Linz 2000, published under the [2]GNU GPL
-
----------------------------------------------------------------------------
-
-USAGE:
-
-General:
-========
-
-1) Make sure you have created the video devices (/dev/video*):
-
-- if you have a recent MAKEDEV do a 'cd /dev;./MAKEDEV video'
-- otherwise do a:
-
-cd /dev
-mknod video0 c 81 0
-ln -s video0 video
-
-2) Compile the kernel (see below for the list of options to use),
-   configure your parport and reboot.
-
-3) If all worked well you should get messages similar
-   to the following (your versions may be different) on the console:
-
-V4L-Driver for Vision CPiA based cameras v0.7.4
-parport0: read2 timeout.
-parport0: Multimedia device, VLSI Vision Ltd PPC2
-Parallel port driver for Vision CPiA based camera
-  CPIA Version: 1.20 (2.0)
-  CPIA PnP-ID: 0553:0002:0100
-  VP-Version: 1.0 0100
-  1 camera(s) found
-
-
-As modules:
-===========
-
-Make sure you have selected the following kernel options (you can
-select all stuff as modules):
-
-The cpia-stuff is in the section 'Character devices -> Video For Linux'.
-
-CONFIG_PARPORT=m
-CONFIG_PARPORT_PC=m
-CONFIG_PARPORT_PC_FIFO=y
-CONFIG_PARPORT_1284=y
-CONFIG_VIDEO_DEV=m
-CONFIG_VIDEO_CPIA=m
-CONFIG_VIDEO_CPIA_PP=m
-
-For autoloading of all those modules you need to tell module-init-tools
-some stuff. Add the following line to your module-init-tools config-file
-(e.g. /etc/modprobe.conf or wherever your distribution does store that
-stuff):
-
-options parport_pc io=0x378 irq=7 dma=3
-alias char-major-81 cpia_pp
-
-The first line tells the dma/irq channels to use. Those _must_ match
-the settings of your BIOS. Do NOT simply use the values above.  See
-Documentation/parport.txt for more information about this. The second
-line associates the video-device file with the driver. Of cause you
-can also load the modules once upon boot (usually done in /etc/modules).
-
-Linked into the kernel:
-=======================
-
-Make sure you have selected the following kernel options. Note that
-you cannot compile the parport-stuff as modules and the cpia-driver
-statically (the other way round is okay though).
-
-The cpia-stuff is in the section 'Character devices -> Video For Linux'.
-
-CONFIG_PARPORT=y
-CONFIG_PARPORT_PC=y
-CONFIG_PARPORT_PC_FIFO=y
-CONFIG_PARPORT_1284=y
-CONFIG_VIDEO_DEV=y
-CONFIG_VIDEO_CPIA=y
-CONFIG_VIDEO_CPIA_PP=y
-
-To use DMA/irq you will need to tell the kernel upon boot time the
-hardware configuration of the parport. You can give the boot-parameter
-at the LILO-prompt or specify it in lilo.conf. I use the following
-append-line in lilo.conf:
-
-        append="parport=0x378,7,3"
-
-See Documentation/parport.txt for more information about the
-configuration of the parport and the values given above. Do not simply
-use the values given above.
-
----------------------------------------------------------------------------
-FEATURES:
-
-- mmap/read v4l-interface (but no overlay)
-- image formats: CIF/QCIF, SIF/QSIF, various others used by isabel;
-  note: all sizes except CIF/QCIF are implemented by clipping, i.e.
-  pixels are not uploaded from the camera
-- palettes: VIDEO_PALETTE_GRAY, VIDEO_PALETTE_RGB565, VIDEO_PALETTE_RGB555,
-  VIDEO_PALETTE_RGB24, VIDEO_PALETTE_RGB32, VIDEO_PALETTE_YUYV,
-  VIDEO_PALETTE_UYVY, VIDEO_PALETTE_YUV422
-- state information (color balance, exposure, ...) is preserved between
-  device opens
-- complete control over camera via proc-interface (_all_ camera settings are
-  supported), there is also a python-gtk application available for this [3]
-- works under SMP (but the driver is completely serialized and synchronous)
-  so you get no benefit from SMP, but at least it does not crash your box
-- might work for non-Intel architecture, let us know about this
-
----------------------------------------------------------------------------
-TESTED APPLICATIONS:
-
-- a simple test application based on Xt is available at [3]
-- another test-application based on gqcam-0.4 (uses GTK)
-- gqcam-0.6 should work
-- xawtv-3.x (also the webcam software)
-- xawtv-2.46
-- w3cam (cgi-interface and vidcat, e.g. you may try out 'vidcat  |xv
-  -maxpect -root -quit +noresetroot -rmode 5 -')
-- vic, the MBONE video conferencing tool (version 2.8ucl4-1)
-- isabel 3R4beta (barely working, but AFAICT all the problems are on
-  their side)
-- camserv-0.40
-
-See [3] for pointers to v4l-applications.
-
----------------------------------------------------------------------------
-KNOWN PROBLEMS:
-
-- some applications do not handle the image format correctly, you will
-  see strange horizontal stripes instead of a nice picture -> make sure
-  your application does use a supported image size or queries the driver
-  for the actually used size (reason behind this: the camera cannot
-  provide any image format, so if size NxM is requested the driver will
-  use a format to the closest fitting N1xM1, the application should now
-  query for this granted size, most applications do not).
-- all the todo ;)
-- if there is not enough light and the picture is too dark try to
-  adjust the SetSensorFPS setting, automatic frame rate adjustment
-  has its price
-- do not try out isabel 3R4beta (built 135), you will be disappointed
-
----------------------------------------------------------------------------
-TODO:
-
-- multiple camera support (struct camera or something) - This should work,
-  but hasn't been tested yet.
-- architecture independence?
-- SMP-safe asynchronous mmap interface
-- nibble mode for old parport interfaces
-- streaming capture, this should give a performance gain
-
----------------------------------------------------------------------------
-IMPLEMENTATION NOTES:
-
-The camera can act in two modes, streaming or grabbing. Right now a
-polling grab-scheme is used. Maybe interrupt driven streaming will be
-used for a asynchronous mmap interface in the next major release of the
-driver. This might give a better frame rate.
-
----------------------------------------------------------------------------
-THANKS (in no particular order):
-
-- Scott J. Bertin <sbertin@mindspring.com> for cleanups, the proc-filesystem
-  and much more
-- Henry Bruce <whb@vvl.co.uk> for providing developers information about
-  the CPiA chip, I wish all companies would treat Linux as seriously
-- Karoly Erdei <Karoly.Erdei@risc.uni-linz.ac.at> and RISC-Linz for being
-  my boss ;) resp. my employer and for providing me the hardware and
-  allow me to devote some working time to this project
-- Manuel J. Petit de Gabriel <mpetit@dit.upm.es> for providing help
-  with Isabel (http://isabel.dit.upm.es/)
-- Bas Huisman <bhuism@cs.utwente.nl> for writing the initial parport code
-- Jarl Totland <Jarl.Totland@bdc.no> for setting up the mailing list
-  and maintaining the web-server[3]
-- Chris Whiteford <Chris@informinteractive.com> for fixes related to the
-  1.02 firmware
-- special kudos to all the tester whose machines crashed and/or
-  will crash. :)
-
----------------------------------------------------------------------------
-REFERENCES
-
-   1. http://www.risc.uni-linz.ac.at/
-      mailto:Peter_Pregler@email.com
-   2. see the file COPYING in the top directory of the kernel tree
-   3. http://webcam.sourceforge.net/
diff --git a/Documentation/video4linux/README.ivtv b/Documentation/video4linux/README.ivtv
index 42b06686eb78..2579b5b709ed 100644
--- a/Documentation/video4linux/README.ivtv
+++ b/Documentation/video4linux/README.ivtv
@@ -36,8 +36,7 @@ Additional features for the PVR-350 (CX23415 based):
  * Provides comprehensive OSD (On Screen Display: ie. graphics overlaying the
    video signal)
  * Provides a framebuffer (allowing X applications to appear on the video
-   device) (this framebuffer is not yet part of the kernel. In the meantime it
-   is available from www.ivtvdriver.org).
+   device)
  * Supports raw YUV output.
 
 IMPORTANT: In case of problems first read this page:
diff --git a/Documentation/video4linux/README.pvrusb2 b/Documentation/video4linux/README.pvrusb2
index a747200fe67c..2137b589276b 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/Zoran b/Documentation/video4linux/Zoran
index 00e3f9267814..9ed629d4874b 100644
--- a/Documentation/video4linux/Zoran
+++ b/Documentation/video4linux/Zoran
@@ -130,7 +130,6 @@ Card number: 4
 
 Note: No module for the mse3000 is available yet
 Note: No module for the vpx3224 is available yet
-Note: use encoder=X or decoder=X for non-default i2c chips (see i2c-id.h)
 
 ===========================
 
@@ -322,76 +321,11 @@ your IRQs and make sure the card has its own interrupts.
 
 4. Programming interface
 
-This driver conforms to video4linux and video4linux2, both can be used to
-use the driver. Since video4linux didn't provide adequate calls to fully
-use the cards' features, we've introduced several programming extensions,
-which are currently officially accepted in the 2.4.x branch of the kernel.
-These extensions are known as the v4l/mjpeg extensions. See zoran.h for
-details (structs/ioctls).
-
-Information - video4linux:
-http://linux.bytesex.org/v4l2/API.html
-Documentation/video4linux/API.html
-/usr/include/linux/videodev.h
-
-Information - video4linux/mjpeg extensions:
-./zoran.h
-(also see below)
-
-Information - video4linux2:
-http://linuxtv.org
-http://v4l2spec.bytesex.org/
-/usr/include/linux/videodev2.h
-
-More information on the video4linux/mjpeg extensions, by Serguei
-Miridonovi and Rainer Johanni:
---
-The ioctls for that interface are as follows:
-
-BUZIOC_G_PARAMS
-BUZIOC_S_PARAMS
-
-Get and set the parameters of the buz. The user should always do a
-BUZIOC_G_PARAMS (with a struct buz_params) to obtain the default
-settings, change what he likes and then make a BUZIOC_S_PARAMS call.
-
-BUZIOC_REQBUFS
-
-Before being able to capture/playback, the user has to request
-the buffers he is wanting to use. Fill the structure
-zoran_requestbuffers with the size (recommended: 256*1024) and
-the number (recommended 32 up to 256). There are no such restrictions
-as for the Video for Linux buffers, you should LEAVE SUFFICIENT
-MEMORY for your system however, else strange things will happen ....
-On return, the zoran_requestbuffers structure contains number and
-size of the actually allocated buffers.
-You should use these numbers for doing a mmap of the buffers
-into the user space.
-The BUZIOC_REQBUFS ioctl also makes it happen, that the next mmap
-maps the MJPEG buffer instead of the V4L buffers.
-
-BUZIOC_QBUF_CAPT
-BUZIOC_QBUF_PLAY
-
-Queue a buffer for capture or playback. The first call also starts
-streaming capture. When streaming capture is going on, you may
-only queue further buffers or issue syncs until streaming
-capture is switched off again with a argument of -1 to
-a BUZIOC_QBUF_CAPT/BUZIOC_QBUF_PLAY ioctl.
-
-BUZIOC_SYNC
-
-Issue this ioctl when all buffers are queued. This ioctl will
-block until the first buffer becomes free for saving its
-data to disk (after BUZIOC_QBUF_CAPT) or for reuse (after BUZIOC_QBUF_PLAY).
-
-BUZIOC_G_STATUS
-
-Get the status of the input lines (video source connected/norm).
+This driver conforms to video4linux2. Support for V4L1 and for the custom
+zoran ioctls has been removed in kernel 2.6.38.
 
 For programming example, please, look at lavrec.c and lavplay.c code in
-lavtools-1.2p2 package (URL: http://www.cicese.mx/)
-and the 'examples' directory in the original Buz driver distribution.
+the MJPEG-tools (http://mjpeg.sf.net/).
 
 Additional notes for software developers:
 
@@ -402,9 +336,6 @@ Additional notes for software developers:
    standard is "more constant" for current country than geometry
    settings of a variety of TV capture cards which may work in ITU or
    square pixel format.
---
-Please note that lavplay/lavrec are also included in the MJPEG-tools
-(http://mjpeg.sf.net/).
 
 ===========================
 
diff --git a/Documentation/video4linux/bttv/Cards b/Documentation/video4linux/bttv/Cards
index 12217fc49725..db833ced2cb8 100644
--- a/Documentation/video4linux/bttv/Cards
+++ b/Documentation/video4linux/bttv/Cards
@@ -464,10 +464,6 @@ Siemens
 -------
    Multimedia eXtension Board (MXB) (SAA7146, SAA7111)
 
-Stradis
--------
-   SDM275,SDM250,SDM026,SDM025 (SAA7146, IBMMPEG2): MPEG2 decoder only
-
 Powercolor
 ----------
    MTV878
diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options
index bbe3ed667d91..14c065fa23ef 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/MAKEDEV b/Documentation/video4linux/bttv/MAKEDEV
index 9d112f7fd5f7..093c0cd18042 100644
--- a/Documentation/video4linux/bttv/MAKEDEV
+++ b/Documentation/video4linux/bttv/MAKEDEV
@@ -19,7 +19,6 @@ function makedev () {
 echo "*** new device names ***"
 makedev video 0
 makedev radio 64
-makedev vtx 192
 makedev vbi 224
 
 #echo "*** old device names (for compatibility only) ***"
diff --git a/Documentation/video4linux/bttv/README b/Documentation/video4linux/bttv/README
index 3a367cdb664e..7cbf4fb6cf31 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 4259dccc8287..5eddfa076cfb 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 1e6328f91083..395f6c6fdd98 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 1247566c4de3..e0cdae491858 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/gspca.txt b/Documentation/video4linux/gspca.txt
index 56ba7bba7168..5bfa9a777d26 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -103,6 +103,7 @@ spca561		046d:092d	Logitech QC Elch2
 spca561         046d:092e       Logitech QC Elch2
 spca561         046d:092f       Logitech QuickCam Express Plus
 sunplus         046d:0960       Logitech ClickSmart 420
+nw80x           046d:d001       Logitech QuickCam Pro (dark focus ring)
 sunplus         0471:0322       Philips DMVC1300K
 zc3xx           0471:0325       Philips SPC 200 NC
 zc3xx           0471:0326       Philips SPC 300 NC
@@ -150,10 +151,12 @@ sunplus		04fc:5330	Digitrex 2110
 sunplus         04fc:5360       Sunplus Generic
 spca500         04fc:7333       PalmPixDC85
 sunplus         04fc:ffff       Pure DigitalDakota
+nw80x           0502:d001       DVC V6
 spca501         0506:00df       3Com HomeConnect Lite
 sunplus         052b:1507       Megapixel 5 Pretec DC-1007
 sunplus         052b:1513       Megapix V4
 sunplus         052b:1803       MegaImage VI
+nw80x           052b:d001       EZCam Pro p35u
 tv8532          0545:808b       Veo Stingray
 tv8532          0545:8333       Veo Stingray
 sunplus         0546:3155       Polaroid PDC3070
@@ -177,6 +180,7 @@ sunplus		055f:c530	Mustek Gsmart LCD 3
 sunplus         055f:c540       Gsmart D30
 sunplus         055f:c630       Mustek MDC4000
 sunplus         055f:c650       Mustek MDC5500Z
+nw80x           055f:d001       Mustek Wcam 300 mini
 zc3xx           055f:d003       Mustek WCam300A
 zc3xx           055f:d004       Mustek WCam300 AN
 conex           0572:0041       Creative Notebook cx11646
@@ -195,14 +199,20 @@ gl860		05e3:0503	Genesys Logic PC Camera
 gl860           05e3:f191       Genesys Logic PC Camera
 spca561         060b:a001       Maxell Compact Pc PM3
 zc3xx           0698:2003       CTX M730V built in
+nw80x           06a5:0000       Typhoon Webcam 100 USB
+nw80x           06a5:d001       Divio based webcams
+nw80x           06a5:d800       Divio Chicony TwinkleCam, Trust SpaceCam
 spca500         06bd:0404       Agfa CL20
 spca500         06be:0800       Optimedia
+nw80x           06be:d001       EZCam Pro p35u
 sunplus         06d6:0031       Trust 610 LCD PowerC@m Zoom
 spca506         06e1:a190       ADS Instant VCD
+ov534           06f8:3002       Hercules Blog Webcam
 ov534_9         06f8:3003       Hercules Dualpix HD Weblog
 sonixj          06f8:3004       Hercules Classic Silver
 sonixj          06f8:3008       Hercules Deluxe Optical Glass
 pac7302         06f8:3009       Hercules Classic Link
+nw80x           0728:d001       AVerMedia Camguard
 spca508         0733:0110       ViewQuest VQ110
 spca501         0733:0401       Intel Create and Share
 spca501         0733:0402       ViewQuest M318B
@@ -265,6 +275,7 @@ pac7302		093a:2629	Genious iSlim 300
 pac7302         093a:262a       Webcam 300k
 pac7302         093a:262c       Philips SPC 230 NC
 jeilinj         0979:0280       Sakar 57379
+jeilinj         0979:0280       Sportscam DV15
 zc3xx           0ac8:0302       Z-star Vimicro zc0302
 vc032x          0ac8:0321       Vimicro generic vc0321
 vc032x          0ac8:0323       Vimicro Vc0323
@@ -302,12 +313,14 @@ sonixj		0c45:60fb	Surfer NoName
 sonixj          0c45:60fc       LG-LIC300
 sonixj          0c45:60fe       Microdia Audio
 sonixj          0c45:6100       PC Camera (SN9C128)
+sonixj          0c45:6102       PC Camera (SN9C128)
 sonixj          0c45:610a       PC Camera (SN9C128)
 sonixj          0c45:610b       PC Camera (SN9C128)
 sonixj          0c45:610c       PC Camera (SN9C128)
 sonixj          0c45:610e       PC Camera (SN9C128)
 sonixj          0c45:6128       Microdia/Sonix SNP325
 sonixj          0c45:612a       Avant Camera
+sonixj          0c45:612b       Speed-Link REFLECT2
 sonixj          0c45:612c       Typhoon Rasy Cam 1.3MPix
 sonixj          0c45:6130       Sonix Pccam
 sonixj          0c45:6138       Sn9c120 Mo4000
@@ -364,6 +377,7 @@ t613		17a1:0128	TASCORP JPEG Webcam, NGS Cyclops
 vc032x          17ef:4802       Lenovo Vc0323+MI1310_SOC
 pac207          2001:f115       D-Link DSB-C120
 sq905c          2770:9050       Disney pix micro (CIF)
+sq905c          2770:9051       Lego Bionicle
 sq905c          2770:9052       Disney pix micro 2 (VGA)
 sq905c          2770:905c       All 11 known cameras with this ID
 sq905           2770:9120       All 24 known cameras with this ID
diff --git a/Documentation/video4linux/meye.txt b/Documentation/video4linux/meye.txt
index bf3af5fe558f..34e2842c70ae 100644
--- a/Documentation/video4linux/meye.txt
+++ b/Documentation/video4linux/meye.txt
@@ -45,8 +45,6 @@ module argument syntax (<param>=<value> when passing the option to the
 module or meye.<param>=<value> on the kernel boot line when meye is
 statically linked into the kernel). Those options are:
 
-        forcev4l1:      force use of V4L1 API instead of V4L2
-
         gbuffers:       number of capture buffers, default is 2 (32 max)
 
         gbufsize:       size of each capture buffer, default is 614400
@@ -79,9 +77,8 @@ Usage:
 Private API:
 ------------
 
-        The driver supports frame grabbing with the video4linux API
-        (either v4l1 or v4l2), so all video4linux tools (like xawtv)
-        should work with this driver.
+        The driver supports frame grabbing with the video4linux API,
+        so all video4linux tools (like xawtv) should work with this driver.
 
         Besides the video4linux interface, the driver has a private interface
         for accessing the Motion Eye extended parameters (camera sharpness,
@@ -123,7 +120,4 @@ Private API:
 Bugs / Todo:
 ------------
 
-        - the driver could be much cleaned up by removing the v4l1 support.
-          However, this means all v4l1-only applications will stop working.
-
         - 'motioneye' still uses the meye private v4l1 API extensions.
diff --git a/Documentation/video4linux/omap3isp.txt b/Documentation/video4linux/omap3isp.txt
new file mode 100644
index 000000000000..69be2c782b98
--- /dev/null
+++ b/Documentation/video4linux/omap3isp.txt
@@ -0,0 +1,278 @@
+OMAP 3 Image Signal Processor (ISP) driver
+
+Copyright (C) 2010 Nokia Corporation
+Copyright (C) 2009 Texas Instruments, Inc.
+
+Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+          Sakari Ailus <sakari.ailus@iki.fi>
+          David Cohen <dacohen@gmail.com>
+
+
+Introduction
+============
+
+This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP)
+driver located under drivers/media/video/omap3isp. The original driver was
+written by Texas Instruments but since that it has been rewritten (twice) at
+Nokia.
+
+The driver has been successfully used on the following versions of OMAP 3:
+
+        3430
+        3530
+        3630
+
+The driver implements V4L2, Media controller and v4l2_subdev interfaces.
+Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel
+are supported.
+
+
+Split to subdevs
+================
+
+The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP
+having one subdev to represent it. Each of the subdevs provide a V4L2 subdev
+interface to userspace.
+
+        OMAP3 ISP CCP2
+        OMAP3 ISP CSI2a
+        OMAP3 ISP CCDC
+        OMAP3 ISP preview
+        OMAP3 ISP resizer
+        OMAP3 ISP AEWB
+        OMAP3 ISP AF
+        OMAP3 ISP histogram
+
+Each possible link in the ISP is modelled by a link in the Media controller
+interface. For an example program see [2].
+
+
+Controlling the OMAP 3 ISP
+==========================
+
+In general, the settings given to the OMAP 3 ISP take effect at the beginning
+of the following frame. This is done when the module becomes idle during the
+vertical blanking period on the sensor. In memory-to-memory operation the pipe
+is run one frame at a time. Applying the settings is done between the frames.
+
+All the blocks in the ISP, excluding the CSI-2 and possibly the CCP2 receiver,
+insist on receiving complete frames. Sensors must thus never send the ISP
+partial frames.
+
+Autoidle does have issues with some ISP blocks on the 3430, at least.
+Autoidle is only enabled on 3630 when the omap3isp module parameter autoidle
+is non-zero.
+
+
+Events
+======
+
+The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and
+statistics (AEWB, AF and histogram) subdevs.
+
+The CCDC subdev produces V4L2_EVENT_OMAP3ISP_HS_VS type event on HS_VS
+interrupt which is used to signal frame start. The event is triggered exactly
+when the reception of the first line of the frame starts in the CCDC module.
+The event can be subscribed on the CCDC subdev.
+
+(When using parallel interface one must pay account to correct configuration
+of the VS signal polarity. This is automatically correct when using the serial
+receivers.)
+
+Each of the statistics subdevs is able to produce events. An event is
+generated whenever a statistics buffer can be dequeued by a user space
+application using the VIDIOC_OMAP3ISP_STAT_REQ IOCTL. The events available
+are:
+
+        V4L2_EVENT_OMAP3ISP_AEWB
+        V4L2_EVENT_OMAP3ISP_AF
+        V4L2_EVENT_OMAP3ISP_HIST
+
+The type of the event data is struct omap3isp_stat_event_status for these
+ioctls. If there is an error calculating the statistics, there will be an
+event as usual, but no related statistics buffer. In this case
+omap3isp_stat_event_status.buf_err is set to non-zero.
+
+
+Private IOCTLs
+==============
+
+The OMAP 3 ISP driver supports standard V4L2 IOCTLs and controls where
+possible and practical. Much of the functions provided by the ISP, however,
+does not fall under the standard IOCTLs --- gamma tables and configuration of
+statistics collection are examples of such.
+
+In general, there is a private ioctl for configuring each of the blocks
+containing hardware-dependent functions.
+
+The following private IOCTLs are supported:
+
+        VIDIOC_OMAP3ISP_CCDC_CFG
+        VIDIOC_OMAP3ISP_PRV_CFG
+        VIDIOC_OMAP3ISP_AEWB_CFG
+        VIDIOC_OMAP3ISP_HIST_CFG
+        VIDIOC_OMAP3ISP_AF_CFG
+        VIDIOC_OMAP3ISP_STAT_REQ
+        VIDIOC_OMAP3ISP_STAT_EN
+
+The parameter structures used by these ioctls are described in
+include/linux/omap3isp.h. The detailed functions of the ISP itself related to
+a given ISP block is described in the Technical Reference Manuals (TRMs) ---
+see the end of the document for those.
+
+While it is possible to use the ISP driver without any use of these private
+IOCTLs it is not possible to obtain optimal image quality this way. The AEWB,
+AF and histogram modules cannot be used without configuring them using the
+appropriate private IOCTLs.
+
+
+CCDC and preview block IOCTLs
+=============================
+
+The VIDIOC_OMAP3ISP_CCDC_CFG and VIDIOC_OMAP3ISP_PRV_CFG IOCTLs are used to
+configure, enable and disable functions in the CCDC and preview blocks,
+respectively. Both IOCTLs control several functions in the blocks they
+control. VIDIOC_OMAP3ISP_CCDC_CFG IOCTL accepts a pointer to struct
+omap3isp_ccdc_update_config as its argument. Similarly VIDIOC_OMAP3ISP_PRV_CFG
+accepts a pointer to struct omap3isp_prev_update_config. The definition of
+both structures is available in [1].
+
+The update field in the structures tells whether to update the configuration
+for the specific function and the flag tells whether to enable or disable the
+function.
+
+The update and flag bit masks accept the following values. Each separate
+functions in the CCDC and preview blocks is associated with a flag (either
+disable or enable; part of the flag field in the structure) and a pointer to
+configuration data for the function.
+
+Valid values for the update and flag fields are listed here for
+VIDIOC_OMAP3ISP_CCDC_CFG. Values may be or'ed to configure more than one
+function in the same IOCTL call.
+
+        OMAP3ISP_CCDC_ALAW
+        OMAP3ISP_CCDC_LPF
+        OMAP3ISP_CCDC_BLCLAMP
+        OMAP3ISP_CCDC_BCOMP
+        OMAP3ISP_CCDC_FPC
+        OMAP3ISP_CCDC_CULL
+        OMAP3ISP_CCDC_CONFIG_LSC
+        OMAP3ISP_CCDC_TBL_LSC
+
+The corresponding values for the VIDIOC_OMAP3ISP_PRV_CFG are here:
+
+        OMAP3ISP_PREV_LUMAENH
+        OMAP3ISP_PREV_INVALAW
+        OMAP3ISP_PREV_HRZ_MED
+        OMAP3ISP_PREV_CFA
+        OMAP3ISP_PREV_CHROMA_SUPP
+        OMAP3ISP_PREV_WB
+        OMAP3ISP_PREV_BLKADJ
+        OMAP3ISP_PREV_RGB2RGB
+        OMAP3ISP_PREV_COLOR_CONV
+        OMAP3ISP_PREV_YC_LIMIT
+        OMAP3ISP_PREV_DEFECT_COR
+        OMAP3ISP_PREV_GAMMABYPASS
+        OMAP3ISP_PREV_DRK_FRM_CAPTURE
+        OMAP3ISP_PREV_DRK_FRM_SUBTRACT
+        OMAP3ISP_PREV_LENS_SHADING
+        OMAP3ISP_PREV_NF
+        OMAP3ISP_PREV_GAMMA
+
+The associated configuration pointer for the function may not be NULL when
+enabling the function. When disabling a function the configuration pointer is
+ignored.
+
+
+Statistic blocks IOCTLs
+=======================
+
+The statistics subdevs do offer more dynamic configuration options than the
+other subdevs. They can be enabled, disable and reconfigured when the pipeline
+is in streaming state.
+
+The statistics blocks always get the input image data from the CCDC (as the
+histogram memory read isn't implemented). The statistics are dequeueable by
+the user from the statistics subdev nodes using private IOCTLs.
+
+The private IOCTLs offered by the AEWB, AF and histogram subdevs are heavily
+reflected by the register level interface offered by the ISP hardware. There
+are aspects that are purely related to the driver implementation and these are
+discussed next.
+
+VIDIOC_OMAP3ISP_STAT_EN
+-----------------------
+
+This private IOCTL enables/disables a statistic module. If this request is
+done before streaming, it will take effect as soon as the pipeline starts to
+stream.  If the pipeline is already streaming, it will take effect as soon as
+the CCDC becomes idle.
+
+VIDIOC_OMAP3ISP_AEWB_CFG, VIDIOC_OMAP3ISP_HIST_CFG and VIDIOC_OMAP3ISP_AF_CFG
+-----------------------------------------------------------------------------
+
+Those IOCTLs are used to configure the modules. They require user applications
+to have an in-depth knowledge of the hardware. Most of the fields explanation
+can be found on OMAP's TRMs. The two following fields common to all the above
+configure private IOCTLs require explanation for better understanding as they
+are not part of the TRM.
+
+omap3isp_[h3a_af/h3a_aewb/hist]_config.buf_size:
+
+The modules handle their buffers internally. The necessary buffer size for the
+module's data output depends on the requested configuration. Although the
+driver supports reconfiguration while streaming, it does not support a
+reconfiguration which requires bigger buffer size than what is already
+internally allocated if the module is enabled. It will return -EBUSY on this
+case. In order to avoid such condition, either disable/reconfigure/enable the
+module or request the necessary buffer size during the first configuration
+while the module is disabled.
+
+The internal buffer size allocation considers the requested configuration's
+minimum buffer size and the value set on buf_size field. If buf_size field is
+out of [minimum, maximum] buffer size range, it's clamped to fit in there.
+The driver then selects the biggest value. The corrected buf_size value is
+written back to user application.
+
+omap3isp_[h3a_af/h3a_aewb/hist]_config.config_counter:
+
+As the configuration doesn't take effect synchronously to the request, the
+driver must provide a way to track this information to provide more accurate
+data. After a configuration is requested, the config_counter returned to user
+space application will be an unique value associated to that request. When
+user application receives an event for buffer availability or when a new
+buffer is requested, this config_counter is used to match a buffer data and a
+configuration.
+
+VIDIOC_OMAP3ISP_STAT_REQ
+------------------------
+
+Send to user space the oldest data available in the internal buffer queue and
+discards such buffer afterwards. The field omap3isp_stat_data.frame_number
+matches with the video buffer's field_count.
+
+
+Technical reference manuals (TRMs) and other documentation
+==========================================================
+
+OMAP 3430 TRM:
+<URL:http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZM.zip>
+Referenced 2011-03-05.
+
+OMAP 35xx TRM:
+<URL:http://www.ti.com/litv/pdf/spruf98o> Referenced 2011-03-05.
+
+OMAP 3630 TRM:
+<URL:http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vQ.zip>
+Referenced 2011-03-05.
+
+DM 3730 TRM:
+<URL:http://www.ti.com/litv/pdf/sprugn4h> Referenced 2011-03-06.
+
+
+References
+==========
+
+[1] include/linux/omap3isp.h
+
+[2] http://git.ideasonboard.org/?p=media-ctl.git;a=summary
diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt
index 4f6d0ca01956..51ed1578b0e8 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 cb47e723af74..1e96ce6e2d2f 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 73de4050d637..b4f67040403a 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/uvcvideo.txt b/Documentation/video4linux/uvcvideo.txt
new file mode 100644
index 000000000000..848d620dcc5c
--- /dev/null
+++ b/Documentation/video4linux/uvcvideo.txt
@@ -0,0 +1,239 @@
+Linux USB Video Class (UVC) driver
+==================================
+
+This file documents some driver-specific aspects of the UVC driver, such as
+driver-specific ioctls and implementation notes.
+
+Questions and remarks can be sent to the Linux UVC development mailing list at
+linux-uvc-devel@lists.berlios.de.
+
+
+Extension Unit (XU) support
+---------------------------
+
+1. Introduction
+
+The UVC specification allows for vendor-specific extensions through extension
+units (XUs). The Linux UVC driver supports extension unit controls (XU controls)
+through two separate mechanisms:
+
+  - through mappings of XU controls to V4L2 controls
+  - through a driver-specific ioctl interface
+
+The first one allows generic V4L2 applications to use XU controls by mapping
+certain XU controls onto V4L2 controls, which then show up during ordinary
+control enumeration.
+
+The second mechanism requires uvcvideo-specific knowledge for the application to
+access XU controls but exposes the entire UVC XU concept to user space for
+maximum flexibility.
+
+Both mechanisms complement each other and are described in more detail below.
+
+
+2. Control mappings
+
+The UVC driver provides an API for user space applications to define so-called
+control mappings at runtime. These allow for individual XU controls or byte
+ranges thereof to be mapped to new V4L2 controls. Such controls appear and
+function exactly like normal V4L2 controls (i.e. the stock controls, such as
+brightness, contrast, etc.). However, reading or writing of such a V4L2 controls
+triggers a read or write of the associated XU control.
+
+The ioctl used to create these control mappings is called UVCIOC_CTRL_MAP.
+Previous driver versions (before 0.2.0) required another ioctl to be used
+beforehand (UVCIOC_CTRL_ADD) to pass XU control information to the UVC driver.
+This is no longer necessary as newer uvcvideo versions query the information
+directly from the device.
+
+For details on the UVCIOC_CTRL_MAP ioctl please refer to the section titled
+"IOCTL reference" below.
+
+
+3. Driver specific XU control interface
+
+For applications that need to access XU controls directly, e.g. for testing
+purposes, firmware upload, or accessing binary controls, a second mechanism to
+access XU controls is provided in the form of a driver-specific ioctl, namely
+UVCIOC_CTRL_QUERY.
+
+A call to this ioctl allows applications to send queries to the UVC driver that
+directly map to the low-level UVC control requests.
+
+In order to make such a request the UVC unit ID of the control's extension unit
+and the control selector need to be known. This information either needs to be
+hardcoded in the application or queried using other ways such as by parsing the
+UVC descriptor or, if available, using the media controller API to enumerate a
+device's entities.
+
+Unless the control size is already known it is necessary to first make a
+UVC_GET_LEN requests in order to be able to allocate a sufficiently large buffer
+and set the buffer size to the correct value. Similarly, to find out whether
+UVC_GET_CUR or UVC_SET_CUR are valid requests for a given control, a
+UVC_GET_INFO request should be made. The bits 0 (GET supported) and 1 (SET
+supported) of the resulting byte indicate which requests are valid.
+
+With the addition of the UVCIOC_CTRL_QUERY ioctl the UVCIOC_CTRL_GET and
+UVCIOC_CTRL_SET ioctls have become obsolete since their functionality is a
+subset of the former ioctl. For the time being they are still supported but
+application developers are encouraged to use UVCIOC_CTRL_QUERY instead.
+
+For details on the UVCIOC_CTRL_QUERY ioctl please refer to the section titled
+"IOCTL reference" below.
+
+
+4. Security
+
+The API doesn't currently provide a fine-grained access control facility. The
+UVCIOC_CTRL_ADD and UVCIOC_CTRL_MAP ioctls require super user permissions.
+
+Suggestions on how to improve this are welcome.
+
+
+5. Debugging
+
+In order to debug problems related to XU controls or controls in general it is
+recommended to enable the UVC_TRACE_CONTROL bit in the module parameter 'trace'.
+This causes extra output to be written into the system log.
+
+
+6. IOCTL reference
+
+---- UVCIOC_CTRL_MAP - Map a UVC control to a V4L2 control ----
+
+Argument: struct uvc_xu_control_mapping
+
+Description:
+        This ioctl creates a mapping between a UVC control or part of a UVC
+        control and a V4L2 control. Once mappings are defined, userspace
+        applications can access vendor-defined UVC control through the V4L2
+        control API.
+
+        To create a mapping, applications fill the uvc_xu_control_mapping
+        structure with information about an existing UVC control defined with
+        UVCIOC_CTRL_ADD and a new V4L2 control.
+
+        A UVC control can be mapped to several V4L2 controls. For instance,
+        a UVC pan/tilt control could be mapped to separate pan and tilt V4L2
+        controls. The UVC control is divided into non overlapping fields using
+        the 'size' and 'offset' fields and are then independantly mapped to
+        V4L2 control.
+
+        For signed integer V4L2 controls the data_type field should be set to
+        UVC_CTRL_DATA_TYPE_SIGNED. Other values are currently ignored.
+
+Return value:
+        On success 0 is returned. On error -1 is returned and errno is set
+        appropriately.
+
+        ENOMEM
+                Not enough memory to perform the operation.
+        EPERM
+                Insufficient privileges (super user privileges are required).
+        EINVAL
+                No such UVC control.
+        EOVERFLOW
+                The requested offset and size would overflow the UVC control.
+        EEXIST
+                Mapping already exists.
+
+Data types:
+        * struct uvc_xu_control_mapping
+
+        __u32   id              V4L2 control identifier
+        __u8    name[32]        V4L2 control name
+        __u8    entity[16]      UVC extension unit GUID
+        __u8    selector        UVC control selector
+        __u8    size            V4L2 control size (in bits)
+        __u8    offset          V4L2 control offset (in bits)
+        enum v4l2_ctrl_type
+                v4l2_type       V4L2 control type
+        enum uvc_control_data_type
+                data_type       UVC control data type
+        struct uvc_menu_info
+                *menu_info      Array of menu entries (for menu controls only)
+        __u32   menu_count      Number of menu entries (for menu controls only)
+
+        * struct uvc_menu_info
+
+        __u32   value           Menu entry value used by the device
+        __u8    name[32]        Menu entry name
+
+
+        * enum uvc_control_data_type
+
+        UVC_CTRL_DATA_TYPE_RAW          Raw control (byte array)
+        UVC_CTRL_DATA_TYPE_SIGNED       Signed integer
+        UVC_CTRL_DATA_TYPE_UNSIGNED     Unsigned integer
+        UVC_CTRL_DATA_TYPE_BOOLEAN      Boolean
+        UVC_CTRL_DATA_TYPE_ENUM         Enumeration
+        UVC_CTRL_DATA_TYPE_BITMASK      Bitmask
+
+
+---- UVCIOC_CTRL_QUERY - Query a UVC XU control ----
+
+Argument: struct uvc_xu_control_query
+
+Description:
+        This ioctl queries a UVC XU control identified by its extension unit ID
+        and control selector.
+
+        There are a number of different queries available that closely
+        correspond to the low-level control requests described in the UVC
+        specification. These requests are:
+
+        UVC_GET_CUR
+                Obtain the current value of the control.
+        UVC_GET_MIN
+                Obtain the minimum value of the control.
+        UVC_GET_MAX
+                Obtain the maximum value of the control.
+        UVC_GET_DEF
+                Obtain the default value of the control.
+        UVC_GET_RES
+                Query the resolution of the control, i.e. the step size of the
+                allowed control values.
+        UVC_GET_LEN
+                Query the size of the control in bytes.
+        UVC_GET_INFO
+                Query the control information bitmap, which indicates whether
+                get/set requests are supported.
+        UVC_SET_CUR
+                Update the value of the control.
+
+        Applications must set the 'size' field to the correct length for the
+        control. Exceptions are the UVC_GET_LEN and UVC_GET_INFO queries, for
+        which the size must be set to 2 and 1, respectively. The 'data' field
+        must point to a valid writable buffer big enough to hold the indicated
+        number of data bytes.
+
+        Data is copied directly from the device without any driver-side
+        processing. Applications are responsible for data buffer formatting,
+        including little-endian/big-endian conversion. This is particularly
+        important for the result of the UVC_GET_LEN requests, which is always
+        returned as a little-endian 16-bit integer by the device.
+
+Return value:
+        On success 0 is returned. On error -1 is returned and errno is set
+        appropriately.
+
+        ENOENT
+                The device does not support the given control or the specified
+                extension unit could not be found.
+        ENOBUFS
+                The specified buffer size is incorrect (too big or too small).
+        EINVAL
+                An invalid request code was passed.
+        EBADRQC
+                The given request is not supported by the given control.
+        EFAULT
+                The data pointer references an inaccessible memory area.
+
+Data types:
+        * struct uvc_xu_control_query
+
+        __u8    unit            Extension unit ID
+        __u8    selector        Control selector
+        __u8    query           Request code to send to the device
+        __u16   size            Control data size (in bytes)
+        __u8    *data           Control value
diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt
index 8773778d23fc..881e7f44491b 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -285,6 +285,9 @@ implement g_volatile_ctrl like this:
 The 'new value' union is not used in g_volatile_ctrl. In general controls
 that need to implement g_volatile_ctrl are read-only controls.
 
+Note that if one or more controls in a control cluster are marked as volatile,
+then all the controls in the cluster are seen as volatile.
+
 To mark a control as volatile you have to set the is_volatile flag:
 
         ctrl = v4l2_ctrl_new_std(&sd->ctrl_handler, ...);
@@ -462,6 +465,15 @@ pointer to the v4l2_ctrl_ops struct that is used for that cluster.
 Obviously, all controls in the cluster array must be initialized to either
 a valid control or to NULL.
 
+In rare cases you might want to know which controls of a cluster actually
+were set explicitly by the user. For this you can check the 'is_new' flag of
+each control. For example, in the case of a volume/mute cluster the 'is_new'
+flag of the mute control would be set if the user called VIDIOC_S_CTRL for
+mute only. If the user would call VIDIOC_S_EXT_CTRLS for both mute and volume
+controls, then the 'is_new' flag would be 1 for both controls.
+
+The 'is_new' flag is always 1 when called from v4l2_ctrl_handler_setup().
+
 
 VIDIOC_LOG_STATUS Support
 =========================
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index e831aaca66f8..cf21f7aae976 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -44,8 +44,8 @@ All drivers have the following structure:
 
 2) A way of initializing and commanding sub-devices (if any).
 
-3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX, /dev/radioX and
-   /dev/vtxX) and keeping track of device-node specific data.
+3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX and /dev/radioX)
+   and keeping track of device-node specific data.
 
 4) Filehandle-specific structs containing per-filehandle data;
 
@@ -71,6 +71,10 @@ sub-device instances, the video_device struct stores V4L2 device node data
 and in the future a v4l2_fh struct will keep track of filehandle instances
 (this is not yet implemented).
 
+The V4L2 framework also optionally integrates with the media framework. If a
+driver sets the struct v4l2_device mdev field, sub-devices and video nodes
+will automatically appear in the media framework as entities.
+
 
 struct v4l2_device
 ------------------
@@ -83,11 +87,20 @@ You must register the device instance:
 
         v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev);
 
-Registration will initialize the v4l2_device struct and link dev->driver_data
-to v4l2_dev. If v4l2_dev->name is empty then it will be set to a value derived
-from dev (driver name followed by the bus_id, to be precise). If you set it
-up before calling v4l2_device_register then it will be untouched. If dev is
-NULL, then you *must* setup v4l2_dev->name before calling v4l2_device_register.
+Registration will initialize the v4l2_device struct. If the dev->driver_data
+field is NULL, it will be linked to v4l2_dev.
+
+Drivers that want integration with the media device framework need to set
+dev->driver_data manually to point to the driver-specific device structure
+that embed the struct v4l2_device instance. This is achieved by a
+dev_set_drvdata() call before registering the V4L2 device instance. They must
+also set the struct v4l2_device mdev field to point to a properly initialized
+and registered media_device instance.
+
+If v4l2_dev->name is empty then it will be set to a value derived from dev
+(driver name followed by the bus_id, to be precise). If you set it up before
+calling v4l2_device_register then it will be untouched. If dev is NULL, then
+you *must* setup v4l2_dev->name before calling v4l2_device_register.
 
 You can use v4l2_device_set_name() to set the name based on a driver name and
 a driver-global atomic_t instance. This will generate names like ivtv0, ivtv1,
@@ -108,6 +121,7 @@ You unregister with:
 
         v4l2_device_unregister(struct v4l2_device *v4l2_dev);
 
+If the dev->driver_data field points to v4l2_dev, it will be reset to NULL.
 Unregistering will also automatically unregister all subdevs from the device.
 
 If you have a hotpluggable device (e.g. a USB device), then when a disconnect
@@ -167,6 +181,21 @@ static int __devinit drv_probe(struct pci_dev *pdev,
         state->instance = atomic_inc_return(&drv_instance) - 1;
 }
 
+If you have multiple device nodes then it can be difficult to know when it is
+safe to unregister v4l2_device. For this purpose v4l2_device has refcounting
+support. The refcount is increased whenever video_register_device is called and
+it is decreased whenever that device node is released. When the refcount reaches
+zero, then the v4l2_device release() callback is called. You can do your final
+cleanup there.
+
+If other device nodes (e.g. ALSA) are created, then you can increase and
+decrease the refcount manually as well by calling:
+
+void v4l2_device_get(struct v4l2_device *v4l2_dev);
+
+or:
+
+int v4l2_device_put(struct v4l2_device *v4l2_dev);
 
 struct v4l2_subdev
 ------------------
@@ -192,6 +221,11 @@ You also need a way to go from the low-level struct to v4l2_subdev. For the
 common i2c_client struct the i2c_set_clientdata() call is used to store a
 v4l2_subdev pointer, for other busses you may have to use other methods.
 
+Bridges might also need to store per-subdev private data, such as a pointer to
+bridge-specific per-subdev private data. The v4l2_subdev structure provides
+host private data for that purpose that can be accessed with
+v4l2_get_subdev_hostdata() and v4l2_set_subdev_hostdata().
+
 From the bridge driver perspective you load the sub-device module and somehow
 obtain the v4l2_subdev pointer. For i2c devices this is easy: you call
 i2c_get_clientdata(). For other busses something similar needs to be done.
@@ -249,6 +283,26 @@ A sub-device driver initializes the v4l2_subdev struct using:
 Afterwards you need to initialize subdev->name with a unique name and set the
 module owner. This is done for you if you use the i2c helper functions.
 
+If integration with the media framework is needed, you must initialize the
+media_entity struct embedded in the v4l2_subdev struct (entity field) by
+calling media_entity_init():
+
+        struct media_pad *pads = &my_sd->pads;
+        int err;
+
+        err = media_entity_init(&sd->entity, npads, pads, 0);
+
+The pads array must have been previously initialized. There is no need to
+manually set the struct media_entity type and name fields, but the revision
+field must be initialized if needed.
+
+A reference to the entity will be automatically acquired/released when the
+subdev device node (if any) is opened/closed.
+
+Don't forget to cleanup the media entity before the sub-device is destroyed:
+
+        media_entity_cleanup(&sd->entity);
+
 A device (bridge) driver needs to register the v4l2_subdev with the
 v4l2_device:
 
@@ -258,6 +312,9 @@ This can fail if the subdev module disappeared before it could be registered.
 After this function was called successfully the subdev->dev field points to
 the v4l2_device.
 
+If the v4l2_device parent device has a non-NULL mdev field, the sub-device
+entity will be automatically registered with the media device.
+
 You can unregister a sub-device using:
 
         v4l2_device_unregister_subdev(sd);
@@ -286,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
@@ -314,6 +371,61 @@ controlled through GPIO pins. This distinction is only relevant when setting
 up the device, but once the subdev is registered it is completely transparent.
 
 
+V4L2 sub-device userspace API
+-----------------------------
+
+Beside exposing a kernel API through the v4l2_subdev_ops structure, V4L2
+sub-devices can also be controlled directly by userspace applications.
+
+Device nodes named v4l-subdevX can be created in /dev to access sub-devices
+directly. If a sub-device supports direct userspace configuration it must set
+the V4L2_SUBDEV_FL_HAS_DEVNODE flag before being registered.
+
+After registering sub-devices, the v4l2_device driver can create device nodes
+for all registered sub-devices marked with V4L2_SUBDEV_FL_HAS_DEVNODE by calling
+v4l2_device_register_subdev_nodes(). Those device nodes will be automatically
+removed when sub-devices are unregistered.
+
+The device node handles a subset of the V4L2 API.
+
+VIDIOC_QUERYCTRL
+VIDIOC_QUERYMENU
+VIDIOC_G_CTRL
+VIDIOC_S_CTRL
+VIDIOC_G_EXT_CTRLS
+VIDIOC_S_EXT_CTRLS
+VIDIOC_TRY_EXT_CTRLS
+
+        The controls ioctls are identical to the ones defined in V4L2. They
+        behave identically, with the only exception that they deal only with
+        controls implemented in the sub-device. Depending on the driver, those
+        controls can be also be accessed through one (or several) V4L2 device
+        nodes.
+
+VIDIOC_DQEVENT
+VIDIOC_SUBSCRIBE_EVENT
+VIDIOC_UNSUBSCRIBE_EVENT
+
+        The events ioctls are identical to the ones defined in V4L2. They
+        behave identically, with the only exception that they deal only with
+        events generated by the sub-device. Depending on the driver, those
+        events can also be reported by one (or several) V4L2 device nodes.
+
+        Sub-device drivers that want to use events need to set the
+        V4L2_SUBDEV_USES_EVENTS v4l2_subdev::flags and initialize
+        v4l2_subdev::nevents to events queue depth before registering the
+        sub-device. After registration events can be queued as usual on the
+        v4l2_subdev::devnode device node.
+
+        To properly support events, the poll() file operation is also
+        implemented.
+
+Private ioctls
+
+        All ioctls not in the above list are passed directly to the sub-device
+        driver through the core::ioctl operation.
+
+
 I2C sub-device drivers
 ----------------------
 
@@ -448,6 +560,14 @@ You should also set these fields:
 - ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance
   (highly recommended to use this and it might become compulsory in the
   future!), then set this to your v4l2_ioctl_ops struct.
+- lock: leave to NULL if you want to do all the locking in the driver.
+  Otherwise you give it a pointer to a struct mutex_lock and before any
+  of the v4l2_file_operations is called this lock will be taken by the
+  core and released afterwards.
+- prio: keeps track of the priorities. Used to implement VIDIOC_G/S_PRIORITY.
+  If left to NULL, then it will use the struct v4l2_prio_state in v4l2_device.
+  If you want to have a separate priority state per (group of) device node(s),
+  then you can point it to your own struct v4l2_prio_state.
 - parent: you only set this if v4l2_device was registered with NULL as
   the parent device struct. This only happens in cases where one hardware
   device has multiple PCI devices that all share the same v4l2_device core.
@@ -457,13 +577,50 @@ You should also set these fields:
   (cx8802). Since the v4l2_device cannot be associated with a particular
   PCI device it is setup without a parent device. But when the struct
   video_device is setup you do know which parent PCI device to use.
+- flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework
+  handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct
+  v4l2_fh. Eventually this flag will disappear once all drivers use the core
+  priority handling. But for now it has to be set explicitly.
+
+If you use v4l2_ioctl_ops, then you should set .unlocked_ioctl to video_ioctl2
+in your v4l2_file_operations struct.
 
-If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or
-.ioctl to video_ioctl2 in your v4l2_file_operations struct.
+Do not use .ioctl! This is deprecated and will go away in the future.
 
 The v4l2_file_operations struct is a subset of file_operations. The main
 difference is that the inode argument is omitted since it is never used.
 
+If integration with the media framework is needed, you must initialize the
+media_entity struct embedded in the video_device struct (entity field) by
+calling media_entity_init():
+
+        struct media_pad *pad = &my_vdev->pad;
+        int err;
+
+        err = media_entity_init(&vdev->entity, 1, pad, 0);
+
+The pads array must have been previously initialized. There is no need to
+manually set the struct media_entity type and name fields.
+
+A reference to the entity will be automatically acquired/released when the
+video device is opened/closed.
+
+v4l2_file_operations and locking
+--------------------------------
+
+You can set a pointer to a mutex_lock in struct video_device. Usually this
+will be either a top-level mutex or a mutex per device node. If you want
+finer-grained locking then you have to set it to NULL and do you own locking.
+
+If a lock is specified then all file operations will be serialized on that
+lock. If you use videobuf then you must pass the same lock to the videobuf
+queue initialize function: if videobuf has to wait for a frame to arrive, then
+it will temporarily unlock the lock and relock it afterwards. If your driver
+also waits in the code, then you should do the same to allow other processes
+to access the device node while the first process is waiting for something.
+
+The implementation of a hotplug disconnect should also take the lock before
+calling v4l2_device_disconnect.
 
 video_device registration
 -------------------------
@@ -477,13 +634,15 @@ for you.
                 return err;
         }
 
+If the v4l2_device parent device has a non-NULL mdev field, the video device
+entity will be automatically registered with the media device.
+
 Which device is registered depends on the type argument. The following
 types exist:
 
 VFL_TYPE_GRABBER: videoX for video input/output devices
 VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext)
 VFL_TYPE_RADIO: radioX for radio tuners
-VFL_TYPE_VTX: vtxX for teletext devices (deprecated, don't use)
 
 The last argument gives you a certain amount of control over the device
 device node number used (i.e. the X in videoX). Normally you will pass -1
@@ -547,13 +706,19 @@ from /dev).
 
 After video_unregister_device() returns no new opens can be done. However,
 in the case of USB devices some application might still have one of these
-device nodes open. So after the unregister all file operations will return
-an error as well, except for the ioctl and unlocked_ioctl file operations:
-those will still be passed on since some buffer ioctls may still be needed.
+device nodes open. So after the unregister all file operations (except
+release, of course) will return an error as well.
 
 When the last user of the video device node exits, then the vdev->release()
 callback is called and you can do the final cleanup there.
 
+Don't forget to cleanup the media entity associated with the video device if
+it has been initialized:
+
+        media_entity_cleanup(&vdev->entity);
+
+This can be done from the release callback.
+
 
 video_device helper functions
 -----------------------------
@@ -613,39 +778,25 @@ struct v4l2_fh
 --------------
 
 struct v4l2_fh provides a way to easily keep file handle specific data
-that is used by the V4L2 framework. Using v4l2_fh is optional for
-drivers.
+that is used by the V4L2 framework. New drivers must use struct v4l2_fh
+since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY)
+if the video_device flag V4L2_FL_USE_FH_PRIO is also set.
 
 The users of v4l2_fh (in the V4L2 framework, not the driver) know
 whether a driver uses v4l2_fh as its file->private_data pointer by
-testing the V4L2_FL_USES_V4L2_FH bit in video_device->flags.
-
-Useful functions:
-
-- v4l2_fh_init()
-
-  Initialise the file handle. This *MUST* be performed in the driver's
-  v4l2_file_operations->open() handler.
-
-- v4l2_fh_add()
-
-  Add a v4l2_fh to video_device file handle list. May be called after
-  initialising the file handle.
-
-- v4l2_fh_del()
-
-  Unassociate the file handle from video_device(). The file handle
-  exit function may now be called.
+testing the V4L2_FL_USES_V4L2_FH bit in video_device->flags. This bit is
+set whenever v4l2_fh_init() is called.
 
-- v4l2_fh_exit()
+struct v4l2_fh is allocated as a part of the driver's own file handle
+structure and file->private_data is set to it in the driver's open
+function by the driver.
 
-  Uninitialise the file handle. After uninitialisation the v4l2_fh
-  memory can be freed.
+In many cases the struct v4l2_fh will be embedded in a larger structure.
+In that case you should call v4l2_fh_init+v4l2_fh_add in open() and
+v4l2_fh_del+v4l2_fh_exit in release().
 
-struct v4l2_fh is allocated as a part of the driver's own file handle
-structure and is set to file->private_data in the driver's open
-function by the driver. Drivers can extract their own file handle
-structure by using the container_of macro. Example:
+Drivers can extract their own file handle structure by using the container_of
+macro. Example:
 
 struct my_fh {
         int blah;
@@ -662,15 +813,21 @@ int my_open(struct file *file)
 
         ...
 
+        my_fh = kzalloc(sizeof(*my_fh), GFP_KERNEL);
+
+        ...
+
         ret = v4l2_fh_init(&my_fh->fh, vfd);
-        if (ret)
+        if (ret) {
+                kfree(my_fh);
                 return ret;
+        }
 
-        v4l2_fh_add(&my_fh->fh);
+        ...
 
         file->private_data = &my_fh->fh;
-
-        ...
+        v4l2_fh_add(&my_fh->fh);
+        return 0;
 }
 
 int my_release(struct file *file)
@@ -679,8 +836,65 @@ int my_release(struct file *file)
         struct my_fh *my_fh = container_of(fh, struct my_fh, fh);
 
         ...
+        v4l2_fh_del(&my_fh->fh);
+        v4l2_fh_exit(&my_fh->fh);
+        kfree(my_fh);
+        return 0;
 }
 
+Below is a short description of the v4l2_fh functions used:
+
+int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
+
+  Initialise the file handle. This *MUST* be performed in the driver's
+  v4l2_file_operations->open() handler.
+
+void v4l2_fh_add(struct v4l2_fh *fh)
+
+  Add a v4l2_fh to video_device file handle list. Must be called once the
+  file handle is completely initialized.
+
+void v4l2_fh_del(struct v4l2_fh *fh)
+
+  Unassociate the file handle from video_device(). The file handle
+  exit function may now be called.
+
+void v4l2_fh_exit(struct v4l2_fh *fh)
+
+  Uninitialise the file handle. After uninitialisation the v4l2_fh
+  memory can be freed.
+
+
+If struct v4l2_fh is not embedded, then you can use these helper functions:
+
+int v4l2_fh_open(struct file *filp)
+
+  This allocates a struct v4l2_fh, initializes it and adds it to the struct
+  video_device associated with the file struct.
+
+int v4l2_fh_release(struct file *filp)
+
+  This deletes it from the struct video_device associated with the file
+  struct, uninitialised the v4l2_fh and frees it.
+
+These two functions can be plugged into the v4l2_file_operation's open() and
+release() ops.
+
+
+Several drivers need to do something when the first file handle is opened and
+when the last file handle closes. Two helper functions were added to check
+whether the v4l2_fh struct is the only open filehandle of the associated
+device node:
+
+int v4l2_fh_is_singular(struct v4l2_fh *fh)
+
+  Returns 1 if the file handle is the only open file handle, else 0.
+
+int v4l2_fh_is_singular_file(struct file *filp)
+
+  Same, but it calls v4l2_fh_is_singular with filp->private_data.
+
+
 V4L2 events
 -----------
 
diff --git a/Documentation/video4linux/v4lgrab.c b/Documentation/video4linux/v4lgrab.c
deleted file mode 100644
index c8ded175796e..000000000000
--- a/Documentation/video4linux/v4lgrab.c
+++ /dev/null
@@ -1,201 +0,0 @@
-/* Simple Video4Linux image grabber. */
-/*
- *      Video4Linux Driver Test/Example Framegrabbing Program
- *
- *      Compile with:
- *              gcc -s -Wall -Wstrict-prototypes v4lgrab.c -o v4lgrab
- *      Use as:
- *              v4lgrab >image.ppm
- *
- *      Copyright (C) 1998-05-03, Phil Blundell <philb@gnu.org>
- *      Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c
- *      with minor modifications (Dave Forrest, drf5n@virginia.edu).
- *
- *
- *      For some cameras you may need to pre-load libv4l to perform
- *      the necessary decompression, e.g.:
- *
- *      export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
- *      ./v4lgrab >image.ppm
- *
- *      see http://hansdegoede.livejournal.com/3636.html for details.
- *
- */
-
-#include <unistd.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <sys/ioctl.h>
-#include <stdlib.h>
-
-#include <linux/types.h>
-#include <linux/videodev.h>
-
-#define VIDEO_DEV "/dev/video0"
-
-/* Stole this from tvset.c */
-
-#define READ_VIDEO_PIXEL(buf, format, depth, r, g, b)                   \
-{                                                                       \
-        switch (format)                                                 \
-        {                                                               \
-                case VIDEO_PALETTE_GREY:                                \
-                        switch (depth)                                  \
-                        {                                               \
-                                case 4:                                 \
-                                case 6:                                 \
-                                case 8:                                 \
-                                        (r) = (g) = (b) = (*buf++ << 8);\
-                                        break;                          \
-                                                                        \
-                                case 16:                                \
-                                        (r) = (g) = (b) =               \
-                                                *((unsigned short *) buf);      \
-                                        buf += 2;                       \
-                                        break;                          \
-                        }                                               \
-                        break;                                          \
-                                                                        \
-                                                                        \
-                case VIDEO_PALETTE_RGB565:                              \
-                {                                                       \
-                        unsigned short tmp = *(unsigned short *)buf;    \
-                        (r) = tmp&0xF800;                               \
-                        (g) = (tmp<<5)&0xFC00;                          \
-                        (b) = (tmp<<11)&0xF800;                         \
-                        buf += 2;                                       \
-                }                                                       \
-                break;                                                  \
-                                                                        \
-                case VIDEO_PALETTE_RGB555:                              \
-                        (r) = (buf[0]&0xF8)<<8;                         \
-                        (g) = ((buf[0] << 5 | buf[1] >> 3)&0xF8)<<8;    \
-                        (b) = ((buf[1] << 2 ) & 0xF8)<<8;               \
-                        buf += 2;                                       \
-                        break;                                          \
-                                                                        \
-                case VIDEO_PALETTE_RGB24:                               \
-                        (r) = buf[0] << 8; (g) = buf[1] << 8;           \
-                        (b) = buf[2] << 8;                              \
-                        buf += 3;                                       \
-                        break;                                          \
-                                                                        \
-                default:                                                \
-                        fprintf(stderr,                                 \
-                                "Format %d not yet supported\n",        \
-                                format);                                \
-        }                                                               \
-}
-
-static int get_brightness_adj(unsigned char *image, long size, int *brightness) {
-  long i, tot = 0;
-  for (i=0;i<size*3;i++)
-    tot += image[i];
-  *brightness = (128 - tot/(size*3))/3;
-  return !((tot/(size*3)) >= 126 && (tot/(size*3)) <= 130);
-}
-
-int main(int argc, char ** argv)
-{
-  int fd = open(VIDEO_DEV, O_RDONLY), f;
-  struct video_capability cap;
-  struct video_window win;
-  struct video_picture vpic;
-
-  unsigned char *buffer, *src;
-  int bpp = 24, r = 0, g = 0, b = 0;
-  unsigned int i, src_depth = 16;
-
-  if (fd < 0) {
-    perror(VIDEO_DEV);
-    exit(1);
-  }
-
-  if (ioctl(fd, VIDIOCGCAP, &cap) < 0) {
-    perror("VIDIOGCAP");
-    fprintf(stderr, "(" VIDEO_DEV " not a video4linux device?)\n");
-    close(fd);
-    exit(1);
-  }
-
-  if (ioctl(fd, VIDIOCGWIN, &win) < 0) {
-    perror("VIDIOCGWIN");
-    close(fd);
-    exit(1);
-  }
-
-  if (ioctl(fd, VIDIOCGPICT, &vpic) < 0) {
-    perror("VIDIOCGPICT");
-    close(fd);
-    exit(1);
-  }
-
-  if (cap.type & VID_TYPE_MONOCHROME) {
-    vpic.depth=8;
-    vpic.palette=VIDEO_PALETTE_GREY;    /* 8bit grey */
-    if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) {
-      vpic.depth=6;
-      if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) {
-        vpic.depth=4;
-        if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) {
-          fprintf(stderr, "Unable to find a supported capture format.\n");
-          close(fd);
-          exit(1);
-        }
-      }
-    }
-  } else {
-    vpic.depth=24;
-    vpic.palette=VIDEO_PALETTE_RGB24;
-
-    if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) {
-      vpic.palette=VIDEO_PALETTE_RGB565;
-      vpic.depth=16;
-
-      if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) {
-        vpic.palette=VIDEO_PALETTE_RGB555;
-        vpic.depth=15;
-
-        if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) {
-          fprintf(stderr, "Unable to find a supported capture format.\n");
-          return -1;
-        }
-      }
-    }
-  }
-
-  buffer = malloc(win.width * win.height * bpp);
-  if (!buffer) {
-    fprintf(stderr, "Out of memory.\n");
-    exit(1);
-  }
-
-  do {
-    int newbright;
-    read(fd, buffer, win.width * win.height * bpp);
-    f = get_brightness_adj(buffer, win.width * win.height, &newbright);
-    if (f) {
-      vpic.brightness += (newbright << 8);
-      if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) {
-        perror("VIDIOSPICT");
-        break;
-      }
-    }
-  } while (f);
-
-  fprintf(stdout, "P6\n%d %d 255\n", win.width, win.height);
-
-  src = buffer;
-
-  for (i = 0; i < win.width * win.height; i++) {
-    READ_VIDEO_PIXEL(src, vpic.palette, src_depth, r, g, b);
-    fputc(r>>8, stdout);
-    fputc(g>>8, stdout);
-    fputc(b>>8, stdout);
-  }
-
-  close(fd);
-  return 0;
-}
diff --git a/Documentation/video4linux/videobuf b/Documentation/video4linux/videobuf
index 17a1f9abf260..1d00d7f15b8f 100644
--- a/Documentation/video4linux/videobuf
+++ b/Documentation/video4linux/videobuf
@@ -247,8 +247,6 @@ calls.  The relevant helper functions are:
                        int nonblocking);
     int videobuf_streamon(struct videobuf_queue *q);
     int videobuf_streamoff(struct videobuf_queue *q);
-    int videobuf_cgmbuf(struct videobuf_queue *q, struct video_mbuf *mbuf,
-                        int count);
 
 So, for example, a VIDIOC_REQBUFS call turns into a call to the driver's
 vidioc_reqbufs() callback which, in turn, usually only needs to locate the
@@ -258,10 +256,7 @@ boilerplate in a lot of V4L2 drivers.
 
 The vidioc_streamon() and vidioc_streamoff() functions will be a bit more
 complex, of course, since they will also need to deal with starting and
-stopping the capture engine.  videobuf_cgmbuf(), called from the driver's
-vidiocgmbuf() function, only exists if the V4L1 compatibility module has
-been selected with CONFIG_VIDEO_V4L1_COMPAT, so its use must be surrounded
-with #ifdef directives.
+stopping the capture engine.
 
 Buffer allocation
 
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt
index 05138e8aea07..9649450f3b90 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 befdfdacdc5b..b41c83cf09f4 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