Merge tag 'media/v6.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

Pull media updates from Mauro Carvalho Chehab:

 - v4l2 core:
     - sub-device framework routing improvements
     - NV12M tiled variants added to v4l2_format_info
     - some fixes at control handler freeing logic
     - fixed H264 SEPARATE_COLOUR_PLANE check

 - new staging driver: Intel IPU7 PCI

 - Rockchip video decoder driver got promoted from staging

 - iris: added HEVC/VP9 encoder/decoder support

 - vsp1: driver has gained Renesas VSPX support

 - uvc:
     - switched to vb2 ioctl helpers
     - added MSXU 1.5 metadata support

 - atomisp: GC0310 sensor driver cleanups in preparation for moving it
   out of staging

 - Lots of cleanup, fixes and improvements

* tag 'media/v6.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (310 commits)
  media: rkvdec: Unstage the driver
  media: rkvdec: Remove TODO file
  media: dt-bindings: rockchip: Add RK3576 Video Decoder bindings
  media: dt-bindings: rockchip: Document RK3588 Video Decoder bindings
  media: amphion: Support dmabuf and v4l2 buffer without binding
  media: verisilicon: postproc: 4K support
  media: v4l2: Add support for NV12M tiled variants to v4l2_format_info()
  media: uvcvideo: Use a count variable for meta_formats instead of 0 terminating
  media: uvcvideo: Auto-set UVC_QUIRK_MSXU_META
  media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5
  media: uvcvideo: Introduce dev->meta_formats
  media: Documentation: Add note about UVCH length field
  media: uvcvideo: Do not mark valid metadata as invalid
  media: uvcvideo: uvc_v4l2_unlocked_ioctl: Invert PM logic
  media: core: export v4l2_translate_cmd
  media: uvcvideo: Turn on the camera if V4L2_EVENT_SUB_FL_SEND_INITIAL
  media: uvcvideo: Remove stream->is_streaming field
  media: uvcvideo: Split uvc_stop_streaming()
  media: uvcvideo: Handle locks in uvc_queue_return_buffers
  media: uvcvideo: Use vb2 ioctl and fop helpers
  ...
This commit is contained in:
Linus Torvalds
2025-07-31 13:16:09 -07:00
314 changed files with 23149 additions and 4618 deletions

View File

@@ -41,6 +41,9 @@ error injection status::
# <op> rx-clear clear all rx error injections for <op>
# <op> tx-clear clear all tx error injections for <op>
#
# RX error injection settings:
# rx-no-low-drive do not generate low-drive pulses
#
# RX error injection:
# <op>[,<mode>] rx-nack NACK the message instead of sending an ACK
# <op>[,<mode>] rx-low-drive <bit> force a low-drive condition at this bit position
@@ -53,6 +56,10 @@ error injection status::
# tx-custom-low-usecs <usecs> define the 'low' time for the custom pulse
# tx-custom-high-usecs <usecs> define the 'high' time for the custom pulse
# tx-custom-pulse transmit the custom pulse once the bus is idle
# tx-glitch-low-usecs <usecs> define the 'low' time for the glitch pulse
# tx-glitch-high-usecs <usecs> define the 'high' time for the glitch pulse
# tx-glitch-falling-edge send the glitch pulse after every falling edge
# tx-glitch-rising-edge send the glitch pulse after every rising edge
#
# TX error injection:
# <op>[,<mode>] tx-no-eom don't set the EOM bit
@@ -193,6 +200,14 @@ Receive Messages
This does not work if the remote CEC transmitter has logical address
0 ('TV') since that will always win.
``rx-no-low-drive``
The receiver will ignore situations that would normally generate a
Low Drive pulse (3.6 ms). This is typically done if a spurious pulse is
detected when receiving a message, and it indicates to the transmitter that
the message has to be retransmitted since the receiver got confused.
Disabling this is useful to test how other CEC devices handle glitches
by ensuring we will not be the one that generates a Low Drive.
Transmit Messages
-----------------
@@ -327,3 +342,30 @@ Custom Pulses
``tx-custom-pulse``
Transmit a single custom pulse as soon as the CEC bus is idle.
Glitch Pulses
-------------
This emulates what happens if the signal on the CEC line is seeing spurious
pulses. Typically this happens after the falling or rising edge where there
is a short voltage fluctuation that, if the CEC hardware doesn't do
deglitching, can be seen as a spurious pulse and can cause a Low Drive
condition or corrupt data.
``tx-glitch-low-usecs <usecs>``
This defines the duration in microseconds that the glitch pulse pulls
the CEC line low. The default is 1 microsecond. The range is 0-100
microseconds. If 0, then no glitch pulse will be generated.
``tx-glitch-high-usecs <usecs>``
This defines the duration in microseconds that the glitch pulse keeps the
CEC line high (unless another CEC adapter pulls it low in that time).
The default is 1 microseconds. The range is 0-100 microseconds. If 0, then
no glitch pulse will be generated.The total period of the glitch pulse is
``tx-custom-low-usecs + tx-custom-high-usecs``.
``tx-glitch-falling-edge``
Send the glitch pulse right after the falling edge.
``tx-glitch-rising-edge``
Send the glitch pulse right after the rising edge.

