media: docs: make V4L documents more compatible with Sphinx 3.1+

Sphinx 3.x broke support for the cdomain.py extension, as the
c domain code was rewritten. Due to that, the c tags need to
be re-written, in order to use the new c domain notation.

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

87 files changed, 559 insertions, 922 deletions

diff --git a/Documentation/userspace-api/media/v4l/buffer.rst b/Documentation/userspace-api/media/v4l/buffer.rst
index 4f95496adc5b..8be62dcffbb2 100644
--- a/Documentation/userspace-api/media/v4l/buffer.rst
+++ b/Documentation/userspace-api/media/v4l/buffer.rst
@@ -1,4 +1,5 @@
 .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. c:namespace:: V4L
 
 .. _buffer:
 
@@ -33,7 +34,6 @@ mem-to-mem devices is an exception to the rule: the timestamp source
 flags are copied from the OUTPUT video buffer to the CAPTURE video
 buffer.
 
-
 Interactions between formats, controls and buffers
 ==================================================
 
@@ -152,7 +152,6 @@ based on the queried sizes (for instance by allocating a set of buffers large
 enough for all the desired formats and controls, or by allocating separate set
 of appropriately sized buffers for each use case).
 
-
 .. c:type:: v4l2_buffer
 
 struct v4l2_buffer
@@ -257,7 +256,7 @@ struct v4l2_buffer
 	``V4L2_MEMORY_MMAP`` this is the offset of the buffer from the
 	start of the device memory. The value is returned by the driver
 	and apart of serving as parameter to the
-	:ref:`mmap() <func-mmap>` function not useful for applications.
+	:c:func:`mmap()` function not useful for applications.
 	See :ref:`mmap` for details
     * - unsigned long
       - ``userptr``
@@ -310,7 +309,6 @@ struct v4l2_buffer
 	given, then ``EINVAL`` will be returned.
 
 
-
 .. c:type:: v4l2_plane
 
 struct v4l2_plane
@@ -350,7 +348,7 @@ struct v4l2_plane
       - ``mem_offset``
       - When the memory type in the containing struct
 	:c:type:`v4l2_buffer` is ``V4L2_MEMORY_MMAP``, this
-	is the value that should be passed to :ref:`mmap() <func-mmap>`,
+	is the value that should be passed to :c:func:`mmap()`,
 	similar to the ``offset`` field in struct
 	:c:type:`v4l2_buffer`.
     * - unsigned long
@@ -384,7 +382,6 @@ struct v4l2_plane
 	applications.
 
 
-
 .. c:type:: v4l2_buf_type
 
 enum v4l2_buf_type
@@ -448,7 +445,6 @@ enum v4l2_buf_type
       - Buffer for metadata output, see :ref:`metadata`.
 
 
-
 .. _buffer-flags:
 
 Buffer Flags
@@ -720,7 +716,6 @@ enum v4l2_memory
       - The buffer is used for :ref:`DMA shared buffer <dmabuf>` I/O.
 
 
-
 Timecodes
 =========
 
@@ -729,7 +724,6 @@ The :c:type:`v4l2_buffer_timecode` structure is designed to hold a
 (struct :c:type:`timeval` timestamps are stored in the struct
 :c:type:`v4l2_buffer` ``timestamp`` field.)
 
-
 .. c:type:: v4l2_timecode
 
 struct v4l2_timecode
@@ -766,7 +760,6 @@ struct v4l2_timecode
       - The "user group" bits from the timecode.
 
 
-
 .. _timecode-type:
 
 Timecode Types
@@ -796,7 +789,6 @@ Timecode Types
       -
 
 
-
 .. _timecode-flags:
 
 Timecode Flags
diff --git a/Documentation/userspace-api/media/v4l/dev-capture.rst b/Documentation/userspace-api/media/v4l/dev-capture.rst
index 5ea1ffe71fa6..fe58fd450e2f 100644
--- a/Documentation/userspace-api/media/v4l/dev-capture.rst
+++ b/Documentation/userspace-api/media/v4l/dev-capture.rst
@@ -1,4 +1,5 @@
 .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. c:namespace:: V4L
 
 .. _capture:
 
@@ -19,7 +20,6 @@ device.
 
 .. note:: The same device file names are used for video output devices.
 
-
 Querying Capabilities
 =====================
 
@@ -34,7 +34,6 @@ functions they may also support the :ref:`video overlay <overlay>`
 streaming I/O methods must be supported. Tuners and audio inputs are
 optional.
 
-
 Supplemental Functions
 ======================
 
@@ -45,7 +44,6 @@ Video capture devices shall support :ref:`audio input <audio>`,
 :ref:`video input <video>` ioctls must be supported by all video
 capture devices.
 
-
 Image Format Negotiation
 ========================
 
@@ -55,7 +53,7 @@ capture, the latter how images are stored in memory, i. e. in RGB or YUV
 format, the number of bits per pixel or width and height. Together they
 also define how images are scaled in the process.
 
-As usual these parameters are *not* reset at :ref:`open() <func-open>`
+As usual these parameters are *not* reset at :c:func:`open()`
 time to permit Unix tool chains, programming a device and then reading
 from it as if it was a plain file. Well written V4L2 applications ensure
 they really get what they want, including cropping and scaling.
