Merge branches 'x86/vt-d', 'arm/omap', 'core', 'x86/amd' and 'arm/smmu' into next

  <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>

</partinfo>

<title>Video for Linux Two API Specification</title>

 <subtitle>Revision 3.9</subtitle>

 <subtitle>Revision 3.10</subtitle>

  <chapter id="common">

    &sub-common;

* ARM System MMU Architecture Implementation

ARM SoCs may contain an implementation of the ARM System Memory

Management Unit Architecture, which can be used to provide 1 or 2 stages

of address translation to bus masters external to the CPU.

The SMMU may also raise interrupts in response to various fault

conditions.

** System MMU required properties:

- compatible    : Should be one of:

                        "arm,smmu-v1"

                        "arm,smmu-v2"

                        "arm,mmu-400"

                        "arm,mmu-500"

                  depending on the particular implementation and/or the

                  version of the architecture implemented.

- reg           : Base address and size of the SMMU.

- #global-interrupts : The number of global interrupts exposed by the

                       device.

- interrupts    : Interrupt list, with the first #global-irqs entries

                  corresponding to the global interrupts and any

                  following entries corresponding to context interrupts,

                  specified in order of their indexing by the SMMU.

                  For SMMUv2 implementations, there must be exactly one

                  interrupt per context bank. In the case of a single,

                  combined interrupt, it must be listed multiple times.

- mmu-masters   : A list of phandles to device nodes representing bus

                  masters for which the SMMU can provide a translation

                  and their corresponding StreamIDs (see example below).

                  Each device node linked from this list must have a

                  "#stream-id-cells" property, indicating the number of

                  StreamIDs associated with it.

** System MMU optional properties:

- smmu-parent   : When multiple SMMUs are chained together, this

                  property can be used to provide a phandle to the

                  parent SMMU (that is the next SMMU on the path going

                  from the mmu-masters towards memory) node for this

                  SMMU.

Example:

        smmu {

                compatible = "arm,smmu-v1";

                reg = <0xba5e0000 0x10000>;

                #global-interrupts = <2>;

                interrupts = <0 32 4>,

                             <0 33 4>,

                             <0 34 4>, /* This is the first context interrupt */

                             <0 35 4>,

                             <0 36 4>,

                             <0 37 4>;

                /*

                 * Two DMA controllers, the first with two StreamIDs (0xd01d

                 * and 0xd01e) and the second with only one (0xd11c).

                 */

                mmu-masters = <&dma0 0xd01d 0xd01e>,

                              <&dma1 0xd11c>;

        };

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;

  alc271-dmic	Enable ALC271X digital mic workaround

  inv-dmic	Inverted internal mic workaround

  lenovo-dock   Enables docking station I/O for some Lenovos

  dell-headset-multi	Headset jack, which can also be used as mic-in

  dell-headset-dock	Headset jack (without mic-in), and also dock I/O

ALC662/663/272

==============

  asus-mode7	ASUS

  asus-mode8	ASUS

  inv-dmic	Inverted internal mic workaround

  dell-headset-multi	Headset jack, which can also be used as mic-in

ALC680

======