mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2026-07-16 17:57:38 -04:00
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:
@@ -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.
|
||||
|
||||
@@ -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)
|
||||
|
||||
|
||||
@@ -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>`
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
@@ -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[];
|
||||
|
||||
@@ -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
|
||||
|
||||
143
Documentation/userspace-api/media/v4l/pixfmt-rawnn-cru.rst
Normal file
143
Documentation/userspace-api/media/v4l/pixfmt-rawnn-cru.rst
Normal 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
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user