14 files changed, 439 insertions, 103 deletions

diff --git a/Documentation/ABI/testing/sysfs-class-regulator b/Documentation/ABI/testing/sysfs-class-regulator
index 79a4a75b2d2c..3731f6f29bcb 100644
--- a/Documentation/ABI/testing/sysfs-class-regulator
+++ b/Documentation/ABI/testing/sysfs-class-regulator
@@ -1,7 +1,7 @@
 What:           /sys/class/regulator/.../state
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 state. This holds the regulator output state.
@@ -27,7 +27,7 @@ Description:
 What:           /sys/class/regulator/.../type
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 type. This holds the regulator type.
@@ -51,7 +51,7 @@ Description:
 What:           /sys/class/regulator/.../microvolts
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 microvolts. This holds the regulator output voltage setting
@@ -65,7 +65,7 @@ Description:
 What:           /sys/class/regulator/.../microamps
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 microamps. This holds the regulator output current limit
@@ -79,7 +79,7 @@ Description:
 What:           /sys/class/regulator/.../opmode
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 opmode. This holds the regulator operating mode setting.
@@ -102,7 +102,7 @@ Description:
 What:           /sys/class/regulator/.../min_microvolts
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 min_microvolts. This holds the minimum safe working regulator
@@ -116,7 +116,7 @@ Description:
 What:           /sys/class/regulator/.../max_microvolts
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 max_microvolts. This holds the maximum safe working regulator
@@ -130,7 +130,7 @@ Description:
 What:           /sys/class/regulator/.../min_microamps
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 min_microamps. This holds the minimum safe working regulator
@@ -145,7 +145,7 @@ Description:
 What:           /sys/class/regulator/.../max_microamps
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 max_microamps. This holds the maximum safe working regulator
@@ -157,10 +157,23 @@ Description:
                 platform code.
 
 
+What:           /sys/class/regulator/.../name
+Date:           October 2008
+KernelVersion:  2.6.28
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
+Description:
+                Each regulator directory will contain a field called
+                name. This holds a string identifying the regulator for
+                display purposes.
+
+                NOTE: this will be empty if no suitable name is provided
+                by platform or regulator drivers.
+
+
 What:           /sys/class/regulator/.../num_users
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 num_users. This holds the number of consumer devices that
@@ -170,7 +183,7 @@ Description:
 What:           /sys/class/regulator/.../requested_microamps
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 requested_microamps. This holds the total requested load
@@ -181,7 +194,7 @@ Description:
 What:           /sys/class/regulator/.../parent
 Date:           April 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Some regulator directories will contain a link called parent.
                 This points to the parent or supply regulator if one exists.
@@ -189,7 +202,7 @@ Description:
 What:           /sys/class/regulator/.../suspend_mem_microvolts
 Date:           May 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 suspend_mem_microvolts. This holds the regulator output
@@ -203,7 +216,7 @@ Description:
 What:           /sys/class/regulator/.../suspend_disk_microvolts
 Date:           May 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 suspend_disk_microvolts. This holds the regulator output
@@ -217,7 +230,7 @@ Description:
 What:           /sys/class/regulator/.../suspend_standby_microvolts
 Date:           May 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 suspend_standby_microvolts. This holds the regulator output
@@ -231,7 +244,7 @@ Description:
 What:           /sys/class/regulator/.../suspend_mem_mode
 Date:           May 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 suspend_mem_mode. This holds the regulator operating mode
@@ -245,7 +258,7 @@ Description:
 What:           /sys/class/regulator/.../suspend_disk_mode
 Date:           May 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 suspend_disk_mode. This holds the regulator operating mode
@@ -258,7 +271,7 @@ Description:
 What:           /sys/class/regulator/.../suspend_standby_mode
 Date:           May 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 suspend_standby_mode. This holds the regulator operating mode
@@ -272,7 +285,7 @@ Description:
 What:           /sys/class/regulator/.../suspend_mem_state
 Date:           May 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 suspend_mem_state. This holds the regulator operating state
@@ -287,7 +300,7 @@ Description:
 What:           /sys/class/regulator/.../suspend_disk_state
 Date:           May 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 suspend_disk_state. This holds the regulator operating state
