aboutsummaryrefslogtreecommitdiff
path: root/Documentation/userspace-api/media/v4l
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/userspace-api/media/v4l')
-rw-r--r--Documentation/userspace-api/media/v4l/control.rst6
-rw-r--r--Documentation/userspace-api/media/v4l/meta-formats.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-pisp-fe.rst39
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-y16i.rst73
-rw-r--r--Documentation/userspace-api/media/v4l/subdev-formats.rst156
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst18
-rw-r--r--Documentation/userspace-api/media/v4l/yuv-formats.rst1
7 files changed, 289 insertions, 5 deletions
diff --git a/Documentation/userspace-api/media/v4l/control.rst b/Documentation/userspace-api/media/v4l/control.rst
index 57893814a1e5..9253cc946f02 100644
--- a/Documentation/userspace-api/media/v4l/control.rst
+++ b/Documentation/userspace-api/media/v4l/control.rst
@@ -290,13 +290,15 @@ Control IDs
This is a read-only control that can be read by the application and
used as a hint to determine the number of CAPTURE buffers to pass to
REQBUFS. The value is the minimum number of CAPTURE buffers that is
- necessary for hardware to work.
+ necessary for hardware to work. This control is required for stateful
+ decoders.
``V4L2_CID_MIN_BUFFERS_FOR_OUTPUT`` ``(integer)``
This is a read-only control that can be read by the application and
used as a hint to determine the number of OUTPUT buffers to pass to
REQBUFS. The value is the minimum number of OUTPUT buffers that is
- necessary for hardware to work.
+ necessary for hardware to work. This control is required for stateful
+ encoders.
.. _v4l2-alpha-component:
diff --git a/Documentation/userspace-api/media/v4l/meta-formats.rst b/Documentation/userspace-api/media/v4l/meta-formats.rst
index c6e56b5888bc..86ffb3bc8ade 100644
--- a/Documentation/userspace-api/media/v4l/meta-formats.rst
+++ b/Documentation/userspace-api/media/v4l/meta-formats.rst
@@ -16,6 +16,7 @@ These formats are used for the :ref:`metadata` interface only.
metafmt-generic
metafmt-intel-ipu3
metafmt-pisp-be
+ metafmt-pisp-fe
metafmt-rkisp1
metafmt-uvc
metafmt-vivid
diff --git a/Documentation/userspace-api/media/v4l/metafmt-pisp-fe.rst b/Documentation/userspace-api/media/v4l/metafmt-pisp-fe.rst
new file mode 100644
index 000000000000..fddeada83e4a
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/metafmt-pisp-fe.rst
@@ -0,0 +1,39 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _v4l2-meta-fmt-rpi-fe-cfg:
+
+************************
+V4L2_META_FMT_RPI_FE_CFG
+************************
+
+Raspberry Pi PiSP Front End configuration format
+================================================
+
+The Raspberry Pi PiSP Front End image signal processor is configured by
+userspace by providing a buffer of configuration parameters to the
+`rp1-cfe-fe-config` output video device node using the
+:c:type:`v4l2_meta_format` interface.
+
+The `Raspberry Pi PiSP technical specification
+<https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf>`_
+provide detailed description of the Front End configuration and programming
+model.
+
+.. _v4l2-meta-fmt-rpi-fe-stats:
+
+**************************
+V4L2_META_FMT_RPI_FE_STATS
+**************************
+
+Raspberry Pi PiSP Front End statistics format
+=============================================
+
+The Raspberry Pi PiSP Front End image signal processor provides statistics data
+by writing to a buffer provided via the `rp1-cfe-fe-stats` capture video device
+node using the
+:c:type:`v4l2_meta_format` interface.
+
+The `Raspberry Pi PiSP technical specification
+<https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf>`_
+provide detailed description of the Front End configuration and programming
+model.
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-y16i.rst b/Documentation/userspace-api/media/v4l/pixfmt-y16i.rst
new file mode 100644
index 000000000000..74ba9e910a38
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/pixfmt-y16i.rst
@@ -0,0 +1,73 @@
+.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+
+.. _V4L2-PIX-FMT-Y16I:
+
+**************************
+V4L2_PIX_FMT_Y16I ('Y16I')
+**************************
+
+Interleaved grey-scale image, e.g. from a stereo-pair
+
+
+Description
+===========
+
+This is a grey-scale image with a depth of 16 bits per pixel, but with pixels
+from 2 sources interleaved and unpacked. Each pixel is stored in a 16-bit word
+in the little-endian order. The first pixel is from the left source.
+
+**Pixel unpacked representation.**
+Left/Right pixels 16-bit unpacked - 16-bit for each interleaved pixel.
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - Y'\ :sub:`0L[7:0]`
+ - Y'\ :sub:`0L[15:8]`
+ - Y'\ :sub:`0R[7:0]`
+ - Y'\ :sub:`0R[15:8]`
+
+**Byte Order.**
+Each cell is one byte.
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start + 0:
+ - Y'\ :sub:`00Llow`
+ - Y'\ :sub:`00Lhigh`
+ - Y'\ :sub:`00Rlow`
+ - Y'\ :sub:`00Rhigh`
+ - Y'\ :sub:`01Llow`
+ - Y'\ :sub:`01Lhigh`
+ - Y'\ :sub:`01Rlow`
+ - Y'\ :sub:`01Rhigh`
+ * - start + 8:
+ - Y'\ :sub:`10Llow`
+ - Y'\ :sub:`10Lhigh`
+ - Y'\ :sub:`10Rlow`
+ - Y'\ :sub:`10Rhigh`
+ - Y'\ :sub:`11Llow`
+ - Y'\ :sub:`11Lhigh`
+ - Y'\ :sub:`11Rlow`
+ - Y'\ :sub:`11Rhigh`
+ * - start + 16:
+ - Y'\ :sub:`20Llow`
+ - Y'\ :sub:`20Lhigh`
+ - Y'\ :sub:`20Rlow`
+ - Y'\ :sub:`20Rhigh`
+ - Y'\ :sub:`21Llow`
+ - Y'\ :sub:`21Lhigh`
+ - Y'\ :sub:`21Rlow`
+ - Y'\ :sub:`21Rhigh`
+ * - start + 24:
+ - Y'\ :sub:`30Llow`
+ - Y'\ :sub:`30Lhigh`
+ - Y'\ :sub:`30Rlow`
+ - Y'\ :sub:`30Rhigh`
+ - Y'\ :sub:`31Llow`
+ - Y'\ :sub:`31Lhigh`
+ - Y'\ :sub:`31Rlow`
+ - Y'\ :sub:`31Rhigh`
diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst
index d2a6cd2e1eb2..2a94371448dc 100644
--- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
+++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
@@ -2225,7 +2225,7 @@ The following table list existing packed 48bit wide RGB formats.
\endgroup
On LVDS buses, usually each sample is transferred serialized in seven
-time slots per pixel clock, on three (18-bit) or four (24-bit)
+time slots per pixel clock, on three (18-bit) or four (24-bit) or five (30-bit)
differential data pairs at the same time. The remaining bits are used
for control signals as defined by SPWG/PSWG/VESA or JEIDA standards. The
24-bit RGB format serialized in seven time slots on four lanes using
@@ -2246,11 +2246,12 @@ JEIDA defined bit mapping will be named
- Code
-
-
- - :cspan:`3` Data organization
+ - :cspan:`4` Data organization
* -
-
- Timeslot
- Lane
+ - 4
- 3
- 2
- 1
@@ -2262,6 +2263,7 @@ JEIDA defined bit mapping will be named
- 0
-
-
+ -
- d
- b\ :sub:`1`
- g\ :sub:`0`
@@ -2270,6 +2272,7 @@ JEIDA defined bit mapping will be named
- 1
-
-
+ -
- d
- b\ :sub:`0`
- r\ :sub:`5`
@@ -2278,6 +2281,7 @@ JEIDA defined bit mapping will be named
- 2
-
-
+ -
- d
- g\ :sub:`5`
- r\ :sub:`4`
@@ -2286,6 +2290,7 @@ JEIDA defined bit mapping will be named
- 3
-
-
+ -
- b\ :sub:`5`
- g\ :sub:`4`
- r\ :sub:`3`
@@ -2294,6 +2299,7 @@ JEIDA defined bit mapping will be named
- 4
-
-
+ -
- b\ :sub:`4`
- g\ :sub:`3`
- r\ :sub:`2`
@@ -2302,6 +2308,7 @@ JEIDA defined bit mapping will be named
- 5
-
-
+ -
- b\ :sub:`3`
- g\ :sub:`2`
- r\ :sub:`1`
@@ -2310,6 +2317,7 @@ JEIDA defined bit mapping will be named
- 6
-
-
+ -
- b\ :sub:`2`
- g\ :sub:`1`
- r\ :sub:`0`
@@ -2319,6 +2327,7 @@ JEIDA defined bit mapping will be named
- 0x1011
- 0
-
+ -
- d
- d
- b\ :sub:`1`
@@ -2327,6 +2336,7 @@ JEIDA defined bit mapping will be named
-
- 1
-
+ -
- b\ :sub:`7`
- d
- b\ :sub:`0`
@@ -2335,6 +2345,7 @@ JEIDA defined bit mapping will be named
-
- 2
-
+ -
- b\ :sub:`6`
- d
- g\ :sub:`5`
@@ -2343,6 +2354,7 @@ JEIDA defined bit mapping will be named
-
- 3
-
+ -
- g\ :sub:`7`
- b\ :sub:`5`
- g\ :sub:`4`
@@ -2351,6 +2363,7 @@ JEIDA defined bit mapping will be named
-
- 4
-
+ -
- g\ :sub:`6`
- b\ :sub:`4`
- g\ :sub:`3`
@@ -2359,6 +2372,7 @@ JEIDA defined bit mapping will be named
-
- 5
-
+ -
- r\ :sub:`7`
- b\ :sub:`3`
- g\ :sub:`2`
@@ -2367,6 +2381,7 @@ JEIDA defined bit mapping will be named
-
- 6
-
+ -
- r\ :sub:`6`
- b\ :sub:`2`
- g\ :sub:`1`
@@ -2377,6 +2392,7 @@ JEIDA defined bit mapping will be named
- 0x1012
- 0
-
+ -
- d
- d
- b\ :sub:`3`
@@ -2385,6 +2401,7 @@ JEIDA defined bit mapping will be named
-
- 1
-
+ -
- b\ :sub:`1`
- d
- b\ :sub:`2`
@@ -2393,6 +2410,7 @@ JEIDA defined bit mapping will be named
-
- 2
-
+ -
- b\ :sub:`0`
- d
- g\ :sub:`7`
@@ -2401,6 +2419,7 @@ JEIDA defined bit mapping will be named
-
- 3
-
+ -
- g\ :sub:`1`
- b\ :sub:`7`
- g\ :sub:`6`
@@ -2409,6 +2428,7 @@ JEIDA defined bit mapping will be named
-
- 4
-
+ -
- g\ :sub:`0`
- b\ :sub:`6`
- g\ :sub:`5`
@@ -2417,6 +2437,7 @@ JEIDA defined bit mapping will be named
-
- 5
-
+ -
- r\ :sub:`1`
- b\ :sub:`5`
- g\ :sub:`4`
@@ -2425,10 +2446,141 @@ JEIDA defined bit mapping will be named
-
- 6
-
+ -
+ - r\ :sub:`0`
+ - b\ :sub:`4`
+ - g\ :sub:`3`
+ - r\ :sub:`2`
+ * .. _MEDIA-BUS-FMT-RGB101010-1X7X5-SPWG:
+
+ - MEDIA_BUS_FMT_RGB101010_1X7X5_SPWG
+ - 0x1026
+ - 0
+ -
+ - d
+ - d
+ - d
+ - b\ :sub:`1`
+ - g\ :sub:`0`
+ * -
+ -
+ - 1
+ -
+ - b\ :sub:`9`
+ - b\ :sub:`7`
+ - d
+ - b\ :sub:`0`
+ - r\ :sub:`5`
+ * -
+ -
+ - 2
+ -
+ - b\ :sub:`8`
+ - b\ :sub:`6`
+ - d
+ - g\ :sub:`5`
+ - r\ :sub:`4`
+ * -
+ -
+ - 3
+ -
+ - g\ :sub:`9`
+ - g\ :sub:`7`
+ - b\ :sub:`5`
+ - g\ :sub:`4`
+ - r\ :sub:`3`
+ * -
+ -
+ - 4
+ -
+ - g\ :sub:`8`
+ - g\ :sub:`6`
+ - b\ :sub:`4`
+ - g\ :sub:`3`
+ - r\ :sub:`2`
+ * -
+ -
+ - 5
+ -
+ - r\ :sub:`9`
+ - r\ :sub:`7`
+ - b\ :sub:`3`
+ - g\ :sub:`2`
+ - r\ :sub:`1`
+ * -
+ -
+ - 6
+ -
+ - r\ :sub:`8`
+ - r\ :sub:`6`
+ - b\ :sub:`2`
+ - g\ :sub:`1`
- r\ :sub:`0`
+ * .. _MEDIA-BUS-FMT-RGB101010-1X7X5-JEIDA:
+
+ - MEDIA_BUS_FMT_RGB101010_1X7X5_JEIDA
+ - 0x1027
+ - 0
+ -
+ - d
+ - d
+ - d
+ - b\ :sub:`5`
+ - g\ :sub:`4`
+ * -
+ -
+ - 1
+ -
+ - b\ :sub:`1`
+ - b\ :sub:`3`
+ - d
- b\ :sub:`4`
+ - r\ :sub:`9`
+ * -
+ -
+ - 2
+ -
+ - b\ :sub:`0`
+ - b\ :sub:`2`
+ - d
+ - g\ :sub:`9`
+ - r\ :sub:`8`
+ * -
+ -
+ - 3
+ -
+ - g\ :sub:`1`
- g\ :sub:`3`
+ - b\ :sub:`9`
+ - g\ :sub:`8`
+ - r\ :sub:`7`
+ * -
+ -
+ - 4
+ -
+ - g\ :sub:`0`
+ - g\ :sub:`2`
+ - b\ :sub:`8`
+ - g\ :sub:`7`
+ - r\ :sub:`6`
+ * -
+ -
+ - 5
+ -
+ - r\ :sub:`1`
+ - r\ :sub:`3`
+ - b\ :sub:`7`
+ - g\ :sub:`6`
+ - r\ :sub:`5`
+ * -
+ -
+ - 6
+ -
+ - r\ :sub:`0`
- r\ :sub:`2`
+ - b\ :sub:`6`
+ - g\ :sub:`5`
+ - r\ :sub:`4`
.. raw:: latex
diff --git a/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst b/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst
index 3adb3d205531..0f69aa04607f 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst
@@ -85,7 +85,17 @@ the ``mbus_code`` field is handled differently:
* - __u32
- ``index``
- Number of the format in the enumeration, set by the application.
- This is in no way related to the ``pixelformat`` field.
+ This is in no way related to the ``pixelformat`` field.
+ When the index is ORed with ``V4L2_FMTDESC_FLAG_ENUM_ALL`` the
+ driver clears the flag and enumerates all the possible formats,
+ ignoring any limitations from the current configuration. Drivers
+ which do not support this flag always return an ``EINVAL``
+ error code without clearing this flag.
+ Formats enumerated when using ``V4L2_FMTDESC_FLAG_ENUM_ALL`` flag
+ shouldn't be used when calling :c:func:`VIDIOC_ENUM_FRAMESIZES`
+ or :c:func:`VIDIOC_ENUM_FRAMEINTERVALS`.
+ ``V4L2_FMTDESC_FLAG_ENUM_ALL`` should only be used by drivers that
+ can return different format list depending on this flag.
* - __u32
- ``type``
- Type of the data stream, set by the application. Only these types
@@ -234,6 +244,12 @@ the ``mbus_code`` field is handled differently:
valid. The buffer consists of ``height`` lines, each having ``width``
Data Units of data and the offset (in bytes) between the beginning of
each two consecutive lines is ``bytesperline``.
+ * - ``V4L2_FMTDESC_FLAG_ENUM_ALL``
+ - 0x80000000
+ - When the applications ORs ``index`` with ``V4L2_FMTDESC_FLAG_ENUM_ALL`` flag
+ the driver enumerates all the possible pixel formats without taking care
+ of any already set configuration. Drivers which do not support this flag,
+ always return ``EINVAL`` without clearing this flag.
Return Value
============
diff --git a/Documentation/userspace-api/media/v4l/yuv-formats.rst b/Documentation/userspace-api/media/v4l/yuv-formats.rst
index 24b34cdfa6fe..78ee406d7647 100644
--- a/Documentation/userspace-api/media/v4l/yuv-formats.rst
+++ b/Documentation/userspace-api/media/v4l/yuv-formats.rst
@@ -269,5 +269,6 @@ image.
pixfmt-yuv-luma
pixfmt-y8i
pixfmt-y12i
+ pixfmt-y16i
pixfmt-uv8
pixfmt-m420