Merge tag 'asoc-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next

ASoC: More updates for v3.11

Some more fixes and enhancements, and also a bunch of refectoring for
AC'97 support which enables more than one AC'97 controller driver to be
built in.

5 files changed, 47 insertions, 15 deletions

diff --git a/Documentation/DocBook/media/v4l/dev-codec.xml b/Documentation/DocBook/media/v4l/dev-codec.xml
index dca0ecd54dc6..ff44c16fc080 100644
--- a/Documentation/DocBook/media/v4l/dev-codec.xml
+++ b/Documentation/DocBook/media/v4l/dev-codec.xml
@@ -1,18 +1,27 @@
   <title>Codec Interface</title>
 
-  <note>
-    <title>Suspended</title>
+  <para>A V4L2 codec can compress, decompress, transform, or otherwise
+convert video data from one format into another format, in memory. Typically
+such devices are memory-to-memory devices (i.e. devices with the
+<constant>V4L2_CAP_VIDEO_M2M</constant> or <constant>V4L2_CAP_VIDEO_M2M_MPLANE</constant>
+capability set).
+</para>
 
-    <para>This interface has been be suspended from the V4L2 API
-implemented in Linux 2.6 until we have more experience with codec
-device interfaces.</para>
-  </note>
+  <para>A memory-to-memory video node acts just like a normal video node, but it
+supports both output (sending frames from memory to the codec hardware) and
+capture (receiving the processed frames from the codec hardware into memory)
+stream I/O. An application will have to setup the stream
+I/O for both sides and finally call &VIDIOC-STREAMON; for both capture and output
+to start the codec.</para>
 
-  <para>A V4L2 codec can compress, decompress, transform, or otherwise
-convert video data from one format into another format, in memory.
-Applications send data to be converted to the driver through a
-&func-write; call, and receive the converted data through a
-&func-read; call. For efficiency a driver may also support streaming
-I/O.</para>
+  <para>Video compression codecs use the MPEG controls to setup their codec parameters
+(note that the MPEG controls actually support many more codecs than just MPEG).
+See <xref linkend="mpeg-controls"></xref>.</para>
 
-  <para>[to do]</para>
+  <para>Memory-to-memory devices can often be used as a shared resource: you can
+open the video node multiple times, each application setting up their own codec properties
+that are local to the file handle, and each can use it independently from the others.
+The driver will arbitrate access to the codec and reprogram it whenever another file
+handler gets access. This is different from the usual video node behavior where the video properties
+are global to the device (i.e. changing something through one file handle is visible
+through another file handle).</para>
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index bfc93cdcf696..bfe823dd0f31 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -493,7 +493,7 @@ and discussions on the V4L mailing list.</revremark>
 </partinfo>
 
 <title>Video for Linux Two API Specification</title>
- <subtitle>Revision 3.9</subtitle>
+ <subtitle>Revision 3.10</subtitle>
 
   <chapter id="common">
     &sub-common;
diff --git a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
index 3f62adfb3e0b..de9f6b78ee51 100644
--- a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
+++ b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
@@ -2,7 +2,7 @@ Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE)
 
 Required properties:
 
-- compatible    : should be "samsung,exynos4212-fimc" for Exynos4212 and
+- compatible    : should be "samsung,exynos4212-fimc-lite" for Exynos4212 and
                   Exynos4412 SoCs;
 - reg           : physical base address and size of the device memory mapped
                   registers;
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1701.txt b/Documentation/devicetree/bindings/sound/adi,adau1701.txt
index 3afeda77b5b9..547a49b56a62 100644
--- a/Documentation/devicetree/bindings/sound/adi,adau1701.txt
+++ b/Documentation/devicetree/bindings/sound/adi,adau1701.txt
@@ -11,6 +11,15 @@ Optional properties:
  - reset-gpio:          A GPIO spec to define which pin is connected to the
                         chip's !RESET pin. If specified, the driver will
                         assert a hardware reset at probe time.
+ - adi,pll-mode-gpios:  An array of two GPIO specs to describe the GPIOs
+                        the ADAU's PLL config pins are connected to.
+                        The state of the pins are set according to the
+                        configured clock divider on ASoC side before the
+                        firmware is loaded.
+ - adi,pin-config:      An array of 12 numerical values selecting one of the
+                        pin configurations as described in the datasheet,
+                        table 53. Note that the value of this property has
+                        to be prefixed with '/bits/ 8'.
 
 Examples:
 
@@ -19,5 +28,8 @@ Examples:
                         compatible = "adi,adau1701";
                         reg = <0x34>;
                         reset-gpio = <&gpio 23 0>;
+                        adi,pll-mode-gpios = <&gpio 24 0 &gpio 25 0>;
+                        adi,pin-config = /bits/ 8 <0x4 0x7 0x5 0x5 0x4 0x4
+                                                   0x4 0x4 0x4 0x4 0x4 0x4>;
                 };
         };
diff --git a/Documentation/devicetree/bindings/sound/ti,tas5086.txt b/Documentation/devicetree/bindings/sound/ti,tas5086.txt
index 8ea4f5b4818d..d2866a0d6a26 100644
--- a/Documentation/devicetree/bindings/sound/ti,tas5086.txt
+++ b/Documentation/devicetree/bindings/sound/ti,tas5086.txt
@@ -20,6 +20,17 @@ Optional properties:
                         When not specified, the hardware default of 1300ms
                         is retained.
 
+ - ti,mid-z-channel-X:  Boolean properties, X being a number from 1 to 6.
+                        If given, channel X will start with the Mid-Z start
+                        sequence, otherwise the default Low-Z scheme is used.
+
+                        The correct configuration depends on how the power
+                        stages connected to the PWM output pins work. Not all
+                        power stages are compatible to Mid-Z - please refer
+                        to the datasheets for more details.
+
+                        Most systems should not set any of these properties.
+
 Examples:
 
         i2c_bus {