@@ -302,7 +315,7 @@ Description:
 What:           /sys/class/regulator/.../suspend_standby_state
 Date:           May 2008
 KernelVersion:  2.6.26
-Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Contact:        Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
                 Each regulator directory will contain a field called
                 suspend_standby_state. This holds the regulator operating
diff --git a/Documentation/laptops/disk-shock-protection.txt b/Documentation/laptops/disk-shock-protection.txt
new file mode 100644
index 000000000000..0e6ba2663834
--- /dev/null
+++ b/Documentation/laptops/disk-shock-protection.txt
@@ -0,0 +1,149 @@
+Hard disk shock protection
+==========================
+
+Author: Elias Oltmanns <eo@nebensachen.de>
+Last modified: 2008-10-03
+
+
+0. Contents
+-----------
+
+1. Intro
+2. The interface
+3. References
+4. CREDITS
+
+
+1. Intro
+--------
+
+ATA/ATAPI-7 specifies the IDLE IMMEDIATE command with unload feature.
+Issuing this command should cause the drive to switch to idle mode and
+unload disk heads. This feature is being used in modern laptops in
+conjunction with accelerometers and appropriate software to implement
+a shock protection facility. The idea is to stop all I/O operations on
+the internal hard drive and park its heads on the ramp when critical
+situations are anticipated. The desire to have such a feature
+available on GNU/Linux systems has been the original motivation to
+implement a generic disk head parking interface in the Linux kernel.
+Please note, however, that other components have to be set up on your
+system in order to get disk shock protection working (see
+section 3. References below for pointers to more information about
+that).
+
+
+2. The interface
+----------------
+
+For each ATA device, the kernel exports the file
+block/*/device/unload_heads in sysfs (here assumed to be mounted under
+/sys). Access to /sys/block/*/device/unload_heads is denied with
+-EOPNOTSUPP if the device does not support the unload feature.
+Otherwise, writing an integer value to this file will take the heads
+of the respective drive off the platter and block all I/O operations
+for the specified number of milliseconds. When the timeout expires and
+no further disk head park request has been issued in the meantime,
+normal operation will be resumed. The maximal value accepted for a
+timeout is 30000 milliseconds. Exceeding this limit will return
+-EOVERFLOW, but heads will be parked anyway and the timeout will be
+set to 30 seconds. However, you can always change a timeout to any
+value between 0 and 30000 by issuing a subsequent head park request
+before the timeout of the previous one has expired. In particular, the
+total timeout can exceed 30 seconds and, more importantly, you can
+cancel a previously set timeout and resume normal operation
+immediately by specifying a timeout of 0. Values below -2 are rejected
+with -EINVAL (see below for the special meaning of -1 and -2). If the
+timeout specified for a recent head park request has not yet expired,
+reading from /sys/block/*/device/unload_heads will report the number
+of milliseconds remaining until normal operation will be resumed;
+otherwise, reading the unload_heads attribute will return 0.
+
+For example, do the following in order to park the heads of drive
+/dev/sda and stop all I/O operations for five seconds:
+
+# echo 5000 > /sys/block/sda/device/unload_heads
+
+A simple
+
+# cat /sys/block/sda/device/unload_heads
+
+will show you how many milliseconds are left before normal operation
+will be resumed.
+
+A word of caution: The fact that the interface operates on a basis of
+milliseconds may raise expectations that cannot be satisfied in
+reality. In fact, the ATA specs clearly state that the time for an
+unload operation to complete is vendor specific. The hint in ATA-7
+that this will typically be within 500 milliseconds apparently has
+been dropped in ATA-8.
+
+There is a technical detail of this implementation that may cause some
+confusion and should be discussed here. When a head park request has
+been issued to a device successfully, all I/O operations on the
+controller port this device is attached to will be deferred. That is
+to say, any other device that may be connected to the same port will
+be affected too. The only exception is that a subsequent head unload
+request to that other device will be executed immediately. Further
+operations on that port will be deferred until the timeout specified
+for either device on the port has expired. As far as PATA (old style
+IDE) configurations are concerned, there can only be two devices
+attached to any single port. In SATA world we have port multipliers
+which means that a user-issued head parking request to one device may
+actually result in stopping I/O to a whole bunch of devices. However,
+since this feature is supposed to be used on laptops and does not seem
+to be very useful in any other environment, there will be mostly one
+device per port. Even if the CD/DVD writer happens to be connected to
+the same port as the hard drive, it generally *should* recover just
+fine from the occasional buffer under-run incurred by a head park
+request to the HD. Actually, when you are using an ide driver rather
+than its libata counterpart (i.e. your disk is called /dev/hda
+instead of /dev/sda), then parking the heads of one drive (drive X)
+will generally not affect the mode of operation of another drive
+(drive Y) on the same port as described above. It is only when a port
+reset is required to recover from an exception on drive Y that further
+I/O operations on that drive (and the reset itself) will be delayed
+until drive X is no longer in the parked state.
+
+Finally, there are some hard drives that only comply with an earlier
+version of the ATA standard than ATA-7, but do support the unload
+feature nonetheless. Unfortunately, there is no safe way Linux can
+detect these devices, so you won't be able to write to the
+unload_heads attribute. If you know that your device really does
+support the unload feature (for instance, because the vendor of your
+laptop or the hard drive itself told you so), then you can tell the
+kernel to enable the usage of this feature for that drive by writing
+the special value -1 to the unload_heads attribute:
+
+# echo -1 > /sys/block/sda/device/unload_heads
+
+will enable the feature for /dev/sda, and giving -2 instead of -1 will
+disable it again.
+
+
+3. References
+-------------
+
+There are several laptops from different vendors featuring shock
+protection capabilities. As manufacturers have refused to support open
+source development of the required software components so far, Linux
+support for shock protection varies considerably between different
+hardware implementations. Ideally, this section should contain a list
+of pointers at different projects aiming at an implementation of shock
+protection on different systems. Unfortunately, I only know of a
+single project which, although still considered experimental, is fit
+for use. Please feel free to add projects that have been the victims
+of my ignorance.
+
+- http://www.thinkwiki.org/wiki/HDAPS
+  See this page for information about Linux support of the hard disk
+  active protection system as implemented in IBM/Lenovo Thinkpads.
+
+
+4. CREDITS
+----------
+
+This implementation of disk head parking has been inspired by a patch
+originally published by Jon Escombe <lists@dresco.co.uk>. My efforts
+to develop an implementation of this feature that is fit to be merged
+into mainline have been aided by various kernel developers, in
+particular by Tejun Heo and Bartlomiej Zolnierkiewicz.
diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt
index 96f155e68750..059934363caf 100644
--- a/Documentation/pcmcia/driver-changes.txt
+++ b/Documentation/pcmcia/driver-changes.txt
@@ -1,5 +1,11 @@
 This file details changes in 2.6 which affect PCMCIA card driver authors:
 
+* New configuration loop helper (as of 2.6.28)
+   By calling pcmcia_loop_config(), a driver can iterate over all available
+   configuration options. During a driver's probe() phase, one doesn't need
+   to use pcmcia_get_{first,next}_tuple, pcmcia_get_tuple_data and
+   pcmcia_parse_tuple directly in most if not all cases.
+
 * New release helper (as of 2.6.17)
    Instead of calling pcmcia_release_{configuration,io,irq,win}, all that's
    necessary now is calling pcmcia_disable_device. As there is no valid
diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt
index c9a35665cf70..ce3487d99abe 100644
--- a/Documentation/power/regulator/machine.txt
+++ b/Documentation/power/regulator/machine.txt
@@ -2,17 +2,8 @@ Regulator Machine Driver Interface
 ===================================
 
 The regulator machine driver interface is intended for board/machine specific
-initialisation code to configure the regulator subsystem. Typical things that
-machine drivers would do are :-
+initialisation code to configure the regulator subsystem.
 
- 1. Regulator -> Device mapping.
- 2. Regulator supply configuration.
- 3. Power Domain constraint setting.
-
-
-
-1. Regulator -> device mapping
-==============================
 Consider the following machine :-
 
   Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
@@ -21,81 +12,82 @@ Consider the following machine :-
 
 The drivers for consumers A & B must be mapped to the correct regulator in
 order to control their power supply. This mapping can be achieved in machine
-initialisation code by calling :-
+initialisation code by creating a struct regulator_consumer_supply for
+each regulator.
+
+struct regulator_consumer_supply {
+        struct device *dev;     /* consumer */
+        const char *supply;     /* consumer supply - e.g. "vcc" */
+};
 
