Merge tag 'v3.10' into sched/core

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

  Symlink to each of the cache devices comprising this cache set. 

cache_available_percent

  Percentage of cache device free.

  Percentage of cache device which doesn't contain dirty data, and could

  potentially be used for writeback.  This doesn't mean this space isn't used

  for clean cached data; the unused statistic (in priority_stats) is typically

  much lower.

clear_stats

  Clears the statistics associated with this cache

  Total buckets in this cache

priority_stats

  Statistics about how recently data in the cache has been accessed.  This can

  reveal your working set size.

  Statistics about how recently data in the cache has been accessed.

  This can reveal your working set size.  Unused is the percentage of

  the cache that doesn't contain any data.  Metadata is bcache's

  metadata overhead.  Average is the average priority of cache buckets.

  Next is a list of quantiles with the priority threshold of each.

written

  Sum of all data that has been written to the cache; comparison with

		Each device type has 5 bits (32 minors).

 13 block	8-bit MFM/RLL/IDE controller

		  0 = /dev/xda		First XT disk whole disk

		 64 = /dev/xdb		Second XT disk whole disk

		Partitions are handled in the same way as IDE disks

		(see major number 3).

 13 block	Previously used for the XT disk (/dev/xdN)

		Deleted in kernel v3.9.

 14 char	Open Sound System (OSS)

		  0 = /dev/mixer	Mixer control

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;