media: docs: move uAPI book to userspace-api/media

Since 2017, there is an space reserved for userspace API,
created by changeset 1d596dee3862 ("docs: Create a user-space API guide").

As the media subsystem was one of the first subsystems to use
Sphinx, until this patch, we were keeping things on a separate
place.

Let's just use the new location, as having all uAPI altogether
will likely make things easier for developers.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

1 files changed, 0 insertions, 68 deletions

diff --git a/Documentation/media/uapi/v4l/planar-apis.rst b/Documentation/media/uapi/v4l/planar-apis.rst
deleted file mode 100644
index a422dc9d592c..000000000000
--- a/Documentation/media/uapi/v4l/planar-apis.rst
+++ /dev/null
@@ -1,68 +0,0 @@
-.. Permission is granted to copy, distribute and/or modify this
-.. document under the terms of the GNU Free Documentation License,
-.. Version 1.1 or any later version published by the Free Software
-.. Foundation, with no Invariant Sections, no Front-Cover Texts
-.. and no Back-Cover Texts. A copy of the license is included at
-.. Documentation/media/uapi/fdl-appendix.rst.
-..
-.. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections
-
-.. _planar-apis:
-
-*****************************
-Single- and multi-planar APIs
-*****************************
-
-Some devices require data for each input or output video frame to be
-placed in discontiguous memory buffers. In such cases, one video frame
-has to be addressed using more than one memory address, i.e. one pointer
-per "plane". A plane is a sub-buffer of the current frame. For examples
-of such formats see :ref:`pixfmt`.
-
-Initially, V4L2 API did not support multi-planar buffers and a set of
-extensions has been introduced to handle them. Those extensions
-constitute what is being referred to as the "multi-planar API".
-
-Some of the V4L2 API calls and structures are interpreted differently,
-depending on whether single- or multi-planar API is being used. An
-application can choose whether to use one or the other by passing a
-corresponding buffer type to its ioctl calls. Multi-planar versions of
-buffer types are suffixed with an ``_MPLANE`` string. For a list of
-available multi-planar buffer types see enum
-:c:type:`v4l2_buf_type`.
-
-
-Multi-planar formats
-====================
-
-Multi-planar API introduces new multi-planar formats. Those formats use
-a separate set of FourCC codes. It is important to distinguish between
-the multi-planar API and a multi-planar format. Multi-planar API calls
-can handle all single-planar formats as well (as long as they are passed
-in multi-planar API structures), while the single-planar API cannot
-handle multi-planar formats.
-
-
-Calls that distinguish between single and multi-planar APIs
-===========================================================
-
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>`
-    Two additional multi-planar capabilities are added. They can be set
-    together with non-multi-planar ones for devices that handle both
-    single- and multi-planar formats.
-
-:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`, :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`, :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`
-    New structures for describing multi-planar formats are added: struct
-    :c:type:`v4l2_pix_format_mplane` and
-    struct :c:type:`v4l2_plane_pix_format`.
-    Drivers may define new multi-planar formats, which have distinct
-    FourCC codes from the existing single-planar ones.
-
-:ref:`VIDIOC_QBUF <VIDIOC_QBUF>`, :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>`, :ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>`
-    A new struct :c:type:`v4l2_plane` structure for
-    describing planes is added. Arrays of this structure are passed in
-    the new ``m.planes`` field of struct
-    :c:type:`v4l2_buffer`.
-
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`
-    Will allocate multi-planar buffers as requested.