-int regulator_set_device_supply(const char *regulator, struct device *dev,
-                                const char *supply);
+e.g. for the machine above
 
-and is shown with the following code :-
+static struct regulator_consumer_supply regulator1_consumers[] = {
+{
+        .dev    = &platform_consumerB_device.dev,
+        .supply = "Vcc",
+},};
 
-regulator_set_device_supply("Regulator-1", devB, "Vcc");
-regulator_set_device_supply("Regulator-2", devA, "Vcc");
+static struct regulator_consumer_supply regulator2_consumers[] = {
+{
+        .dev    = &platform_consumerA_device.dev,
+        .supply = "Vcc",
+},};
 
 This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2
 to the 'Vcc' supply for Consumer A.
 
-
-2. Regulator supply configuration.
-==================================
-Consider the following machine (again) :-
-
-  Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
-               |
-               +-> [Consumer B @ 3.3V]
+Constraints can now be registered by defining a struct regulator_init_data
+for each regulator power domain. This structure also maps the consumers
+to their supply regulator :-
+
+static struct regulator_init_data regulator1_data = {
+        .constraints = {
+                .min_uV = 3300000,
+                .max_uV = 3300000,
+                .valid_modes_mask = REGULATOR_MODE_NORMAL,
+        },
+        .num_consumer_supplies = ARRAY_SIZE(regulator1_consumers),
+        .consumer_supplies = regulator1_consumers,
+};
 
 Regulator-1 supplies power to Regulator-2. This relationship must be registered
 with the core so that Regulator-1 is also enabled when Consumer A enables it's