View File

@@ -150,7 +150,7 @@ ITU-T.81
========
:title: ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continous-Tone Still Images --- Requirements and Guidelines"
:title: ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continuous-Tone Still Images --- Requirements and Guidelines"
:author: International Telecommunication Union (http://www.itu.int)

View File

@@ -48,7 +48,7 @@ capabilities, and they may support :ref:`control` ioctls.
The :ref:`video standard <standard>` ioctls provide information vital
to program a sliced VBI device, therefore must be supported.
.. _sliced-vbi-format-negotitation:
.. _sliced-vbi-format-negotiation:
Sliced VBI Format Negotiation
=============================
@@ -377,7 +377,7 @@ Sliced VBI Data in MPEG Streams
If a device can produce an MPEG output stream, it may be capable of
providing
:ref:`negotiated sliced VBI services <sliced-vbi-format-negotitation>`
:ref:`negotiated sliced VBI services <sliced-vbi-format-negotiation>`
as data embedded in the MPEG stream. Users or applications control this
sliced VBI data insertion with the
:ref:`V4L2_CID_MPEG_STREAM_VBI_FMT <v4l2-mpeg-stream-vbi-fmt>`

View File

@@ -64,17 +64,12 @@ FM_RX Control IDs
broadcasts speech. If the transmitter doesn't make this distinction,
then it will be set.
``V4L2_CID_TUNE_DEEMPHASIS``
(enum)
enum v4l2_deemphasis -
``V4L2_CID_TUNE_DEEMPHASIS (enum)``
Configures the de-emphasis value for reception. A de-emphasis filter
is applied to the broadcast to accentuate the high audio
frequencies. Depending on the region, a time constant of either 50
or 75 useconds is used. The enum v4l2_deemphasis defines possible
values for de-emphasis. Here they are:
or 75 microseconds is used. The enum v4l2_deemphasis defines possible
values for de-emphasis. They are:
.. flat-table::
:header-rows: 0

View File

@@ -104,7 +104,7 @@ FM_TX Control IDs
``V4L2_CID_AUDIO_LIMITER_RELEASE_TIME (integer)``
Sets the audio deviation limiter feature release time. Unit is in
useconds. Step and range are driver-specific.
microseconds. Step and range are driver-specific.
``V4L2_CID_AUDIO_LIMITER_DEVIATION (integer)``
Configures audio frequency deviation level in Hz. The range and step
@@ -121,16 +121,16 @@ FM_TX Control IDs
range and step are driver-specific.
``V4L2_CID_AUDIO_COMPRESSION_THRESHOLD (integer)``
Sets the threshold level for audio compression freature. It is a dB
Sets the threshold level for audio compression feature. It is a dB
value. The range and step are driver-specific.
``V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME (integer)``
Sets the attack time for audio compression feature. It is a useconds
Sets the attack time for audio compression feature. It is a microseconds
value. The range and step are driver-specific.
``V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME (integer)``
Sets the release time for audio compression feature. It is a
useconds value. The range and step are driver-specific.
microseconds value. The range and step are driver-specific.
``V4L2_CID_PILOT_TONE_ENABLED (boolean)``
Enables or disables the pilot tone generation feature.
@@ -143,17 +143,12 @@ FM_TX Control IDs
Configures pilot tone frequency value. Unit is in Hz. The range and
step are driver-specific.
``V4L2_CID_TUNE_PREEMPHASIS``
(enum)
enum v4l2_preemphasis -
``V4L2_CID_TUNE_PREEMPHASIS (enum)``
Configures the pre-emphasis value for broadcasting. A pre-emphasis
filter is applied to the broadcast to accentuate the high audio
frequencies. Depending on the region, a time constant of either 50
or 75 useconds is used. The enum v4l2_preemphasis defines possible
values for pre-emphasis. Here they are:
or 75 microseconds is used. The enum v4l2_preemphasis defines possible
values for pre-emphasis. They are:
.. flat-table::
:header-rows: 0
@@ -166,8 +161,6 @@ enum v4l2_preemphasis -
* - ``V4L2_PREEMPHASIS_75_uS``
- A pre-emphasis of 75 uS is used.
``V4L2_CID_TUNE_POWER_LEVEL (integer)``
Sets the output power level for signal transmission. Unit is in
dBuV. Range and step are driver-specific.

View File

@@ -20,6 +20,7 @@ These formats are used for the :ref:`metadata` interface only.
metafmt-pisp-fe
metafmt-rkisp1
metafmt-uvc
metafmt-uvc-msxu-1-5
metafmt-vivid
metafmt-vsp1-hgo
metafmt-vsp1-hgt

View File

@@ -0,0 +1,23 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _v4l2-meta-fmt-uvc-msxu-1-5:
***********************************
V4L2_META_FMT_UVC_MSXU_1_5 ('UVCM')
***********************************
Microsoft(R)'s UVC Payload Metadata.
Description
===========
V4L2_META_FMT_UVC_MSXU_1_5 buffers follow the metadata buffer layout of
V4L2_META_FMT_UVC with the only difference that it includes all the UVC
metadata in the `buffer[]` field, not just the first 2-12 bytes.
The metadata format follows the specification from Microsoft(R) [1].
.. _1:
[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-extensions-1-5

View File

@@ -44,7 +44,9 @@ Each individual block contains the following fields:
them
* - :cspan:`1` *The rest is an exact copy of the UVC payload header:*
* - __u8 length;
- length of the rest of the block, including this field
- length of the rest of the block, including this field. Please note that
regardless of this value, for V4L2_META_FMT_UVC the kernel will never
copy more than 2-12 bytes.
* - __u8 flags;
- Flags, indicating presence of other standard UVC fields
* - __u8 buf[];

View File

@@ -19,6 +19,7 @@ orders. See also `the Wikipedia article on Bayer filter
.. toctree::
:maxdepth: 1
pixfmt-rawnn-cru
pixfmt-srggb8
pixfmt-srggb8-pisp-comp
pixfmt-srggb10

View File

@@ -0,0 +1,143 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _v4l2-pix-fmt-raw-cru10:
.. _v4l2-pix-fmt-raw-cru12:
.. _v4l2-pix-fmt-raw-cru14:
.. _v4l2-pix-fmt-raw-cru20:
**********************************************************************************************************************************
V4L2_PIX_FMT_RAW_CRU10 ('CR10'), V4L2_PIX_FMT_RAW_CRU12 ('CR12'), V4L2_PIX_FMT_RAW_CRU14 ('CR14'), V4L2_PIX_FMT_RAW_CRU20 ('CR20')
**********************************************************************************************************************************
===============================================================
Renesas RZ/V2H Camera Receiver Unit 64-bit packed pixel formats
===============================================================
| V4L2_PIX_FMT_RAW_CRU10 (CR10)
| V4L2_PIX_FMT_RAW_CRU12 (CR12)
| V4L2_PIX_FMT_RAW_CRU14 (CR14)
| V4L2_PIX_FMT_RAW_CRU20 (CR20)
Description
===========
These pixel formats are some of the RAW outputs for the Camera Receiver Unit in
the Renesas RZ/V2H SoC. They are raw formats which pack pixels contiguously into
64-bit units, with the 4 or 8 most significant bits padded.
**Byte Order**
.. flat-table:: RAW formats
:header-rows: 2
:stub-columns: 0
:widths: 36 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
:fill-cells:
* - :rspan:`1` Pixel Format Code
- :cspan:`63` Data organization
* - 63
- 62
- 61
- 60
- 59
- 58
- 57
- 56
- 55
- 54
- 53
- 52
- 51
- 50
- 49
- 48
- 47
- 46
- 45
- 44
- 43
- 42
- 41
- 40
- 39
- 38
- 37
- 36
- 35
- 34
- 33
- 32
- 31
- 30
- 29
- 28
- 27
- 26
- 25
- 24
- 23
- 22
- 21
- 20
- 19
- 18
- 17
- 16
- 15
- 14
- 13
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2
- 1
- 0
* - V4L2_PIX_FMT_RAW_CRU10
- 0
- 0
- 0
- 0
- :cspan:`9` P5
- :cspan:`9` P4
- :cspan:`9` P3
- :cspan:`9` P2
- :cspan:`9` P1
- :cspan:`9` P0
* - V4L2_PIX_FMT_RAW_CRU12
- 0
- 0
- 0
- 0
- :cspan:`11` P4
- :cspan:`11` P3
- :cspan:`11` P2
- :cspan:`11` P1
- :cspan:`11` P0
* - V4L2_PIX_FMT_RAW_CRU14
- 0
- 0
- 0
- 0
- 0
- 0
- 0
- 0
- :cspan:`13` P3
- :cspan:`13` P2
- :cspan:`13` P1
- :cspan:`13` P0
* - V4L2_PIX_FMT_RAW_CRU20
- 0
- 0
- 0
- 0
- :cspan:`19` P2
- :cspan:`19` P1
- :cspan:`19` P0

View File

@@ -6,7 +6,7 @@
.. _v4l2-pix-fmt-sgrbg12p:
*******************************************************************************************************************************
V4L2_PIX_FMT_SRGGB12P ('pRCC'), V4L2_PIX_FMT_SGRBG12P ('pgCC'), V4L2_PIX_FMT_SGBRG12P ('pGCC'), V4L2_PIX_FMT_SBGGR12P ('pBCC'),
V4L2_PIX_FMT_SRGGB12P ('pRCC'), V4L2_PIX_FMT_SGRBG12P ('pgCC'), V4L2_PIX_FMT_SGBRG12P ('pGCC'), V4L2_PIX_FMT_SBGGR12P ('pBCC')
*******************************************************************************************************************************
@@ -20,7 +20,7 @@ Description
These four pixel formats are packed raw sRGB / Bayer formats with 12
bits per colour. Every two consecutive samples are packed into three
bytes. Each of the first two bytes contain the 8 high order bits of
the pixels, and the third byte contains the four least significants
the pixels, and the third byte contains the four least significant
bits of each pixel, in the same order.
Each n-pixel row contains n/2 green samples and n/2 blue or red

View File

@@ -24,7 +24,7 @@ These four pixel formats are packed raw sRGB / Bayer formats with 14
bits per colour. Every four consecutive samples are packed into seven
bytes. Each of the first four bytes contain the eight high order bits
of the pixels, and the three following bytes contains the six least
significants bits of each pixel, in the same order.
significant bits of each pixel, in the same order.
Each n-pixel row contains n/2 green samples and n/2 blue or red samples,
with alternating green-red and green-blue rows. They are conventionally