@@ -95,7 +93,6 @@ and :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, even if :ref:`VIDIOC_S_FMT <VIDIOC
 requests and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does.
 :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is optional.
 
-
 Reading Images
 ==============
 
diff --git a/Documentation/userspace-api/media/v4l/dev-output.rst b/Documentation/userspace-api/media/v4l/dev-output.rst
index 2315faf61aaf..eadcb4aa813b 100644
--- a/Documentation/userspace-api/media/v4l/dev-output.rst
+++ b/Documentation/userspace-api/media/v4l/dev-output.rst
@@ -1,4 +1,5 @@
 .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. c:namespace:: V4L
 
 .. _output:
 
@@ -18,7 +19,6 @@ device.
 
 .. note:: The same device file names are used also for video capture devices.
 
-
 Querying Capabilities
 =====================
 
@@ -32,7 +32,6 @@ functions they may also support the :ref:`raw VBI output <raw-vbi>`
 streaming I/O methods must be supported. Modulators and audio outputs
 are optional.
 
-
 Supplemental Functions
 ======================
 
@@ -43,7 +42,6 @@ Video output devices shall support :ref:`audio output <audio>`,
 :ref:`video output <video>` ioctls must be supported by all video
 output devices.
 
-
 Image Format Negotiation
 ========================
 
@@ -53,7 +51,7 @@ the latter how images are stored in memory, i. e. in RGB or YUV format,
 the number of bits per pixel or width and height. Together they also
 define how images are scaled in the process.
 
-As usual these parameters are *not* reset at :ref:`open() <func-open>`
+As usual these parameters are *not* reset at :c:func:`open()`
 time to permit Unix tool chains, programming a device and then writing
 to it as if it was a plain file. Well written V4L2 applications ensure
 they really get what they want, including cropping and scaling.
@@ -92,7 +90,6 @@ and :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, even if :ref:`VIDIOC_S_FMT <VIDIOC
 requests and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does.
 :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is optional.
 
-
 Writing Images
 ==============
 
diff --git a/Documentation/userspace-api/media/v4l/dev-raw-vbi.rst b/Documentation/userspace-api/media/v4l/dev-raw-vbi.rst
index bb52f85a619c..3f43a01ba938 100644
--- a/Documentation/userspace-api/media/v4l/dev-raw-vbi.rst
+++ b/Documentation/userspace-api/media/v4l/dev-raw-vbi.rst
@@ -1,4 +1,5 @@
 .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. c:namespace:: V4L
 
 .. _raw-vbi:
 
@@ -32,7 +33,6 @@ applications must call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
 Accessed as ``/dev/vbi``, raw VBI capturing or output is the default
 device function.
 
-
 Querying Capabilities
 =====================
 
@@ -44,7 +44,6 @@ in the ``capabilities`` field of struct
 read/write, streaming or asynchronous I/O methods must be supported. VBI
 devices may or may not have a tuner or modulator.
 
-
 Supplemental Functions
 ======================
 
@@ -53,7 +52,6 @@ VBI devices shall support :ref:`video input or output <video>`,
 ioctls as needed. The :ref:`video standard <standard>` ioctls provide
 information vital to program a VBI device, therefore must be supported.
 
-
 Raw VBI Format Negotiation
 ==========================
 
@@ -62,7 +60,7 @@ frequency. To properly interpret the data V4L2 specifies an ioctl to
 query the sampling parameters. Moreover, to allow for some flexibility
 applications can also suggest different parameters.
 
-As usual these parameters are *not* reset at :ref:`open() <func-open>`
+As usual these parameters are *not* reset at :c:func:`open()`
 time to permit Unix tool chains, programming a device and then reading
 from it as if it was a plain file. Well written V4L2 applications should
 always ensure they really get what they want, requesting reasonable
@@ -91,8 +89,8 @@ happen for instance when the video and VBI areas to capture would
 overlap, or when the driver supports multiple opens and another process
 already requested VBI capturing or output. Anyway, applications must
 expect other resource allocation points which may return ``EBUSY``, at the
-:ref:`VIDIOC_STREAMON` ioctl and the first :ref:`read() <func-read>`
-, :ref:`write() <func-write>` and :ref:`select() <func-select>` calls.
+:ref:`VIDIOC_STREAMON` ioctl and the first :c:func:`read()`
+, :c:func:`write()` and :c:func:`select()` calls.
 
 VBI devices must implement both the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, even if :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ignores all requests
@@ -182,7 +180,6 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does
       - This array is reserved for future extensions. Drivers and
 	applications must set it to zero.
 
-
 .. tabularcolumns:: |p{4.4cm}|p{1.5cm}|p{11.6cm}|
 
 .. _vbifmt-flags:
@@ -218,7 +215,6 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does
 	non-zero.
 
 
-
 .. _vbi-hsync:
 
 .. kernel-figure:: vbi_hsync.svg
@@ -227,7 +223,6 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does
 
     **Figure 4.1. Line synchronization**
 
-
 .. _vbi-525:
 
 .. kernel-figure:: vbi_525.svg
@@ -251,7 +246,6 @@ negotiation, or after switching the video standard which may invalidate
 the negotiated VBI parameters, should be refused by the driver. A format
 change during active I/O is not permitted.
 
-
 Reading and writing VBI images
 ==============================
 
@@ -261,7 +255,6 @@ consisting of two fields of VBI images immediately following in memory.
 
 The total size of a frame computes as follows:
 
-
 .. code-block:: c
 
     (count[0] + count[1]) * samples_per_line * sample size in bytes
@@ -276,8 +269,8 @@ The latter bears the possibility of synchronizing video and VBI data by
 using buffer timestamps.
 
 Remember the :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` ioctl and the
-first :ref:`read() <func-read>`, :ref:`write() <fun