-supply (Regulator-2).
-
-This relationship can be register with the core via :-
-
-int regulator_set_supply(const char *regulator, const char *regulator_supply);
-
-In this example we would use the following code :-
-
-regulator_set_supply("Regulator-2", "Regulator-1");
-
-Relationships can be queried by calling :-
-
-const char *regulator_get_supply(const char *regulator);
-
-
-3. Power Domain constraint setting.
-===================================
-Each power domain within a system has physical constraints on voltage and
-current. This must be defined in software so that the power domain is always
-operated within specifications.
-
-Consider the following machine (again) :-
-
-  Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
-               |
-               +-> [Consumer B @ 3.3V]
-
-This gives us two regulators and two power domains:
-
-                   Domain 1: Regulator-2, Consumer B.
-                   Domain 2: Consumer A.
-
-Constraints can be registered by calling :-
-
-int regulator_set_platform_constraints(const char *regulator,
-        struct regulation_constraints *constraints);
-
-The example is defined as follows :-
-
-struct regulation_constraints domain_1 = {
-        .min_uV = 3300000,
-        .max_uV = 3300000,
-        .valid_modes_mask = REGULATOR_MODE_NORMAL,
+supply (Regulator-2). The supply regulator is set by the supply_regulator_dev
+field below:-
+
+static struct regulator_init_data regulator2_data = {
+        .supply_regulator_dev = &platform_regulator1_device.dev,
+        .constraints = {
+                .min_uV = 1800000,
+                .max_uV = 2000000,
+                .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+                .valid_modes_mask = REGULATOR_MODE_NORMAL,
+        },
+        .num_consumer_supplies = ARRAY_SIZE(regulator2_consumers),
+        .consumer_supplies = regulator2_consumers,
 };
 
-struct regulation_constraints domain_2 = {
-        .min_uV = 1800000,
-        .max_uV = 2000000,
-        .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
-        .valid_modes_mask = REGULATOR_MODE_NORMAL,
+Finally the regulator devices must be registered in the usual manner.
+
+static struct platform_device regulator_devices[] = {
+{
+        .name = "regulator",
+        .id = DCDC_1,
+        .dev = {
+                .platform_data = &regulator1_data,
+        },
+},
+{
+        .name = "regulator",
+        .id = DCDC_2,
+        .dev = {
+                .platform_data = &regulator2_data,
+        },
+},
 };
+/* register regulator 1 device */
+platform_device_register(&wm8350_regulator_devices[0]);
 
-regulator_set_platform_constraints("Regulator-1", &domain_1);
-regulator_set_platform_constraints("Regulator-2", &domain_2);
+/* register regulator 2 device */
+platform_device_register(&wm8350_regulator_devices[1]);
diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt
index a69050143592..4200accb9bba 100644
--- a/Documentation/power/regulator/regulator.txt
+++ b/Documentation/power/regulator/regulator.txt
@@ -10,11 +10,11 @@ Registration
 
 Drivers can register a regulator by calling :-
 
-struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
-                                          void *reg_data);
+struct regulator_dev *regulator_register(struct device *dev,
+        struct regulator_desc *regulator_desc);
 
-This will register the regulators capabilities and operations the regulator
-core. The core does not touch reg_data (private to regulator driver).
+This will register the regulators capabilities and operations to the regulator
+core.
 
 Regulators can be unregistered by calling :-
 
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv
index f32efb6fb12c..60ba66836038 100644
--- a/Documentation/video4linux/CARDLIST.bttv
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -150,3 +150,4 @@
 149 -> Typhoon TV-Tuner PCI (50684)
 150 -> Geovision GV-600                                    [008a:763c]
 151 -> Kozumi KTV-01C
+152 -> Encore ENL TV-FM-2                                  [1000:1801]
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885
index f0e613ba55b8..64823ccacd69 100644
--- a/Documentation/video4linux/CARDLIST.cx23885
+++ b/Documentation/video4linux/CARDLIST.cx23885
@@ -9,3 +9,5 @@
   8 -> Hauppauge WinTV-HVR1700                             [0070:8101]
   9 -> Hauppauge WinTV-HVR1400                             [0070:8010]
  10 -> DViCO FusionHDTV7 Dual Express                      [18ac:d618]
+ 11 -> DViCO FusionHDTV DVB-T Dual Express                 [18ac:db78]
+ 12 -> Leadtek Winfast PxDVR3200 H                         [107d:6681]
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88
index 7cf5685d3645..a5227e308f4a 100644
--- a/Documentation/video4linux/CARDLIST.cx88
+++ b/Documentation/video4linux/CARDLIST.cx88
@@ -66,3 +66,11 @@
  65 -> DViCO FusionHDTV 7 Gold                             [18ac:d610]
  66 -> Prolink Pixelview MPEG 8000GT                       [1554:4935]
  67 -> Kworld PlusTV HD PCI 120 (ATSC 120)                 [17de:08c1]
+ 68 -> Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid           [0070:6900,0070:6904,0070:6902]
+ 69 -> Hauppauge WinTV-HVR4000(Lite) DVB-S/S2              [0070:6905,0070:6906]
+ 70 -> TeVii S460 DVB-S/S2                                 [d460:9022]
+ 71 -> Omicom SS4 DVB-S/S2 PCI                             [A044:2011]
+ 72 -> TBS 8920 DVB-S/S2                                   [8920:8888]
+ 73 -> TeVii S420 DVB-S                                    [d420:9022]
+ 74 -> Prolink Pixelview Global Extreme                    [1554:4976]
+ 75 -> PROF 7300 DVB-S/S2                                  [B033:3033]
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index 53449cb99b17..187cc48d0924 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:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883]
+  1 -> Unknown EM2750/28xx video grabber        (em2820/em2840) [eb1a:2820,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883]
   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]
