mirror of
https://github.com/Dasharo/linux.git
synced 2026-03-06 15:25:10 -08:00
Merge tag 'media/v6.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab: - New CEC driver: Extron DA HD 4K Plus - Lots of driver fixes, cleanups and improvements * tag 'media/v6.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (179 commits) media: atomisp: Use clamp() in ia_css_eed1_8_vmem_encode() media: atomisp: Fix eed1_8 code assigning signed values to an unsigned variable media: atomisp: set lock before calling vb2_queue_init() media: atomisp: Improve binary finding debug logging media: atomisp: Drop dev_dbg() calls from hmm_[alloc|free]() media: atomisp: csi2-bridge: Add DMI quirk for t4ka3 on Xiaomi Mipad2 media: atomisp: add missing wait_prepare/finish ops media: atomisp: Remove unused declaration media: atomisp: use clamp() in compute_coring() media: atomisp: use clamp() in ia_css_eed1_8_encode() media: atomisp: Simplify ia_css_pipe_create_cas_scaler_desc_single_output() media: atomisp: Replace rarely used macro from math_support.h media: atomisp: Remove duplicated leftover, i.e. sh_css_dvs_info.h media: atomisp: bnr: fix trailing statement media: atomisp: move trailing */ to separate lines media: atomisp: move trailing statement to next line. media: atomisp: Fix trailing statement in ia_css_de.host.c media: atomisp: Fix spelling mistakes in atomisp.h media: atomisp: Fix spelling mistakes in atomisp_platform.h media: atomisp: Fix spelling mistake in csi_rx_public.h ...
This commit is contained in:
Linus Torvalds
@@ -42,10 +42,14 @@ dongles):
|
||||
``persistent_config``: by default this is off, but when set to 1 the driver
|
||||
will store the current settings to the device's internal eeprom and restore
|
||||
it the next time the device is connected to the USB port.
|
||||
|
||||
- RainShadow Tech. Note: this driver does not support the persistent_config
|
||||
module option of the Pulse-Eight driver. The hardware supports it, but I
|
||||
have no plans to add this feature. But I accept patches :-)
|
||||
|
||||
- Extron DA HD 4K PLUS HDMI Distribution Amplifier. See
|
||||
:ref:`extron_da_hd_4k_plus` for more information.
|
||||
|
||||
Miscellaneous:
|
||||
|
||||
- vivid: emulates a CEC receiver and CEC transmitter.
|
||||
@@ -378,3 +382,86 @@ it later using ``--analyze-pin``.
|
||||
|
||||
You can also use this as a full-fledged CEC device by configuring it
|
||||
using ``cec-ctl --tv -p0.0.0.0`` or ``cec-ctl --playback -p1.0.0.0``.
|
||||
|
||||
.. _extron_da_hd_4k_plus:
|
||||
|
||||
Extron DA HD 4K PLUS CEC Adapter driver
|
||||
=======================================
|
||||
|
||||
This driver is for the Extron DA HD 4K PLUS series of HDMI Distribution
|
||||
Amplifiers: https://www.extron.com/product/dahd4kplusseries
|
||||
|
||||
The 2, 4 and 6 port models are supported.
|
||||
|
||||
Firmware version 1.02.0001 or higher is required.
|
||||
|
||||
Note that older Extron hardware revisions have a problem with the CEC voltage,
|
||||
which may mean that CEC will not work. This is fixed in hardware revisions
|
||||
E34814 and up.
|
||||
|
||||
The CEC support has two modes: the first is a manual mode where userspace has
|
||||
to manually control CEC for the HDMI Input and all HDMI Outputs. While this gives
|
||||
full control, it is also complicated.
|
||||
|
||||
The second mode is an automatic mode, which is selected if the module option
|
||||
``vendor_id`` is set. In that case the driver controls CEC and CEC messages
|
||||
received in the input will be distributed to the outputs. It is still possible
|
||||
to use the /dev/cecX devices to talk to the connected devices directly, but it is
|
||||
the driver that configures everything and deals with things like Hotplug Detect
|
||||
changes.
|
||||
|
||||
The driver also takes care of the EDIDs: /dev/videoX devices are created to
|
||||
read the EDIDs and (for the HDMI Input port) to set the EDID.
|
||||
|
||||
By default userspace is responsible to set the EDID for the HDMI Input
|
||||
according to the EDIDs of the connected displays. But if the ``manufacturer_name``
|
||||
module option is set, then the driver will take care of setting the EDID
|
||||
of the HDMI Input based on the supported resolutions of the connected displays.
|
||||
Currently the driver only supports resolutions 1080p60 and 4kp60: if all connected
|
||||
displays support 4kp60, then it will advertise 4kp60 on the HDMI input, otherwise
|
||||
it will fall back to an EDID that just reports 1080p60.
|
||||
|
||||
The status of the Extron is reported in ``/sys/kernel/debug/cec/cecX/status``.
|
||||
|
||||
The extron-da-hd-4k-plus driver implements the following module options:
|
||||
|
||||
``debug``
|
||||
---------
|
||||
|
||||
If set to 1, then all serial port traffic is shown.
|
||||
|
||||
``vendor_id``
|
||||
-------------
|
||||
|
||||
The CEC Vendor ID to report to connected displays.
|
||||
|
||||
If set, then the driver will take care of distributing CEC messages received
|
||||
on the input to the HDMI outputs. This is done for the following CEC messages:
|
||||
|
||||
- <Standby>
|
||||
- <Image View On> and <Text View On>
|
||||
- <Give Device Power Status>
|
||||
- <Set System Audio Mode>
|
||||
- <Request Current Latency>
|
||||
|
||||
If not set, then userspace is responsible for this, and it will have to
|
||||
configure the CEC devices for HDMI Input and the HDMI Outputs manually.
|
||||
|
||||
``manufacturer_name``
|
||||
---------------------
|
||||
|
||||
A three character manufacturer name that is used in the EDID for the HDMI
|
||||
Input. If not set, then userspace is reponsible for configuring an EDID.
|
||||
If set, then the driver will update the EDID automatically based on the
|
||||
resolutions supported by the connected displays, and it will not be possible
|
||||
anymore to manually set the EDID for the HDMI Input.
|
||||
|
||||
``hpd_never_low``
|
||||
-----------------
|
||||
|
||||
If set, then the Hotplug Detect pin of the HDMI Input will always be high,
|
||||
even if nothing is connected to the HDMI Outputs. If not set (the default)
|
||||
then the Hotplug Detect pin of the HDMI input will go low if all the detected
|
||||
Hotplug Detect pins of the HDMI Outputs are also low.
|
||||
|
||||
This option may be changed dynamically.
|
||||
|
||||
@@ -227,8 +227,13 @@ Common FPDL3/GMSL output parameters
|
||||
open.*
|
||||
|
||||
**frame_rate** (RW):
|
||||
Output video frame rate in frames per second. The default frame rate is
|
||||
60Hz.
|
||||
Output video signal frame rate limit in frames per second. Due to
|
||||
the limited output pixel clock steps, the card can not always generate
|
||||
a frame rate perfectly matching the value required by the connected display.
|
||||
Using this parameter one can limit the frame rate by "crippling" the signal
|
||||
so that the lines are not equal (the porches of the last line differ) but
|
||||
the signal appears like having the exact frame rate to the connected display.
|
||||
The default frame rate limit is 60Hz.
|
||||
|
||||
**hsync_polarity** (RW):
|
||||
HSYNC signal polarity.
|
||||
@@ -253,33 +258,33 @@ Common FPDL3/GMSL output parameters
|
||||
and there is a non-linear stepping between two consecutive allowed
|
||||
frequencies. The driver finds the nearest allowed frequency to the given
|
||||
value and sets it. When reading this property, you get the exact
|
||||
frequency set by the driver. The default frequency is 70000kHz.
|
||||
frequency set by the driver. The default frequency is 61150kHz.
|
||||
|
||||
*Note: This parameter can not be changed while the output v4l2 device is
|
||||
open.*
|
||||
|
||||
**hsync_width** (RW):
|
||||
Width of the HSYNC signal in pixels. The default value is 16.
|
||||
Width of the HSYNC signal in pixels. The default value is 40.
|
||||
|
||||
**vsync_width** (RW):
|
||||
Width of the VSYNC signal in video lines. The default value is 2.
|
||||
Width of the VSYNC signal in video lines. The default value is 20.
|
||||
|
||||
**hback_porch** (RW):
|
||||
Number of PCLK pulses between deassertion of the HSYNC signal and the first
|
||||
valid pixel in the video line (marked by DE=1). The default value is 32.
|
||||
valid pixel in the video line (marked by DE=1). The default value is 50.
|
||||
|
||||
**hfront_porch** (RW):
|
||||
Number of PCLK pulses between the end of the last valid pixel in the video
|
||||
line (marked by DE=1) and assertion of the HSYNC signal. The default value
|
||||
is 32.
|
||||
is 50.
|
||||
|
||||
**vback_porch** (RW):
|
||||
Number of video lines between deassertion of the VSYNC signal and the video
|
||||
line with the first valid pixel (marked by DE=1). The default value is 2.
|
||||
line with the first valid pixel (marked by DE=1). The default value is 31.
|
||||
|
||||
**vfront_porch** (RW):
|
||||
Number of video lines between the end of the last valid pixel line (marked
|
||||
by DE=1) and assertion of the VSYNC signal. The default value is 2.
|
||||
by DE=1) and assertion of the VSYNC signal. The default value is 30.
|
||||
|
||||
FPDL3 specific input parameters
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -114,11 +114,18 @@ to be applied to the hardware during a video stream, allowing userspace
|
||||
to dynamically modify values such as black level, cross talk corrections
|
||||
and others.
|
||||
|
||||
The buffer format is defined by struct :c:type:`rkisp1_params_cfg`, and
|
||||
userspace should set
|
||||
The ISP driver supports two different parameters configuration methods, the
|
||||
`fixed parameters format` or the `extensible parameters format`.
|
||||
|
||||
When using the `fixed parameters` method the buffer format is defined by struct
|
||||
:c:type:`rkisp1_params_cfg`, and userspace should set
|
||||
:ref:`V4L2_META_FMT_RK_ISP1_PARAMS <v4l2-meta-fmt-rk-isp1-params>` as the
|
||||
dataformat.
|
||||
|
||||
When using the `extensible parameters` method the buffer format is defined by
|
||||
struct :c:type:`rkisp1_ext_params_cfg`, and userspace should set
|
||||
:ref:`V4L2_META_FMT_RK_ISP1_EXT_PARAMS <v4l2-meta-fmt-rk-isp1-ext-params>` as
|
||||
the dataformat.
|
||||
|
||||
Capturing Video Frames Example
|
||||
==============================
|
||||
|
||||
@@ -1343,7 +1343,7 @@ Some Future Improvements
|
||||
Just as a reminder and in no particular order:
|
||||
|
||||
- Add a virtual alsa driver to test audio
|
||||
- Add virtual sub-devices and media controller support
|
||||
- Add virtual sub-devices
|
||||
- Some support for testing compressed video
|
||||
- Add support to loop raw VBI output to raw VBI input
|
||||
- Add support to loop teletext sliced VBI output to VBI input
|
||||
@@ -1358,4 +1358,4 @@ Just as a reminder and in no particular order:
|
||||
- Make a thread for the RDS generation, that would help in particular for the
|
||||
"Controls" RDS Rx I/O Mode as the read-only RDS controls could be updated
|
||||
in real-time.
|
||||
- Changing the EDID should cause hotplug detect emulation to happen.
|
||||
- Changing the EDID doesn't wait 100 ms before setting the HPD signal.
|
||||
|
||||
@@ -31,7 +31,8 @@ properties:
|
||||
- items:
|
||||
- enum:
|
||||
- amlogic,gxbb-vdec # GXBB (S905)
|
||||
- amlogic,gxl-vdec # GXL (S905X, S905D)
|
||||
- amlogic,gxl-vdec # GXL (S905D, S905W, S905X, S905Y)
|
||||
- amlogic,gxlx-vdec # GXLX (S905L)
|
||||
- amlogic,gxm-vdec # GXM (S912)
|
||||
- const: amlogic,gx-vdec
|
||||
- enum:
|
||||
|
||||
107
Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml
Normal file
107
Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml
Normal file
@@ -0,0 +1,107 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (c) 2023-2024 Linaro Ltd.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/ovti,og01a1b.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: OmniVision OG01A1B Image Sensor
|
||||
|
||||
maintainers:
|
||||
- Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
|
||||
|
||||
description:
|
||||
The OmniVision OG01A1B is black and white CMOS 1.3 Megapixel (1280x1024)
|
||||
image sensor controlled over an I2C-compatible SCCB bus.
|
||||
The sensor transmits images on a MIPI CSI-2 output interface with one or
|
||||
two data lanes.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/media/video-interface-devices.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: ovti,og01a1b
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
description: Active low GPIO connected to XSHUTDOWN pad of the sensor.
|
||||
maxItems: 1
|
||||
|
||||
strobe-gpios:
|
||||
description: Input GPIO connected to strobe pad of the sensor.
|
||||
maxItems: 1
|
||||
|
||||
avdd-supply:
|
||||
description: Analogue circuit voltage supply.
|
||||
|
||||
dovdd-supply:
|
||||
description: I/O circuit voltage supply.
|
||||
|
||||
dvdd-supply:
|
||||
description: Digital circuit voltage supply.
|
||||
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
additionalProperties: false
|
||||
description:
|
||||
Output port node, single endpoint describing the CSI-2 transmitter.
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
data-lanes:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
items:
|
||||
enum: [1, 2]
|
||||
|
||||
link-frequencies: true
|
||||
|
||||
required:
|
||||
- data-lanes
|
||||
- link-frequencies
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- port
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
sensor@60 {
|
||||
compatible = "ovti,og01a1b";
|
||||
reg = <0x60>;
|
||||
clocks = <&clk 0>;
|
||||
reset-gpios = <&gpio 117 GPIO_ACTIVE_LOW>;
|
||||
avdd-supply = <&vreg_3v3>;
|
||||
dovdd-supply = <&vreg_1p8>;
|
||||
dvdd-supply = <&vreg_1p2>;
|
||||
|
||||
port {
|
||||
og01a1b_ep: endpoint {
|
||||
remote-endpoint = <&csiphy_ep>;
|
||||
data-lanes = <1 2>;
|
||||
link-frequencies = /bits/ 64 <500000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
@@ -75,6 +75,8 @@ additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
@@ -92,6 +94,8 @@ examples:
|
||||
ovdd-supply = <&camera_vddo_1v8>;
|
||||
dvdd-supply = <&camera_vddd_1v2>;
|
||||
|
||||
reset-gpios = <&gpio 50 GPIO_ACTIVE_LOW>;
|
||||
|
||||
port {
|
||||
imx335: endpoint {
|
||||
remote-endpoint = <&cam>;
|
||||
|
||||
@@ -43,6 +43,7 @@ properties:
|
||||
- const: vcodec_bus
|
||||
|
||||
iommus:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
interconnects:
|
||||
|
||||
@@ -27,6 +27,7 @@ properties:
|
||||
- renesas,fcpf # FCP for FDP
|
||||
- items:
|
||||
- enum:
|
||||
- renesas,r9a07g043u-fcpvd # RZ/G2UL
|
||||
- renesas,r9a07g044-fcpvd # RZ/G2{L,LC}
|
||||
- renesas,r9a07g054-fcpvd # RZ/V2L
|
||||
- const: renesas,fcpv # Generic FCP for VSP fallback
|
||||
@@ -62,6 +63,7 @@ allOf:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- renesas,r9a07g043u-fcpvd
|
||||
- renesas,r9a07g044-fcpvd
|
||||
- renesas,r9a07g054-fcpvd
|
||||
then:
|
||||
|
||||
@@ -52,8 +52,12 @@ properties:
|
||||
- renesas,vin-r8a77980 # R-Car V3H
|
||||
- renesas,vin-r8a77990 # R-Car E3
|
||||
- renesas,vin-r8a77995 # R-Car D3
|
||||
- items:
|
||||
- enum:
|
||||
- renesas,vin-r8a779a0 # R-Car V3U
|
||||
- renesas,vin-r8a779g0 # R-Car V4H
|
||||
- renesas,vin-r8a779h0 # R-Car V4M
|
||||
- const: renesas,rcar-gen4-vin # Generic R-Car Gen4
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -23,6 +23,7 @@ properties:
|
||||
- renesas,vsp2 # R-Car Gen3 and RZ/G2
|
||||
- items:
|
||||
- enum:
|
||||
- renesas,r9a07g043u-vsp2 # RZ/G2UL
|
||||
- renesas,r9a07g054-vsp2 # RZ/V2L
|
||||
- const: renesas,r9a07g044-vsp2 # RZ/G2L fallback
|
||||
|
||||
|
||||
@@ -17,6 +17,7 @@ properties:
|
||||
compatible:
|
||||
enum:
|
||||
- rockchip,rk3568-vepu
|
||||
- rockchip,rk3588-vepu121
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -26,11 +26,16 @@ properties:
|
||||
- rockchip,rk3568-vpu
|
||||
- rockchip,rk3588-av1-vpu
|
||||
- items:
|
||||
- const: rockchip,rk3188-vpu
|
||||
- enum:
|
||||
- rockchip,rk3128-vpu
|
||||
- rockchip,rk3188-vpu
|
||||
- const: rockchip,rk3066-vpu
|
||||
- items:
|
||||
- const: rockchip,rk3228-vpu
|
||||
- const: rockchip,rk3399-vpu
|
||||
- items:
|
||||
- const: rockchip,rk3588-vpu121
|
||||
- const: rockchip,rk3568-vpu
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -144,7 +144,8 @@ valid values are described at :c:func:`media_create_pad_link()` and
|
||||
Graph traversal
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
The media framework provides APIs to iterate over entities in a graph.
|
||||
The media framework provides APIs to traverse media graphs, locating connected
|
||||
entities and links.
|
||||
|
||||
To iterate over all entities belonging to a media device, drivers can use
|
||||
the media_device_for_each_entity macro, defined in
|
||||
@@ -159,31 +160,6 @@ the media_device_for_each_entity macro, defined in
|
||||
...
|
||||
}
|
||||
|
||||
Drivers might also need to iterate over all entities in a graph that can be
|
||||
reached only through enabled links starting at a given entity. The media
|
||||
framework provides a depth-first graph traversal API for that purpose.
|
||||
|
||||
.. note::
|
||||
|
||||
Graphs with cycles (whether directed or undirected) are **NOT**
|
||||
supported by the graph traversal API. To prevent infinite loops, the graph
|
||||
traversal code limits the maximum depth to ``MEDIA_ENTITY_ENUM_MAX_DEPTH``,
|
||||
currently defined as 16.
|
||||
|
||||
Drivers initiate a graph traversal by calling
|
||||
:c:func:`media_graph_walk_start()`
|
||||
|
||||
The graph structure, provided by the caller, is initialized to start graph
|
||||
traversal at the given entity.
|
||||
|
||||
Drivers can then retrieve the next entity by calling
|
||||
:c:func:`media_graph_walk_next()`
|
||||
|
||||
When the graph traversal is complete the function will return ``NULL``.
|
||||
|
||||
Graph traversal can be interrupted at any moment. No cleanup function call
|
||||
is required and the graph structure can be freed normally.
|
||||
|
||||
Helper functions can be used to find a link between two given pads, or a pad
|
||||
connected to another pad through an enabled link
|
||||
(:c:func:`media_entity_find_link()`, :c:func:`media_pad_remote_pad_first()`,
|
||||
@@ -276,6 +252,45 @@ Subsystems should facilitate link validation by providing subsystem specific
|
||||
helper functions to provide easy access for commonly needed information, and
|
||||
in the end provide a way to use driver-specific callbacks.
|
||||
|
||||
Pipeline traversal
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once a pipeline has been constructed with :c:func:`media_pipeline_start()`,
|
||||
drivers can iterate over entities or pads in the pipeline with the
|
||||
:c:macro:´media_pipeline_for_each_entity` and
|
||||
:c:macro:´media_pipeline_for_each_pad` macros. Iterating over pads is
|
||||
straightforward:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
media_pipeline_pad_iter iter;
|
||||
struct media_pad *pad;
|
||||
|
||||
media_pipeline_for_each_pad(pipe, &iter, pad) {
|
||||
/* 'pad' will point to each pad in turn */
|
||||
...
|
||||
}
|
||||
|
||||
To iterate over entities, the iterator needs to be initialized and cleaned up
|
||||
as an additional steps:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
media_pipeline_entity_iter iter;
|
||||
struct media_entity *entity;
|
||||
int ret;
|
||||
|
||||
ret = media_pipeline_entity_iter_init(pipe, &iter);
|
||||
if (ret)
|
||||
...;
|
||||
|
||||
media_pipeline_for_each_entity(pipe, &iter, entity) {
|
||||
/* 'entity' will point to each entity in turn */
|
||||
...
|
||||
}
|
||||
|
||||
media_pipeline_entity_iter_cleanup(&iter);
|
||||
|
||||
Media Controller Device Allocator API
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
@@ -137,6 +137,12 @@ returns the information to the application. The ioctl never fails.
|
||||
- 0x00000100
|
||||
- If this capability is set, then :ref:`CEC_ADAP_G_CONNECTOR_INFO` can
|
||||
be used.
|
||||
* .. _`CEC-CAP-REPLY-VENDOR-ID`:
|
||||
|
||||
- ``CEC_CAP_REPLY_VENDOR_ID``
|
||||
- 0x00000200
|
||||
- If this capability is set, then
|
||||
:ref:`CEC_MSG_FL_REPLY_VENDOR_ID <cec-msg-flags>` can be used.
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
@@ -232,6 +232,21 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
|
||||
capability. If that is not set, then the ``EPERM`` error code is
|
||||
returned.
|
||||
|
||||
* .. _`CEC-MSG-FL-REPLY-VENDOR-ID`:
|
||||
|
||||
- ``CEC_MSG_FL_REPLY_VENDOR_ID``
|
||||
- 4
|
||||
- This flag is only available if the ``CEC_CAP_REPLY_VENDOR_ID`` capability
|
||||
is set. If this flag is set, then the reply is expected to consist of
|
||||
the ``CEC_MSG_VENDOR_COMMAND_WITH_ID`` opcode followed by the Vendor ID
|
||||
(in bytes 1-4 of the message), followed by the ``struct cec_msg``
|
||||
``reply`` field.
|
||||
|
||||
Note that this assumes that the byte after the Vendor ID is a
|
||||
vendor-specific opcode.
|
||||
|
||||
This flag makes it easier to wait for replies to vendor commands.
|
||||
|
||||
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{10.8cm}|
|
||||
|
||||
.. _cec-tx-status:
|
||||
|
||||
@@ -334,6 +334,17 @@ VESA DMT
|
||||
|
||||
:author: Video Electronics Standards Association (http://www.vesa.org)
|
||||
|
||||
.. _vesaeddc:
|
||||
|
||||
E-DDC
|
||||
=====
|
||||
|
||||
|
||||
:title: VESA Enhanced Display Data Channel (E-DDC) Standard
|
||||
:subtitle: Version 1.3
|
||||
|
||||
:author: Video Electronics Standards Association (http://www.vesa.org)
|
||||
|
||||
.. _vesaedid:
|
||||
|
||||
EDID
|
||||
|
||||
@@ -694,41 +694,6 @@ enum v4l2_memory
|
||||
- 4
|
||||
- The buffer is used for :ref:`DMA shared buffer <dmabuf>` I/O.
|
||||
|
||||
.. _memory-flags:
|
||||
|
||||
Memory Consistency Flags
|
||||
------------------------
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\small
|
||||
|
||||
.. tabularcolumns:: |p{7.0cm}|p{2.1cm}|p{8.4cm}|
|
||||
|
||||
.. cssclass:: longtable
|
||||
|
||||
.. flat-table::
|
||||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
:widths: 3 1 4
|
||||
|
||||
* .. _`V4L2-MEMORY-FLAG-NON-COHERENT`:
|
||||
|
||||
- ``V4L2_MEMORY_FLAG_NON_COHERENT``
|
||||
- 0x00000001
|
||||
- A buffer is allocated either in coherent (it will be automatically
|
||||
coherent between the CPU and the bus) or non-coherent memory. The
|
||||
latter can provide performance gains, for instance the CPU cache
|
||||
sync/flush operations can be avoided if the buffer is accessed by the
|
||||
corresponding device only and the CPU does not read/write to/from that
|
||||
buffer. However, this requires extra care from the driver -- it must
|
||||
guarantee memory consistency by issuing a cache flush/sync when
|
||||
consistency is needed. If this flag is set V4L2 will attempt to
|
||||
allocate the buffer in non-coherent memory. The flag takes effect
|
||||
only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the
|
||||
queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
|
||||
<V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\normalsize
|
||||
|
||||
@@ -333,7 +333,7 @@ file: media/v4l/capture.c
|
||||
if (-1 == xioctl(fd, VIDIOC_REQBUFS, &req)) {
|
||||
if (EINVAL == errno) {
|
||||
fprintf(stderr, "%s does not support "
|
||||
"memory mappingn", dev_name);
|
||||
"memory mapping\n", dev_name);
|
||||
exit(EXIT_FAILURE);
|
||||
} else {
|
||||
errno_exit("VIDIOC_REQBUFS");
|
||||
@@ -391,7 +391,7 @@ file: media/v4l/capture.c
|
||||
if (-1 == xioctl(fd, VIDIOC_REQBUFS, &req)) {
|
||||
if (EINVAL == errno) {
|
||||
fprintf(stderr, "%s does not support "
|
||||
"user pointer i/on", dev_name);
|
||||
"user pointer i/o\n", dev_name);
|
||||
exit(EXIT_FAILURE);
|
||||
} else {
|
||||
errno_exit("VIDIOC_REQBUFS");
|
||||
@@ -547,7 +547,7 @@ file: media/v4l/capture.c
|
||||
}
|
||||
|
||||
if (!S_ISCHR(st.st_mode)) {
|
||||
fprintf(stderr, "%s is no devicen", dev_name);
|
||||
fprintf(stderr, "%s is no device\n", dev_name);
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
|
||||
@@ -2993,7 +2993,11 @@ This structure contains all loop filter related parameters. See sections
|
||||
- Applications and drivers must set this to zero.
|
||||
* - __u16
|
||||
- ``max_frame_width_minus_1``
|
||||
- specifies the maximum frame width minus 1 for the frames represented by
|
||||
- Specifies the maximum frame width minus 1 for the frames represented by
|
||||
this sequence header.
|
||||
* - __u16
|
||||
- ``max_frame_height_minus_1``
|
||||
- Specifies the maximum frame height minus 1 for the frames represented by
|
||||
this sequence header.
|
||||
|
||||
.. _av1_sequence_flags:
|
||||
@@ -3374,7 +3378,7 @@ semantics" of :ref:`av1`.
|
||||
- ``uv_pri_strength[V4L2_AV1_CDEF_MAX]``
|
||||
- Specifies the strength of the primary filter.
|
||||
* - __u8
|
||||
- ``uv_secondary_strength[V4L2_AV1_CDEF_MAX]``
|
||||
- ``uv_sec_strength[V4L2_AV1_CDEF_MAX]``
|
||||
- Specifies the strength of the secondary filter.
|
||||
|
||||
.. c:type:: v4l2_av1_segment_feature
|
||||
@@ -3439,7 +3443,7 @@ semantics" of :ref:`av1`.
|
||||
- Bitmask defining which features are enabled in each segment. Use
|
||||
V4L2_AV1_SEGMENT_FEATURE_ENABLED to build a suitable mask.
|
||||
* - __u16
|
||||
- `feature_data[V4L2_AV1_MAX_SEGMENTS][V4L2_AV1_SEG_LVL_MAX]``
|
||||
- ``feature_data[V4L2_AV1_MAX_SEGMENTS][V4L2_AV1_SEG_LVL_MAX]``
|
||||
- Data attached to each feature. Data entry is only valid if the feature
|
||||
is enabled.
|
||||
|
||||
@@ -3490,7 +3494,7 @@ AV1 Loop filter params as defined in section 6.8.10 "Loop filter semantics" of
|
||||
|
||||
.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}|
|
||||
|
||||
.. flat-table:: struct v4l2_av1_global_motion
|
||||
.. flat-table:: struct v4l2_av1_loop_filter
|
||||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
:widths: 1 1 2
|
||||
@@ -3806,12 +3810,12 @@ AV1 Tx mode as described in section 6.8.21 "TX mode semantics" of :ref:`av1`.
|
||||
* - struct :c:type:`v4l2_av1_quantization`
|
||||
- ``quantization``
|
||||
- Quantization parameters.
|
||||
* - struct :c:type:`v4l2_av1_segmentation`
|
||||
- ``segmentation``
|
||||
- Segmentation parameters.
|
||||
* - __u8
|
||||
- ``superres_denom``
|
||||
- The denominator for the upscaling ratio.
|
||||
* - struct :c:type:`v4l2_av1_segmentation`
|
||||
- ``segmentation``
|
||||
- Segmentation parameters.
|
||||
* - struct :c:type:`v4l2_av1_loop_filter`
|
||||
- ``loop_filter``
|
||||
- Loop filter params
|
||||
@@ -3829,7 +3833,7 @@ AV1 Tx mode as described in section 6.8.21 "TX mode semantics" of :ref:`av1`.
|
||||
* - struct :c:type:`v4l2_av1_loop_restoration`
|
||||
- ``loop_restoration``
|
||||
- Loop restoration parameters.
|
||||
* - struct :c:type:`v4l2_av1_loop_global_motion`
|
||||
* - struct :c:type:`v4l2_av1_global_motion`
|
||||
- ``global_motion``
|
||||
- Global motion parameters.
|
||||
* - __u32
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user