Merge tag 'media/v6.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab: - New sensor drivers: gc05a2, gc08a3 and imx283 - New serializer/deserializer drivers: max96714 and max96717 - New JPEG encoder driver: e5010 - Support for Raspberry Pi PiSP Backend (BE) ISP driver - Old documentation for av7110 driver removed, as a new version was added as Documentation/userspace-api/media/dvb/legacy*.rst - atompisp: Linux firmwares are now available, so drop firmware-related task from TODO and update firmware logic - The imx258 driver has gained several improvements - wave5 driver has gained support for HEVC decoding - em28xx gained support for MyGica UTV3 - av7110 budget-patch driver removed - Lots of other cleanups, improvements and fixes * tag 'media/v6.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (301 commits) media: raspberrypi: Switch to remove_new media: uapi: pisp_be_config: Add extra config fields media: uapi: pisp_be_config: Re-sort pisp_be_tiles_config media: uapi: pisp_common: Capitalize all macros media: uapi: pisp_common: Add 32 bpp format test media: uapi: pisp_be_config: Drop BIT() from uAPI media: stm32: dcmipp: correct error handling in dcmipp_create_subdevs media: atomisp: Fix spelling mistakes in sh_css_sp.c media: atomisp: Fix spelling mistake in ia_css_debug.c media: atomisp: Fix spelling mistake in hmm_bo.c media: atomisp: Fix spelling mistake in ia_css_eed1_8.host.c media: atomisp: Fix spelling mistake in sh_css_internal.h media: atomisp: Fix spelling mistake "pipline" -> "pipeline" media: atomisp: Remove unused GPIO related defines and APIs media: atomisp: Replace COMPILATION_ERROR_IF() by static_assert() media: atomisp: Clean up unused macros from math_support.h media: atomisp: csi2-bridge: Add DMI quirk for OV5693 on Xiaomi Mipad2 media: atomisp: Update TODO media: atomisp: Prefix firmware paths with "intel/ipu/" media: atomisp: Remove firmware_name module parameter ...
This commit is contained in:
Linus Torvalds
@@ -35,6 +35,6 @@ For more details see the file COPYING in the source distribution of Linux.
|
||||
max2175
|
||||
npcm-video
|
||||
omap3isp-uapi
|
||||
st-vgxy61
|
||||
thp7312
|
||||
uvcvideo
|
||||
vgxy61
|
||||
|
||||
@@ -971,8 +971,8 @@ FWHT Flags
|
||||
- ``horizontal_scale``
|
||||
- Horizontal scaling factor.
|
||||
* - __u8
|
||||
- ``vertical_scaling factor``
|
||||
- Vertical scale.
|
||||
- ``vertical_scale``
|
||||
- Vertical scaling factor.
|
||||
* - __u8
|
||||
- ``version``
|
||||
- Bitstream version.
|
||||
|
||||
@@ -1653,6 +1653,20 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
|
||||
Quantization parameter for a P frame for FWHT. Valid range: from 1
|
||||
to 31.
|
||||
|
||||
``V4L2_CID_MPEG_VIDEO_AVERAGE_QP (integer)``
|
||||
This read-only control returns the average QP value of the currently
|
||||
encoded frame. The value applies to the last dequeued capture buffer
|
||||
(VIDIOC_DQBUF). Its valid range depends on the encoding format and parameters.
|
||||
For H264, its valid range is from 0 to 51.
|
||||
For HEVC, its valid range is from 0 to 51 for 8 bit and
|
||||
from 0 to 63 for 10 bit.
|
||||
For H263 and MPEG4, its valid range is from 1 to 31.
|
||||
For VP8, its valid range is from 0 to 127.
|
||||
For VP9, its valid range is from 0 to 255.
|
||||
If the codec's MIN_QP and MAX_QP are set, then the QP will meet both requirements.
|
||||
Codecs need to always use the specified range, rather then a HW custom range.
|
||||
Applicable to encoders
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\normalsize
|
||||
|
||||
@@ -15,6 +15,7 @@ These formats are used for the :ref:`metadata` interface only.
|
||||
metafmt-d4xx
|
||||
metafmt-generic
|
||||
metafmt-intel-ipu3
|
||||
metafmt-pisp-be
|
||||
metafmt-rkisp1
|
||||
metafmt-uvc
|
||||
metafmt-vivid
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. _v4l2-meta-fmt-rpi-be-cfg:
|
||||
|
||||
************************
|
||||
V4L2_META_FMT_RPI_BE_CFG
|
||||
************************
|
||||
|
||||
Raspberry Pi PiSP Back End configuration format
|
||||
===============================================
|
||||
|
||||
The Raspberry Pi PiSP Back End memory-to-memory image signal processor is
|
||||
configured by userspace by providing a buffer of configuration parameters
|
||||
to the `pispbe-config` output video device node using the
|
||||
:c:type:`v4l2_meta_format` interface.
|
||||
|
||||
The PiSP Back End processes images in tiles, and its configuration requires
|
||||
specifying two different sets of parameters by populating the members of
|
||||
:c:type:`pisp_be_tiles_config` defined in the ``pisp_be_config.h`` header file.
|
||||
|
||||
The `Raspberry Pi PiSP technical specification
|
||||
<https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf>`_
|
||||
provide detailed description of the ISP back end configuration and programming
|
||||
model.
|
||||
|
||||
Global configuration data
|
||||
-------------------------
|
||||
|
||||
The global configuration data describe how the pixels in a particular image are
|
||||
to be processed and is therefore shared across all the tiles of the image. So
|
||||
for example, LSC (Lens Shading Correction) or Denoise parameters would be common
|
||||
across all tiles from the same frame.
|
||||
|
||||
Global configuration data are passed to the ISP by populating the member of
|
||||
:c:type:`pisp_be_config`.
|
||||
|
||||
Tile parameters
|
||||
---------------
|
||||
|
||||
As the ISP processes images in tiles, each set of tiles parameters describe how
|
||||
a single tile in an image is going to be processed. A single set of tile
|
||||
parameters consist of 160 bytes of data and to process a batch of tiles several
|
||||
sets of tiles parameters are required.
|
||||
|
||||
Tiles parameters are passed to the ISP by populating the member of
|
||||
``pisp_tile`` and the ``num_tiles`` fields of :c:type:`pisp_be_tiles_config`.
|
||||
|
||||
Raspberry Pi PiSP Back End uAPI data types
|
||||
==========================================
|
||||
|
||||
This section describes the data types exposed to userspace by the Raspberry Pi
|
||||
PiSP Back End. The section is informative only, for a detailed description of
|
||||
each field refer to the `Raspberry Pi PiSP technical specification
|
||||
<https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf>`_.
|
||||
|
||||
.. kernel-doc:: include/uapi/linux/media/raspberrypi/pisp_be_config.h
|
||||
@@ -20,6 +20,7 @@ orders. See also `the Wikipedia article on Bayer filter
|
||||
:maxdepth: 1
|
||||
|
||||
pixfmt-srggb8
|
||||
pixfmt-srggb8-pisp-comp
|
||||
pixfmt-srggb10
|
||||
pixfmt-srggb10p
|
||||
pixfmt-srggb10alaw8
|
||||
|
||||
@@ -996,6 +996,60 @@ arranged in little endian order.
|
||||
|
||||
\normalsize
|
||||
|
||||
16 Bits Per Component
|
||||
=====================
|
||||
|
||||
These formats store an RGB triplet in six bytes, with 16 bits per component
|
||||
stored in memory in little endian byte order. They are named based on the order
|
||||
of the RGB components as stored in memory. For instance, RGB48 stores R\
|
||||
:sub:`7:0` and R\ :sub:`15:8` in bytes 0 and 1 respectively. This differs from
|
||||
the DRM format nomenclature that instead uses the order of components as seen in
|
||||
the 48-bits little endian word.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\small
|
||||
|
||||
.. flat-table:: RGB Formats With 16 Bits Per Component
|
||||
:header-rows: 1
|
||||
|
||||
* - Identifier
|
||||
- Code
|
||||
- Byte 0
|
||||
- Byte 1
|
||||
- Byte 2
|
||||
- Byte 3
|
||||
- Byte 4
|
||||
- Byte 5
|
||||
|
||||
* .. _V4L2-PIX-FMT-BGR48:
|
||||
|
||||
- ``V4L2_PIX_FMT_BGR48``
|
||||
- 'BGR6'
|
||||
|
||||
- B\ :sub:`7-0`
|
||||
- B\ :sub:`15-8`
|
||||
- G\ :sub:`7-0`
|
||||
- G\ :sub:`15-8`
|
||||
- R\ :sub:`7-0`
|
||||
- R\ :sub:`15-8`
|
||||
|
||||
* .. _V4L2-PIX-FMT-RGB48:
|
||||
|
||||
- ``V4L2_PIX_FMT_RGB48``
|
||||
- 'RGB6'
|
||||
|
||||
- R\ :sub:`7-0`
|
||||
- R\ :sub:`15-8`
|
||||
- G\ :sub:`7-0`
|
||||
- G\ :sub:`15-8`
|
||||
- B\ :sub:`7-0`
|
||||
- B\ :sub:`15-8`
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\normalsize
|
||||
|
||||
Deprecated RGB Formats
|
||||
======================
|
||||
|
||||
|
||||
@@ -0,0 +1,74 @@
|
||||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
|
||||
.. _v4l2-pix-fmt-pisp-comp1-rggb:
|
||||
.. _v4l2-pix-fmt-pisp-comp1-grbg:
|
||||
.. _v4l2-pix-fmt-pisp-comp1-gbrg:
|
||||
.. _v4l2-pix-fmt-pisp-comp1-bggr:
|
||||
.. _v4l2-pix-fmt-pisp-comp1-mono:
|
||||
.. _v4l2-pix-fmt-pisp-comp2-rggb:
|
||||
.. _v4l2-pix-fmt-pisp-comp2-grbg:
|
||||
.. _v4l2-pix-fmt-pisp-comp2-gbrg:
|
||||
.. _v4l2-pix-fmt-pisp-comp2-bggr:
|
||||
.. _v4l2-pix-fmt-pisp-comp2-mono:
|
||||
|
||||
**************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
|
||||
V4L2_PIX_FMT_PISP_COMP1_RGGB ('PC1R'), V4L2_PIX_FMT_PISP_COMP1_GRBG ('PC1G'), V4L2_PIX_FMT_PISP_COMP1_GBRG ('PC1g'), V4L2_PIX_FMT_PISP_COMP1_BGGR ('PC1B), V4L2_PIX_FMT_PISP_COMP1_MONO ('PC1M'), V4L2_PIX_FMT_PISP_COMP2_RGGB ('PC2R'), V4L2_PIX_FMT_PISP_COMP2_GRBG ('PC2G'), V4L2_PIX_FMT_PISP_COMP2_GBRG ('PC2g'), V4L2_PIX_FMT_PISP_COMP2_BGGR ('PC2B), V4L2_PIX_FMT_PISP_COMP2_MONO ('PC2M')
|
||||
**************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
|
||||
|
||||
================================================
|
||||
Raspberry Pi PiSP compressed 8-bit Bayer formats
|
||||
================================================
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The Raspberry Pi ISP (PiSP) uses a family of three fixed-rate compressed Bayer
|
||||
formats. A black-level offset may be subtracted to improve compression
|
||||
efficiency; the nominal black level and amount of offset must be signalled out
|
||||
of band. Each scanline is padded to a multiple of 8 pixels wide, and each block
|
||||
of 8 horizontally-contiguous pixels is coded using 8 bytes.
|
||||
|
||||
Mode 1 uses a quantization and delta-based coding scheme which preserves up to
|
||||
12 significant bits. Mode 2 is a simple sqrt-like companding scheme with 6 PWL
|
||||
chords, preserving up to 12 significant bits. Mode 3 combines both companding
|
||||
(with 4 chords) and the delta scheme, preserving up to 14 significant bits.
|
||||
|
||||
The remainder of this description applies to Modes 1 and 3.
|
||||
|
||||
Each block of 8 pixels is separated into even and odd phases of 4 pixels,
|
||||
coded independently by 32-bit words at successive locations in memory.
|
||||
The two LS bits of each 32-bit word give its "quantization mode".
|
||||
|
||||
In quantization mode 0, the lowest 321 quantization levels are multiples of
|
||||
FSD/4096 and the remaining levels are successive multiples of FSD/2048.
|
||||
Quantization modes 1 and 2 use linear quantization with step sizes of
|
||||
FSD/1024 and FSD/512 respectively. Each of the four pixels is quantized
|
||||
independently, with rounding to the nearest level.
|
||||
In quantization mode 2 where the middle two samples have quantized values
|
||||
(q1,q2) both in the range [384..511], they are coded using 9 bits for q1
|
||||
followed by 7 bits for (q2 & 127). Otherwise, for quantization modes
|
||||
0, 1 and 2: a 9-bit field encodes MIN(q1,q2) which must be in the range
|
||||
[0..511] and a 7-bit field encodes (q2-q1+64) which must be in [0..127].
|
||||
|
||||
Each of the outer samples (q0,q3) is encoded using a 7-bit field based
|
||||
on its inner neighbour q1 or q2. In quantization mode 2 where the inner
|
||||
sample has a quantized value in the range [448..511], the field value is
|
||||
(q0-384). Otherwise for quantization modes 0, 1 and 2: The outer sample
|
||||
is encoded as (q0-MAX(0,q1-64)). q3 is likewise coded based on q2.
|
||||
Each of these values must be in the range [0..127]. All these fields
|
||||
of 2, 9, 7, 7, 7 bits respectively are packed in little-endian order
|
||||
to give a 32-bit word with LE byte order.
|
||||
|
||||
Quantization mode 3 has a "7.5-bit" escape, used when none of the above
|
||||
encodings will fit. Each pixel value is quantized to the nearest of 176
|
||||
levels, where the lowest 95 levels are multiples of FSD/256 and the
|
||||
remaining levels are multiples of FSD/128 (level 175 represents values
|
||||
very close to FSD and may require saturating arithmetic to decode).
|
||||
|
||||
Each pair of quantized pixels (q0,q1) or (q2,q3) is jointly coded
|
||||
by a 15-bit field: 2816*(q0>>4) + 16*q1 + (q0&15).
|
||||
Three fields of 2, 15, 15 bits are packed in LE order {15,15,2}.
|
||||
|
||||
An implementation of a software decoder of compressed formats is available
|
||||
in `Raspberry Pi camera applications code base
|
||||
<https://github.com/raspberrypi/rpicam-apps/blob/main/image/dng.cpp>`_.
|
||||
@@ -209,3 +209,7 @@ are often referred to as greyscale formats.
|
||||
For Y012 and Y12 formats, Y012 places its data in the 12 high bits, with
|
||||
padding zeros in the 4 low bits, in contrast to the Y12 format, which has
|
||||
its padding located in the most significant bits of the 16 bit word.
|
||||
|
||||
The 'P' variations of the Y10, Y12 and Y14 formats are packed according to
|
||||
the RAW10, RAW12 and RAW14 packing scheme as defined by the MIPI CSI-2
|
||||
specification.
|
||||
|
||||
Reference in New Issue
Block a user