@@ -12,7 +12,7 @@
  11 -> Terratec Hybrid XS                       (em2880)        [0ccd:0042]
  12 -> Kworld PVR TV 2800 RF                    (em2820/em2840)
  13 -> Terratec Prodigy XS                      (em2880)        [0ccd:0047]
- 14 -> Pixelview Prolink PlayTV USB 2.0         (em2820/em2840)
+ 14 -> Pixelview Prolink PlayTV USB 2.0         (em2820/em2840) [eb1a:2821]
  15 -> V-Gear PocketTV                          (em2800)
  16 -> Hauppauge WinTV HVR 950                  (em2883)        [2040:6513,2040:6517,2040:651b,2040:651f]
  17 -> Pinnacle PCTV HD Pro Stick               (em2880)        [2304:0227]
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 39868af9cf9f..dc67eef38ff9 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -76,7 +76,7 @@
  75 -> AVerMedia AVerTVHD MCE A180              [1461:1044]
  76 -> SKNet MonsterTV Mobile                   [1131:4ee9]
  77 -> Pinnacle PCTV 40i/50i/110i (saa7133)     [11bd:002e]
- 78 -> ASUSTeK P7131 Dual                       [1043:4862,1043:4857]
+ 78 -> ASUSTeK P7131 Dual                       [1043:4862]
  79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B)
  80 -> ASUS Digimatrix TV                       [1043:0210]
  81 -> Philips Tiger reference design           [1131:2018]
@@ -145,3 +145,9 @@
 144 -> Beholder BeholdTV M6 Extra               [5ace:6193]
 145 -> AVerMedia MiniPCI DVB-T Hybrid M103      [1461:f636]
 146 -> ASUSTeK P7131 Analog
+147 -> Asus Tiger 3in1                          [1043:4878]
+148 -> Encore ENLTV-FM v5.3                     [1a7f:2008]
+149 -> Avermedia PCI pure analog (M135A)        [1461:f11d]
+150 -> Zogis Real Angel 220
+151 -> ADS Tech Instant HDTV                    [1421:0380]
+152 -> Asus Tiger Rev:1.00                      [1043:4857]
diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner
index 0e2394695bb8..30bbdda68d03 100644
--- a/Documentation/video4linux/CARDLIST.tuner
+++ b/Documentation/video4linux/CARDLIST.tuner
@@ -74,3 +74,4 @@ tuner=72 - Thomson FE6600
 tuner=73 - Samsung TCPG 6121P30A
 tuner=75 - Philips TEA5761 FM Radio
 tuner=76 - Xceive 5000 tuner
+tuner=77 - TCL tuner MF02GIP-5N-E
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt
index 9a3e4d797fa8..004818fab040 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -7,6 +7,7 @@ The modules are:
 xxxx            vend:prod
 ----
 spca501         0000:0000       MystFromOri Unknow Camera
+m5602           0402:5602       ALi Video Camera Controller
 spca501         040a:0002       Kodak DVC-325
 spca500         040a:0300       Kodak EZ200
 zc3xx           041e:041e       Creative WebCam Live!
@@ -42,6 +43,7 @@ zc3xx		0458:7007	Genius VideoCam V2
 zc3xx           0458:700c       Genius VideoCam V3
 zc3xx           0458:700f       Genius VideoCam Web V2
 sonixj          0458:7025       Genius Eye 311Q
+sonixj          0458:702e       Genius Slim 310 NB
 sonixj          045e:00f5       MicroSoft VX3000
 sonixj          045e:00f7       MicroSoft VX1000
 ov519           045e:028c       Micro$oft xbox cam
@@ -81,7 +83,7 @@ spca561		046d:092b	Labtec Webcam Plus
 spca561         046d:092c       Logitech QC chat Elch2
 spca561         046d:092d       Logitech QC Elch2
 spca561         046d:092e       Logitech QC Elch2
-spca561         046d:092f       Logitech QC Elch2
+spca561         046d:092f       Logitech  QuickCam Express Plus
 sunplus         046d:0960       Logitech ClickSmart 420
 sunplus         0471:0322       Philips DMVC1300K
 zc3xx           0471:0325       Philips SPC 200 NC
@@ -96,6 +98,29 @@ sunplus		04a5:3003	Benq DC 1300
 sunplus         04a5:3008       Benq DC 1500
 sunplus         04a5:300a       Benq DC 3410
 spca500         04a5:300c       Benq DC 1016
+finepix         04cb:0104       Fujifilm FinePix 4800
+finepix         04cb:0109       Fujifilm FinePix A202
+finepix         04cb:010b       Fujifilm FinePix A203
+finepix         04cb:010f       Fujifilm FinePix A204
+finepix         04cb:0111       Fujifilm FinePix A205
+finepix         04cb:0113       Fujifilm FinePix A210
+finepix         04cb:0115       Fujifilm FinePix A303
+finepix         04cb:0117       Fujifilm FinePix A310
+finepix         04cb:0119       Fujifilm FinePix F401
+finepix         04cb:011b       Fujifilm FinePix F402
+finepix         04cb:011d       Fujifilm FinePix F410
+finepix         04cb:0121       Fujifilm FinePix F601
+finepix         04cb:0123       Fujifilm FinePix F700
+finepix         04cb:0125       Fujifilm FinePix M603
+finepix         04cb:0127       Fujifilm FinePix S300
+finepix         04cb:0129       Fujifilm FinePix S304
+finepix         04cb:012b       Fujifilm FinePix S500
+finepix         04cb:012d       Fujifilm FinePix S602
+finepix         04cb:012f       Fujifilm FinePix S700
+finepix         04cb:0131       Fujifilm FinePix unknown model
+finepix         04cb:013b       Fujifilm FinePix unknown model
+finepix         04cb:013d       Fujifilm FinePix unknown model
+finepix         04cb:013f       Fujifilm FinePix F420
 sunplus         04f1:1001       JVC GC A50
 spca561         04fc:0561       Flexcam 100
 sunplus         04fc:500c       Sunplus CA500C
@@ -181,6 +206,7 @@ pac207		093a:2468	PAC207
 pac207          093a:2470       Genius GF112
 pac207          093a:2471       Genius VideoCam ge111
 pac207          093a:2472       Genius VideoCam ge110
+pac207          093a:2476       Genius e-Messenger 112
 pac7311         093a:2600       PAC7311 Typhoon
 pac7311         093a:2601       Philips SPC 610 NC
 pac7311         093a:2603       PAC7312
diff --git a/Documentation/video4linux/m5602.txt b/Documentation/video4linux/m5602.txt
new file mode 100644
index 000000000000..4450ab13f37b
--- /dev/null
+++ b/Documentation/video4linux/m5602.txt
@@ -0,0 +1,12 @@
+This document describes the ALi m5602 bridge connected
+to the following supported sensors:
+OmniVision OV9650,
+Samsung s5k83a,
+Samsung s5k4aa,
+Micron mt9m111,
+Pixel plus PO1030
+
+This driver mimics the windows drivers, which have a braindead implementation sending bayer-encoded frames at VGA resolution.
+In a perfect world we should be able to reprogram the m5602 and the connected sensor in hardware instead, supporting a range of resolutions and pixelformats
+
+Anyway, have fun and please report any bugs to m560x-driver-devel@lists.sourceforge.net
diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt
new file mode 100644
index 000000000000..178ef3c5e579
--- /dev/null
+++ b/Documentation/video4linux/soc-camera.txt
@@ -0,0 +1,120 @@
+                        Soc-Camera Subsystem
+                        ====================
+
+Terminology
+-----------
+
+The following terms are used in this document:
+ - camera / camera device / camera sensor - a video-camera sensor chip, capable
+   of connecting to a variety of systems and interfaces, typically uses i2c for
+   control and configuration, and a parallel or a serial bus for data.
+ - camera host - an interface, to which a camera is connected. Typically a
+   specialised interface, present on many SoCs, e.g., PXA27x and PXA3xx, SuperH,
+   AVR32, i.MX27, i.MX31.
+ - camera host bus - a connection between a camera host and a camera. Can be
+   parallel or serial, consists of data and control lines, e.g., clock, vertical
+   and horizontal synchronization signals.
+
+Purpose of the soc-camera subsystem
+-----------------------------------
+
+The soc-camera subsystem provides a unified API between camera host drivers and
+camera sensor drivers. It implements a V4L2 interface to the user, currently
+only the mmap method is supported.
+
+This subsystem has been written to connect drivers for System-on-Chip (SoC)
+video capture interfaces with drivers for CMOS camera sensor chips to enable
+the reuse of sensor drivers with various hosts. The subsystem has been designed
+to support multiple camera host interfaces and multiple cameras per interface,
+although most applications have only one camera sensor.
+
+Existing drivers
+----------------
+
+As of 2.6.27-rc4 there are two host drivers in the mainline: pxa_camera.c for
+PXA27x SoCs and sh_mobile_ceu_camera.c for SuperH SoCs, and four sensor drivers:
+mt9m001.c, mt9m111.c, mt9v022.c and a generic soc_camera_platform.c driver. This
+list is not supposed to be updated, look for more examples in your tree.
+
+Camera host API
+---------------
+
+A host camera driver is registered using the
+
+soc_camera_host_register(struct soc_camera_host *);
+
+function. The host object can be initialized as follows:
+
+static struct soc_camera_host pxa_soc_camera_host = {
+        .drv_name       = PXA_CAM_DRV_NAME,
+        .ops            = &pxa_soc_camera_host_ops,
+};
+
+All camera host methods are passed in a struct soc_camera_host_ops:
+
+static struct soc_camera_host_ops pxa_soc_camera_host_ops = {
+        .owner          = THIS_MODULE,
+        .add            = pxa_camera_add_device,
+        .remove         = pxa_camera_remove_device,
+        .suspend        = pxa_camera_suspend,
+        .resume         = pxa_camera_resume,
+        .set_fmt_cap    = pxa_camera_set_fmt_cap,
+        .try_fmt_cap    = pxa_camera_try_fmt_cap,
+        .init_videobuf  = pxa_camera_init_videobuf,
+        .reqbufs        = pxa_camera_reqbufs,
+        .poll           = pxa_camera_poll,
+        .querycap       = pxa_camera_querycap,
+        .try_bus_param  = pxa_camera_try_bus_param,
+        .set_bus_param  = pxa_camera_set_bus_param,
+};
+
+.add and .remove methods are called when a sensor is attached to or detached
+from the host, apart from performing host-internal tasks they shall also call
+sensor driver's .init and .release methods respectively. .suspend and .resume
+methods implement host's power-management functionality and its their
+responsibility to call respective sensor's methods. .try_bus_param and
+.set_bus_param are used to negotiate physical connection parameters between the
+host and the sensor. .init_videobuf is called by soc-camera core when a
+video-device is opened, further video-buffer management is implemented completely
+by the specific camera host driver. The rest of the methods are called from
+respective V4L2 operations.
+
+Camera API
+----------
+
+Sensor drivers can use struct soc_camera_link, typically provided by the
+platform, and used to specify to which camera host bus the sensor is connected,
+and arbitrarily provide platform .power and .reset methods for the camera.
+soc_camera_device_register() and soc_camera_device_unregister() functions are
+used to add a sensor driver to or remove one from the system. The registration
+function takes a pointer to struct soc_camera_device as the only parameter.
+This struct can be initialized as follows:
+
+        /* link to driver operations */
+        icd->ops        = &mt9m001_ops;
+        /* link to the underlying physical (e.g., i2c) device */
+        icd->control    = &client->dev;
+        /* window geometry */
+        icd->x_min      = 20;
+        icd->y_min      = 12;
+        icd->x_current  = 20;
+        icd->y_current  = 12;
+        icd->width_min  = 48;
+        icd->width_max  = 1280;
+        icd->height_min = 32;
+        icd->height_max = 1024;
+        icd->y_skip_top = 1;
+        /* camera bus ID, typically obtained from platform data */
+        icd->iface      = icl->bus_id;
+
+struct soc_camera_ops provides .probe and .remove methods, which are called by
+the soc-camera core, when a camera is matched against or removed from a camera
+host bus, .init, .release, .suspend, and .resume are called from the camera host
+driver as discussed above. Other members of this struct provide respective V4L2
+functionality.
+
+struct soc_camera_device also links to an array of struct soc_camera_data_format,
+listing pixel formats, supported by the camera.
+
+--
+Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>