moonjuice/kernel_arpi
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge 16b3d0cf5b Merge tag 'sched-core-2021-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into android-mainline

Browse Source 
A little step en route to v5.13-rc1

Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: Ic2fb8aa220023572c96907aebce0a675333ef29f
This commit is contained in:
Lee Jones
2021-05-10 09:01:36 +01:00
parent 0c3ec15ae0 16b3d0cf5b
commit 4797acfb9c
1928 changed files with 210168 additions and 43793 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
Documentation/ABI/testing/sysfs-bus-pci
View File

@@ -195,10 +195,13 @@ What: /sys/bus/pci/devices/.../index
Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given instance (SMBIOS type 41 device type instance) of the
PCI device. The attribute will be created only if the firmware
has given an instance number to the PCI device.
Reading this attribute will provide the firmware given instance
number of the PCI device. Depending on the platform this can
be for example the SMBIOS type 41 device type instance or the
user-defined ID (UID) on s390. The attribute will be created
only if the firmware has given an instance number to the PCI
device and that number is guaranteed to uniquely identify the
device in the system.
Users:
Userspace applications interested in knowing the
firmware assigned device type instance of the PCI

2
Documentation/RCU/RTFP.txt
View File

@@ -847,7 +847,7 @@ Symposium on Distributed Computing}
'It's entirely possible that the current user could be replaced
by RCU and/or seqlocks, and we could get rid of brlocks entirely.'
.
Steve Hemminger responds by replacing them with RCU.
Stephen Hemminger responds by replacing them with RCU.
}
}

1
Documentation/admin-guide/cgroup-v1/index.rst
View File

@@ -17,6 +17,7 @@ Control Groups version 1
hugetlb
memcg_test
memory
misc
net_cls
net_prio
pids

4
Documentation/admin-guide/cgroup-v1/misc.rst Normal file
View File

@@ -0,0 +1,4 @@
===============
Misc controller
===============
Please refer "Misc" documentation in Documentation/admin-guide/cgroup-v2.rst

73
Documentation/admin-guide/cgroup-v2.rst
View File

@@ -65,8 +65,11 @@ v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgrou
5-7-1. RDMA Interface Files
5-8. HugeTLB
5.8-1. HugeTLB Interface Files
5-8. Misc
5-8-1. perf_event
5-9. Misc
5.9-1 Miscellaneous cgroup Interface Files
5.9-2 Migration and Ownership
5-10. Others
5-10-1. perf_event
5-N. Non-normative information
5-N-1. CPU controller root cgroup process behaviour
5-N-2. IO controller root cgroup process behaviour
@@ -2171,6 +2174,72 @@ HugeTLB Interface Files
Misc
----
The Miscellaneous cgroup provides the resource limiting and tracking
mechanism for the scalar resources which cannot be abstracted like the other
cgroup resources. Controller is enabled by the CONFIG_CGROUP_MISC config
option.
A resource can be added to the controller via enum misc_res_type{} in the
include/linux/misc_cgroup.h file and the corresponding name via misc_res_name[]
in the kernel/cgroup/misc.c file. Provider of the resource must set its
capacity prior to using the resource by calling misc_cg_set_capacity().
Once a capacity is set then the resource usage can be updated using charge and
uncharge APIs. All of the APIs to interact with misc controller are in
include/linux/misc_cgroup.h.
Misc Interface Files
~~~~~~~~~~~~~~~~~~~~
Miscellaneous controller provides 3 interface files. If two misc resources (res_a and res_b) are registered then:
misc.capacity
A read-only flat-keyed file shown only in the root cgroup. It shows
miscellaneous scalar resources available on the platform along with
their quantities::
$ cat misc.capacity
res_a 50
res_b 10
misc.current
A read-only flat-keyed file shown in the non-root cgroups. It shows
the current usage of the resources in the cgroup and its children.::
$ cat misc.current
res_a 3
res_b 0
misc.max
A read-write flat-keyed file shown in the non root cgroups. Allowed
maximum usage of the resources in the cgroup and its children.::
$ cat misc.max
res_a max
res_b 4
Limit can be set by::
# echo res_a 1 > misc.max
Limit can be set to max by::
# echo res_a max > misc.max
Limits can be set higher than the capacity value in the misc.capacity
file.
Migration and Ownership
~~~~~~~~~~~~~~~~~~~~~~~
A miscellaneous scalar resource is charged to the cgroup in which it is used
first, and stays charged to that cgroup until that resource is freed. Migrating
a process to a different cgroup does not move the charge to the destination
cgroup where the process has moved.
Others
------
perf_event
~~~~~~~~~~

7
Documentation/admin-guide/kernel-parameters.rst
View File

@@ -68,6 +68,13 @@ For example one can add to the command line following parameter:
where the final item represents CPUs 100,101,125,126,150,151,...
The value "N" can be used to represent the numerically last CPU on the system,
i.e "foo_cpus=16-N" would be equivalent to "16-31" on a 32 core system.
Keep in mind that "N" is dynamic, so if system changes cause the bitmap width
to change, such as less cores in the CPU list, then N and any ranges using N
will also change. Use the same on a small 4 core system, and "16-N" becomes
"16-3" and now the same boot input will be flagged as invalid (start > end).
This document may not be entirely up to date and comprehensive. The command

28
Documentation/admin-guide/kernel-parameters.txt
View File

@@ -782,6 +782,16 @@
cs89x0_media= [HW,NET]
Format: { rj45 | aui | bnc }
csdlock_debug= [KNL] Enable debug add-ons of cross-CPU function call
handling. When switched on, additional debug data is
printed to the console in case a hanging CPU is
detected, and that CPU is pinged again in order to try
to resolve the hang situation.
0: disable csdlock debugging (default)
1: enable basic csdlock debugging (minor impact)
ext: enable extended csdlock debugging (more impact,
but more data)
dasd= [HW,NET]
See header of drivers/s390/block/dasd_devmap.c.
@@ -4081,9 +4091,7 @@
see CONFIG_RAS_CEC help text.
rcu_nocbs= [KNL]
The argument is a cpu list, as described above,
except that the string "all" can be used to
specify every CPU on the system.
The argument is a cpu list, as described above.
In kernels built with CONFIG_RCU_NOCB_CPU=y, set
the specified list of CPUs to be no-callback CPUs.
@@ -4272,6 +4280,18 @@
rcuscale.kfree_rcu_test= [KNL]
Set to measure performance of kfree_rcu() flooding.
rcuscale.kfree_rcu_test_double= [KNL]
Test the double-argument variant of kfree_rcu().
If this parameter has the same value as
rcuscale.kfree_rcu_test_single, both the single-
and double-argument variants are tested.
rcuscale.kfree_rcu_test_single= [KNL]
Test the single-argument variant of kfree_rcu().
If this parameter has the same value as
rcuscale.kfree_rcu_test_double, both the single-
and double-argument variants are tested.
rcuscale.kfree_nthreads= [KNL]
The number of threads running loops of kfree_rcu().
@@ -4738,7 +4758,7 @@
sbni= [NET] Granch SBNI12 leased line adapter
sched_debug [KNL] Enables verbose scheduler debug messages.
sched_verbose [KNL] Enables verbose scheduler debug messages.
schedstats= [KNL,X86] Enable or disable scheduled statistics.
Allowed values are enable and disable. This feature

46
Documentation/core-api/printk-formats.rst
View File

@@ -79,7 +79,19 @@ Pointers printed without a specifier extension (i.e unadorned %p) are
hashed to prevent leaking information about the kernel memory layout. This
has the added benefit of providing a unique identifier. On 64-bit machines
the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it
gathers enough entropy. If you *really* want the address see %px below.
gathers enough entropy.
When possible, use specialised modifiers such as %pS or %pB (described below)
to avoid the need of providing an unhashed address that has to be interpreted
post-hoc. If not possible, and the aim of printing the address is to provide
more information for debugging, use %p and boot the kernel with the
``no_hash_pointers`` parameter during debugging, which will print all %p
addresses unmodified. If you *really* always want the unmodified address, see
%px below.
If (and only if) you are printing addresses as a content of a virtual file in
e.g. procfs or sysfs (using e.g. seq_printf(), not printk()) read by a
userspace process, use the %pK modifier described below instead of %p or %px.
Error Pointers
--------------
@@ -139,6 +151,11 @@ For printing kernel pointers which should be hidden from unprivileged
users. The behaviour of %pK depends on the kptr_restrict sysctl - see
Documentation/admin-guide/sysctl/kernel.rst for more details.
This modifier is *only* intended when producing content of a file read by
userspace from e.g. procfs or sysfs, not for dmesg. Please refer to the
section about %p above for discussion about how to manage hashing pointers
in printk().
Unmodified Addresses
--------------------
@@ -153,6 +170,13 @@ equivalent to %lx (or %lu). %px is preferred because it is more uniquely
grep'able. If in the future we need to modify the way the kernel handles
printing pointers we will be better equipped to find the call sites.
Before using %px, consider if using %p is sufficient together with enabling the
``no_hash_pointers`` kernel parameter during debugging sessions (see the %p
description above). One valid scenario for %px might be printing information
immediately before a panic, which prevents any sensitive information to be
exploited anyway, and with %px there would be no need to reproduce the panic
with no_hash_pointers.
Pointer Differences
-------------------
@@ -540,7 +564,7 @@ Flags bitfields such as page flags, gfp_flags
::
%pGp referenced|uptodate|lru|active|private
%pGp referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff
%pGg GFP_USER|GFP_DMA32|GFP_NOWARN
%pGv read|exec|mayread|maywrite|mayexec|denywrite
@@ -567,6 +591,24 @@ For printing netdev_features_t.
Passed by reference.
V4L2 and DRM FourCC code (pixel format)
---------------------------------------
::
%p4cc
Print a FourCC code used by V4L2 or DRM, including format endianness and
its numerical value as hexadecimal.
Passed by reference.
Examples::
%p4cc BG12 little-endian (0x32314742)
%p4cc Y10 little-endian (0x20303159)
%p4cc NV12 big-endian (0xb231564e)
Thanks
======

3
Documentation/dev-tools/kcsan.rst
View File

@@ -1,3 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0
.. Copyright (C) 2019, Google LLC.
The Kernel Concurrency Sanitizer (KCSAN)
========================================

4
Documentation/dev-tools/kselftest.rst
View File

@@ -239,8 +239,8 @@ using a shell script test runner. ``kselftest/module.sh`` is designed
to facilitate this process. There is also a header file provided to
assist writing kernel modules that are for use with kselftest:
- ``tools/testing/kselftest/kselftest_module.h``
- ``tools/testing/kselftest/kselftest/module.sh``
- ``tools/testing/selftests/kselftest_module.h``
- ``tools/testing/selftests/kselftest/module.sh``
How to use
----------

78
Documentation/dev-tools/kunit/tips.rst
View File

@@ -78,8 +78,82 @@ Similarly to the above, it can be useful to add test-specific logic.
void test_only_hook(void) { }
#endif
TODO(dlatypov@google.com): add an example of using ``current->kunit_test`` in
such a hook when it's not only updated for ``CONFIG_KASAN=y``.
This test-only code can be made more useful by accessing the current kunit
test, see below.
Accessing the current test
--------------------------
In some cases, you need to call test-only code from outside the test file, e.g.
like in the example above or if you're providing a fake implementation of an
ops struct.
There is a ``kunit_test`` field in ``task_struct``, so you can access it via
``current->kunit_test``.
Here's a slightly in-depth example of how one could implement "mocking":
.. code-block:: c
#include <linux/sched.h> /* for current */
struct test_data {
int foo_result;
int want_foo_called_with;
};
static int fake_foo(int arg)
{
struct kunit *test = current->kunit_test;
struct test_data *test_data = test->priv;
KUNIT_EXPECT_EQ(test, test_data->want_foo_called_with, arg);
return test_data->foo_result;
}
static void example_simple_test(struct kunit *test)
{
/* Assume priv is allocated in the suite's .init */
struct test_data *test_data = test->priv;
test_data->foo_result = 42;
test_data->want_foo_called_with = 1;
/* In a real test, we'd probably pass a pointer to fake_foo somewhere
* like an ops struct, etc. instead of calling it directly. */
KUNIT_EXPECT_EQ(test, fake_foo(1), 42);
}
Note: here we're able to get away with using ``test->priv``, but if you wanted
something more flexible you could use a named ``kunit_resource``, see :doc:`api/test`.
Failing the current test
------------------------
But sometimes, you might just want to fail the current test. In that case, we
have ``kunit_fail_current_test(fmt, args...)`` which is defined in ``<kunit/test-bug.h>`` and
doesn't require pulling in ``<kunit/test.h>``.
E.g. say we had an option to enable some extra debug checks on some data structure:
.. code-block:: c
#include <kunit/test-bug.h>
#ifdef CONFIG_EXTRA_DEBUG_CHECKS
static void validate_my_data(struct data *data)
{
if (is_valid(data))
return;
kunit_fail_current_test("data %p is invalid", data);
/* Normal, non-KUnit, error reporting code here. */
}
#else
static void my_debug_function(void) { }
#endif
Customizing error messages
--------------------------

4
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml
View File

@@ -12,8 +12,8 @@ description: |
and CEC.
These DT bindings follow the Synopsys DWC HDMI TX bindings defined
in Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with
the following device-specific properties.
in bridge/synopsys,dw-hdmi.yaml with the following device-specific
properties.
maintainers:
- Chen-Yu Tsai <wens@csie.org>

2
Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
View File

@@ -109,7 +109,7 @@ required:
- resets
- ddc
additionalProperties: false
unevaluatedProperties: false
examples:
- |

15
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
View File

@@ -34,6 +34,15 @@ properties:
description: used for reset chip control, RESET_N pin B7.
maxItems: 1
vdd10-supply:
description: Regulator that provides the supply 1.0V power.
vdd18-supply:
description: Regulator that provides the supply 1.8V power.
vdd33-supply:
description: Regulator that provides the supply 3.3V power.
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -55,6 +64,9 @@ properties:
required:
- compatible
- reg
- vdd10-supply
- vdd18-supply
- vdd33-supply
- ports
additionalProperties: false
@@ -72,6 +84,9 @@ examples:
reg = <0x58>;
enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
vdd10-supply = <&pp1000_mipibrdg>;
vdd18-supply = <&pp1800_mipibrdg>;
vdd33-supply = <&pp3300_mipibrdg>;
ports {
#address-cells = <1>;

99
Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml Normal file
View File

@@ -0,0 +1,99 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/chipone,icn6211.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Chipone ICN6211 MIPI-DSI to RGB Converter bridge
maintainers:
- Jagan Teki <jagan@amarulasolutions.com>
description: |
ICN6211 is MIPI-DSI to RGB Converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input and
produce RGB565, RGB666, RGB888 output format.
properties:
compatible:
enum:
- chipone,icn6211
reg:
maxItems: 1
description: virtual channel number of a DSI peripheral
enable-gpios:
description: Bridge EN pin, chip is reset when EN is low.
vdd1-supply:
description: A 1.8V/2.5V/3.3V supply that power the MIPI RX.
vdd2-supply:
description: A 1.8V/2.5V/3.3V supply that power the PLL.
vdd3-supply:
description: A 1.8V/2.5V/3.3V supply that power the RGB output.
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description:
Video port for MIPI DSI input
port@1:
$ref: /schemas/graph.yaml#/properties/port
description:
Video port for MIPI DPI output (panel or connector).
required:
- port@0
- port@1
required:
- compatible
- reg
- enable-gpios
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
dsi {
#address-cells = <1>;
#size-cells = <0>;
bridge@0 {
compatible = "chipone,icn6211";
reg = <0>;
enable-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
bridge_in_dsi: endpoint {
remote-endpoint = <&dsi_out_bridge>;
};
};
port@1 {
reg = <1>;
bridge_out_panel: endpoint {
remote-endpoint = <&panel_out_bridge>;
};
};
};
};
};

33
Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
View File

@@ -1,33 +0,0 @@
Synopsys DesignWare HDMI TX Encoder
===================================
This document defines device tree properties for the Synopsys DesignWare HDMI
TX Encoder (DWC HDMI TX). It doesn't constitue a device tree binding
specification by itself but is meant to be referenced by platform-specific
device tree bindings.
When referenced from platform device tree bindings the properties defined in
this document are defined as follows. The platform device tree bindings are
responsible for defining whether each property is required or optional.
- reg: Memory mapped base address and length of the DWC HDMI TX registers.
- reg-io-width: Width of the registers specified by the reg property. The
value is expressed in bytes and must be equal to 1 or 4 if specified. The
register width defaults to 1 if the property is not present.
- interrupts: Reference to the DWC HDMI TX interrupt.
- clocks: References to all the clocks specified in the clock-names property
as specified in Documentation/devicetree/bindings/clock/clock-bindings.txt.
- clock-names: The DWC HDMI TX uses the following clocks.
- "iahb" is the bus clock for either AHB and APB (mandatory).
- "isfr" is the internal register configuration clock (mandatory).
- "cec" is the HDMI CEC controller main clock (optional).
- ports: The connectivity of the DWC HDMI TX with the rest of the system is
expressed in using ports as specified in the device graph bindings defined
in Documentation/devicetree/bindings/graph.txt. The numbering of the ports
is platform-specific.

102
Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml Normal file
View File

@@ -0,0 +1,102 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/lontium,lt8912b.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Lontium LT8912B MIPI to HDMI Bridge
maintainers:
- Adrien Grassein <adrien.grassein@gmail.com>
description: |
The LT8912B is a bridge device which convert DSI to HDMI
properties:
compatible:
enum:
- lontium,lt8912b
reg:
maxItems: 1
reset-gpios:
maxItems: 1
description: GPIO connected to active high RESET pin.
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description:
Primary MIPI port for MIPI input
properties:
endpoint:
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes: true
required:
- data-lanes
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: |
HDMI port, should be connected to a node compatible with the
hdmi-connector binding.
required:
- port@0
- port@1
required:
- compatible
- reg
- reset-gpios
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c4 {
#address-cells = <1>;
#size-cells = <0>;
hdmi-bridge@48 {
compatible = "lontium,lt8912b";
reg = <0x48>;
reset-gpios = <&max7323 0 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
hdmi_out_in: endpoint {
data-lanes = <0 1 2 3>;
remote-endpoint = <&mipi_dsi_out>;
};
};
port@1 {
reg = <1>;
endpoint {
remote-endpoint = <&hdmi_in>;
};
};
};
};
};
...

88
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
View File

@@ -1,88 +0,0 @@
Renesas Gen3 DWC HDMI TX Encoder
================================
The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
with a companion PHY IP.
These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
following device-specific properties.
Required properties:
- compatible : Shall contain one or more of
- "renesas,r8a774a1-hdmi" for R8A774A1 (RZ/G2M) compatible HDMI TX
- "renesas,r8a774b1-hdmi" for R8A774B1 (RZ/G2N) compatible HDMI TX
- "renesas,r8a774e1-hdmi" for R8A774E1 (RZ/G2H) compatible HDMI TX
- "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX
- "renesas,r8a7796-hdmi" for R8A7796 (R-Car M3-W) compatible HDMI TX
- "renesas,r8a77961-hdmi" for R8A77961 (R-Car M3-W+) compatible HDMI TX
- "renesas,r8a77965-hdmi" for R8A77965 (R-Car M3-N) compatible HDMI TX
- "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 and RZ/G2 compatible
HDMI TX
When compatible with generic versions, nodes must list the SoC-specific
version corresponding to the platform first, followed by the
family-specific version.
- reg: See dw_hdmi.txt.
- interrupts: HDMI interrupt number
- clocks: See dw_hdmi.txt.
- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
- ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0
corresponding to the video input of the controller and one port numbered 1
corresponding to its HDMI output, and one port numbered 2 corresponding to
sound input of the controller. Each port shall have a single endpoint.
Optional properties:
- power-domains: Shall reference the power domain that contains the DWC HDMI,
if any.
Example:
hdmi0: hdmi@fead0000 {
compatible = "renesas,r8a7795-hdmi", "renesas,rcar-gen3-hdmi";
reg = <0 0xfead0000 0 0x10000>;
interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>;
clock-names = "iahb", "isfr";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dw_hdmi0_in: endpoint {
remote-endpoint = <&du_out_hdmi0>;
};
};
port@1 {
reg = <1>;
rcar_dw_hdmi0_out: endpoint {
remote-endpoint = <&hdmi0_con>;
};
};
port@2 {
reg = <2>;
rcar_dw_hdmi0_sound_in: endpoint {
remote-endpoint = <&hdmi_sound_out>;
};
};
};
};
hdmi0-out {
compatible = "hdmi-connector";
label = "HDMI0 OUT";
type = "a";
port {
hdmi0_con: endpoint {
remote-endpoint = <&rcar_dw_hdmi0_out>;
};
};
};

125
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml Normal file
View File

@@ -0,0 +1,125 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/renesas,dw-hdmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car DWC HDMI TX Encoder
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
description: |
The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
with a companion PHY IP.
allOf:
- $ref: synopsys,dw-hdmi.yaml#
properties:
compatible:
items:
- enum:
- renesas,r8a774a1-hdmi # for RZ/G2M compatible HDMI TX
- renesas,r8a774b1-hdmi # for RZ/G2N compatible HDMI TX
- renesas,r8a774e1-hdmi # for RZ/G2H compatible HDMI TX
- renesas,r8a7795-hdmi # for R-Car H3 compatible HDMI TX
- renesas,r8a7796-hdmi # for R-Car M3-W compatible HDMI TX
- renesas,r8a77961-hdmi # for R-Car M3-W+ compatible HDMI TX
- renesas,r8a77965-hdmi # for R-Car M3-N compatible HDMI TX
- const: renesas,rcar-gen3-hdmi
reg-io-width:
const: 1
clocks:
maxItems: 2
clock-names:
maxItems: 2
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: Parallel RGB input port
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: HDMI output port
port@2:
$ref: /schemas/graph.yaml#/properties/port
description: Sound input port
required:
- port@0
- port@1
- port@2
power-domains:
maxItems: 1
required:
- compatible
- reg
- clocks
- clock-names
- interrupts
- ports
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/r8a7795-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/power/r8a7795-sysc.h>
hdmi@fead0000 {
compatible = "renesas,r8a7795-hdmi", "renesas,rcar-gen3-hdmi";
reg = <0xfead0000 0x10000>;
interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>;
clock-names = "iahb", "isfr";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dw_hdmi0_in: endpoint {
remote-endpoint = <&du_out_hdmi0>;
};
};
port@1 {
reg = <1>;
rcar_dw_hdmi0_out: endpoint {
remote-endpoint = <&hdmi0_con>;
};
};
port@2 {
reg = <2>;
rcar_dw_hdmi0_sound_in: endpoint {
remote-endpoint = <&hdmi_sound_out>;
};
};
};
};
hdmi0-out {
compatible = "hdmi-connector";
label = "HDMI0 OUT";
type = "a";
port {
hdmi0_con: endpoint {
remote-endpoint = <&rcar_dw_hdmi0_out>;
};
};
};
...

55
Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml Normal file
View File

@@ -0,0 +1,55 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/synopsys,dw-hdmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common Properties for Synopsys DesignWare HDMI TX Controller
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
description: |
This document defines device tree properties for the Synopsys DesignWare HDMI
TX controller (DWC HDMI TX) IP core. It doesn't constitute a full device tree
binding specification by itself but is meant to be referenced by device tree
bindings for the platform-specific integrations of the DWC HDMI TX.
When referenced from platform device tree bindings the properties defined in
this document are defined as follows. The platform device tree bindings are
responsible for defining whether each property is required or optional.
properties:
reg:
maxItems: 1
reg-io-width:
description:
Width (in bytes) of the registers specified by the reg property.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 4]
default: 1
clocks:
minItems: 2
maxItems: 5
items:
- description: The bus clock for either AHB and APB
- description: The internal register configuration clock
additionalItems: true
clock-names:
minItems: 2
maxItems: 5
items:
- const: iahb
- const: isfr
additionalItems: true
interrupts:
maxItems: 1
additionalProperties: true
...

110
Documentation/devicetree/bindings/display/fsl,lcdif.yaml Normal file
View File

@@ -0,0 +1,110 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/fsl,lcdif.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale/NXP i.MX LCD Interface (LCDIF)
maintainers:
- Marek Vasut <marex@denx.de>
- Stefan Agner <stefan@agner.ch>
description: |
(e)LCDIF display controller found in the Freescale/NXP i.MX SoCs.
properties:
compatible:
oneOf:
- enum:
- fsl,imx23-lcdif
- fsl,imx28-lcdif
- fsl,imx6sx-lcdif
- items:
- enum:
- fsl,imx6sl-lcdif
- fsl,imx6sll-lcdif
- fsl,imx6ul-lcdif
- fsl,imx7d-lcdif
- fsl,imx8mm-lcdif
- fsl,imx8mq-lcdif
- const: fsl,imx6sx-lcdif
reg:
maxItems: 1
clocks:
items:
- description: Pixel clock
- description: Bus clock
- description: Display AXI clock
minItems: 1
clock-names:
items:
- const: pix
- const: axi
- const: disp_axi
minItems: 1
interrupts:
maxItems: 1
port:
$ref: /schemas/graph.yaml#/properties/port
description: The LCDIF output port
required:
- compatible
- reg
- clocks
- interrupts
- port
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
const: fsl,imx6sx-lcdif
then:
properties:
clocks:
minItems: 2
maxItems: 3
clock-names:
minItems: 2
maxItems: 3
required:
- clock-names
else:
properties:
clocks:
maxItems: 1
clock-names:
maxItems: 1
examples:
- |
#include <dt-bindings/clock/imx6sx-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
display-controller@2220000 {
compatible = "fsl,imx6sx-lcdif";
reg = <0x02220000 0x4000>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
<&clks IMX6SX_CLK_LCDIF_APB>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
clock-names = "pix", "axi", "disp_axi";
port {
endpoint {
remote-endpoint = <&panel_in>;
};
};
};
...

126
Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml Normal file
View File

@@ -0,0 +1,126 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/imx/fsl,imx6-hdmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX6 DWC HDMI TX Encoder
maintainers:
- Philipp Zabel <p.zabel@pengutronix.de>
description: |
The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
with a companion PHY IP.
allOf:
- $ref: ../bridge/synopsys,dw-hdmi.yaml#
properties:
compatible:
enum:
- fsl,imx6dl-hdmi
- fsl,imx6q-hdmi
reg-io-width:
const: 1
clocks:
maxItems: 2
clock-names:
maxItems: 2
ddc-i2c-bus:
$ref: /schemas/types.yaml#/definitions/phandle
description:
The HDMI DDC bus can be connected to either a system I2C master or the
functionally-reduced I2C master contained in the DWC HDMI. When connected
to a system I2C master this property contains a phandle to that I2C
master controller.
gpr:
$ref: /schemas/types.yaml#/definitions/phandle
description:
phandle to the iomuxc-gpr region containing the HDMI multiplexer control
register.
ports:
$ref: /schemas/graph.yaml#/properties/ports
description: |
This device has four video ports, corresponding to the four inputs of the
HDMI multiplexer. Each port shall have a single endpoint.
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: First input of the HDMI multiplexer
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: Second input of the HDMI multiplexer
port@2:
$ref: /schemas/graph.yaml#/properties/port
description: Third input of the HDMI multiplexer
port@3:
$ref: /schemas/graph.yaml#/properties/port
description: Fourth input of the HDMI multiplexer
anyOf:
- required:
- port@0
- required:
- port@1
- required:
- port@2
- required:
- port@3
required:
- compatible
- reg
- clocks
- clock-names
- gpr
- interrupts
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx6qdl-clock.h>
hdmi: hdmi@120000 {
reg = <0x00120000 0x9000>;
interrupts = <0 115 0x04>;
gpr = <&gpr>;
clocks = <&clks IMX6QDL_CLK_HDMI_IAHB>,
<&clks IMX6QDL_CLK_HDMI_ISFR>;
clock-names = "iahb", "isfr";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
hdmi_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_hdmi>;
};
};
port@1 {
reg = <1>;
hdmi_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_hdmi>;
};
};
};
};
...

65
Documentation/devicetree/bindings/display/imx/hdmi.txt
View File

@@ -1,65 +0,0 @@
Freescale i.MX6 DWC HDMI TX Encoder
===================================
The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
with a companion PHY IP.
These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
following device-specific properties.
Required properties:
- compatible : Shall be one of "fsl,imx6q-hdmi" or "fsl,imx6dl-hdmi".
- reg: See dw_hdmi.txt.
- interrupts: HDMI interrupt number
- clocks: See dw_hdmi.txt.
- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
- ports: See dw_hdmi.txt. The DWC HDMI shall have between one and four ports,
numbered 0 to 3, corresponding to the four inputs of the HDMI multiplexer.
Each port shall have a single endpoint.
- gpr : Shall contain a phandle to the iomuxc-gpr region containing the HDMI
multiplexer control register.
Optional properties
- ddc-i2c-bus: The HDMI DDC bus can be connected to either a system I2C master
or the functionally-reduced I2C master contained in the DWC HDMI. When
connected to a system I2C master this property contains a phandle to that
I2C master controller.
Example:
gpr: iomuxc-gpr@20e0000 {
/* ... */
};
hdmi: hdmi@120000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-hdmi";
reg = <0x00120000 0x9000>;
interrupts = <0 115 0x04>;
gpr = <&gpr>;
clocks = <&clks 123>, <&clks 124>;
clock-names = "iahb", "isfr";
ddc-i2c-bus = <&i2c2>;
port@0 {
reg = <0>;
hdmi_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_hdmi>;
};
};
port@1 {
reg = <1>;
hdmi_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_hdmi>;
};
};
};

2
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
View File

@@ -64,7 +64,7 @@ Required properties (DMA function blocks):
- larb: Should contain a phandle pointing to the local arbiter device as defined
in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
- iommus: Should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
Optional properties (RDMA function blocks):

12
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
View File

@@ -22,6 +22,7 @@ properties:
- mediatek,mt7623-dpi
- mediatek,mt8173-dpi
- mediatek,mt8183-dpi
- mediatek,mt8192-dpi
reg:
maxItems: 1
@@ -50,15 +51,10 @@ properties:
- const: sleep
port:
type: object
$ref: /schemas/graph.yaml#/properties/port
description:
Output port node with endpoint definitions as described in
Documentation/devicetree/bindings/graph.txt. This port should be connected
to the input port of an attached HDMI or LVDS encoder chip.
properties:
endpoint:
type: object
Output port node. This port should be connected to the input port of an
attached HDMI or LVDS encoder chip.
required:
- compatible

87
Documentation/devicetree/bindings/display/mxsfb.txt
View File

@@ -1,87 +0,0 @@
* Freescale MXS LCD Interface (LCDIF)
New bindings:
=============
Required properties:
- compatible: Should be "fsl,imx23-lcdif" for i.MX23.
Should be "fsl,imx28-lcdif" for i.MX28.
Should be "fsl,imx6sx-lcdif" for i.MX6SX.
Should be "fsl,imx8mq-lcdif" for i.MX8MQ.
- reg: Address and length of the register set for LCDIF
- interrupts: Should contain LCDIF interrupt
- clocks: A list of phandle + clock-specifier pairs, one for each
entry in 'clock-names'.
- clock-names: A list of clock names. For MXSFB it should contain:
- "pix" for the LCDIF block clock
- (MX6SX-only) "axi", "disp_axi" for the bus interface clock
Required sub-nodes:
- port: The connection to an encoder chip.
Example:
lcdif1: display-controller@2220000 {
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
reg = <0x02220000 0x4000>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
<&clks IMX6SX_CLK_LCDIF_APB>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
clock-names = "pix", "axi", "disp_axi";
port {
parallel_out: endpoint {
remote-endpoint = <&panel_in_parallel>;
};
};
};
Deprecated bindings:
====================
Required properties:
- compatible: Should be "fsl,imx23-lcdif" for i.MX23.
Should be "fsl,imx28-lcdif" for i.MX28.
- reg: Address and length of the register set for LCDIF
- interrupts: Should contain LCDIF interrupts
- display: phandle to display node (see below for details)
* display node
Required properties:
- bits-per-pixel: <16> for RGB565, <32> for RGB888/666.
- bus-width: number of data lines. Could be <8>, <16>, <18> or <24>.
Required sub-node:
- display-timings: Refer to binding doc display-timing.txt for details.
Examples:
lcdif@80030000 {
compatible = "fsl,imx28-lcdif";
reg = <0x80030000 2000>;
interrupts = <38 86>;
display: display {
bits-per-pixel = <32>;
bus-width = <24>;
display-timings {
native-mode = <&timing0>;
timing0: timing0 {
clock-frequency = <33500000>;
hactive = <800>;
vactive = <480>;
hfront-porch = <164>;
hback-porch = <89>;
hsync-len = <10>;
vback-porch = <23>;
vfront-porch = <10>;
vsync-len = <10>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <0>;
};
};
};
};

2
Documentation/devicetree/bindings/display/panel/panel-simple.yaml
View File

@@ -161,6 +161,8 @@ properties:
# Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
- innolux,g121x1-l03
# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- innolux,n116bca-ea1
# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- innolux,n116bge
# InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
- innolux,n125hce-gn1

145
Documentation/devicetree/bindings/display/renesas,du.txt
View File

@@ -1,145 +0,0 @@
* Renesas R-Car Display Unit (DU)
Required Properties:
- compatible: must be one of the following.
- "renesas,du-r8a7742" for R8A7742 (RZ/G1H) compatible DU
- "renesas,du-r8a7743" for R8A7743 (RZ/G1M) compatible DU
- "renesas,du-r8a7744" for R8A7744 (RZ/G1N) compatible DU
- "renesas,du-r8a7745" for R8A7745 (RZ/G1E) compatible DU
- "renesas,du-r8a77470" for R8A77470 (RZ/G1C) compatible DU
- "renesas,du-r8a774a1" for R8A774A1 (RZ/G2M) compatible DU
- "renesas,du-r8a774b1" for R8A774B1 (RZ/G2N) compatible DU
- "renesas,du-r8a774c0" for R8A774C0 (RZ/G2E) compatible DU
- "renesas,du-r8a774e1" for R8A774E1 (RZ/G2H) compatible DU
- "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU
- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU
- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
- "renesas,du-r8a7792" for R8A7792 (R-Car V2H) compatible DU
- "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU
- "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
- "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
- "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
- "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU
- "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
- "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
- "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU
- "renesas,du-r8a77990" for R8A77990 (R-Car E3) compatible DU
- "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU
- reg: the memory-mapped I/O registers base address and length
- interrupts: Interrupt specifiers for the DU interrupts.
- clocks: A list of phandles + clock-specifier pairs, one for each entry in
the clock-names property.
- clock-names: Name of the clocks. This property is model-dependent.
- R8A7779 uses a single functional clock. The clock doesn't need to be
named.
- All other DU instances use one functional clock per channel The
functional clocks must be named "du.x" with "x" being the channel
numerical index.
- In addition to the functional clocks, all DU versions also support
externally supplied pixel clocks. Those clocks are optional. When
supplied they must be named "dclkin.x" with "x" being the input clock
numerical index.
- renesas,cmms: A list of phandles to the CMM instances present in the SoC,
one for each available DU channel. The property shall not be specified for
SoCs that do not provide any CMM (such as V3M and V3H).
- renesas,vsps: A list of phandle and channel index tuples to the VSPs that
handle the memory interfaces for the DU channels. The phandle identifies the
VSP instance that serves the DU channel, and the channel index identifies
the LIF instance in that VSP.
Optional properties:
- resets: A list of phandle + reset-specifier pairs, one for each entry in
the reset-names property.
- reset-names: Names of the resets. This property is model-dependent.
- All but R8A7779 use one reset for a group of one or more successive
channels. The resets must be named "du.x" with "x" being the numerical
index of the lowest channel in the group.
Required nodes:
The connections to the DU output video ports are modeled using the OF graph
bindings specified in Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each DU output.
Port0 Port1 Port2 Port3
-----------------------------------------------------------------------------
R8A7742 (RZ/G1H) DPAD 0 LVDS 0 LVDS 1 -
R8A7743 (RZ/G1M) DPAD 0 LVDS 0 - -
R8A7744 (RZ/G1N) DPAD 0 LVDS 0 - -
R8A7745 (RZ/G1E) DPAD 0 DPAD 1 - -
R8A77470 (RZ/G1C) DPAD 0 DPAD 1 LVDS 0 -
R8A774A1 (RZ/G2M) DPAD 0 HDMI 0 LVDS 0 -
R8A774B1 (RZ/G2N) DPAD 0 HDMI 0 LVDS 0 -
R8A774C0 (RZ/G2E) DPAD 0 LVDS 0 LVDS 1 -
R8A774E1 (RZ/G2H) DPAD 0 HDMI 0 LVDS 0 -
R8A7779 (R-Car H1) DPAD 0 DPAD 1 - -
R8A7790 (R-Car H2) DPAD 0 LVDS 0 LVDS 1 -
R8A7791 (R-Car M2-W) DPAD 0 LVDS 0 - -
R8A7792 (R-Car V2H) DPAD 0 DPAD 1 - -
R8A7793 (R-Car M2-N) DPAD 0 LVDS 0 - -
R8A7794 (R-Car E2) DPAD 0 DPAD 1 - -
R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0
R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
R8A77961 (R-Car M3-W+) DPAD 0 HDMI 0 LVDS 0 -
R8A77965 (R-Car M3-N) DPAD 0 HDMI 0 LVDS 0 -
R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - -
R8A77980 (R-Car V3H) DPAD 0 LVDS 0 - -
R8A77990 (R-Car E3) DPAD 0 LVDS 0 LVDS 1 -
R8A77995 (R-Car D3) DPAD 0 LVDS 0 LVDS 1 -
Example: R8A7795 (R-Car H3) ES2.0 DU
du: display@feb00000 {
compatible = "renesas,du-r8a7795";
reg = <0 0xfeb00000 0 0x80000>;
interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 724>,
<&cpg CPG_MOD 723>,
<&cpg CPG_MOD 722>,
<&cpg CPG_MOD 721>;
clock-names = "du.0", "du.1", "du.2", "du.3";
resets = <&cpg 724>, <&cpg 722>;
reset-names = "du.0", "du.2";
renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
du_out_rgb: endpoint {
};
};
port@1 {
reg = <1>;
du_out_hdmi0: endpoint {
remote-endpoint = <&dw_hdmi0_in>;
};
};
port@2 {
reg = <2>;
du_out_hdmi1: endpoint {
remote-endpoint = <&dw_hdmi1_in>;
};
};
port@3 {
reg = <3>;
du_out_lvds0: endpoint {
};
};
};
};

831
Documentation/devicetree/bindings/display/renesas,du.yaml Normal file
View File

@@ -0,0 +1,831 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/renesas,du.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car Display Unit (DU)
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
description: |
These DT bindings describe the Display Unit embedded in the Renesas R-Car
Gen1, R-Car Gen2, R-Car Gen3, RZ/G1 and RZ/G2 SoCs.
properties:
compatible:
enum:
- renesas,du-r8a7742 # for RZ/G1H compatible DU
- renesas,du-r8a7743 # for RZ/G1M compatible DU
- renesas,du-r8a7744 # for RZ/G1N compatible DU
- renesas,du-r8a7745 # for RZ/G1E compatible DU
- renesas,du-r8a77470 # for RZ/G1C compatible DU
- renesas,du-r8a774a1 # for RZ/G2M compatible DU
- renesas,du-r8a774b1 # for RZ/G2N compatible DU
- renesas,du-r8a774c0 # for RZ/G2E compatible DU
- renesas,du-r8a774e1 # for RZ/G2H compatible DU
- renesas,du-r8a7779 # for R-Car H1 compatible DU
- renesas,du-r8a7790 # for R-Car H2 compatible DU
- renesas,du-r8a7791 # for R-Car M2-W compatible DU
- renesas,du-r8a7792 # for R-Car V2H compatible DU
- renesas,du-r8a7793 # for R-Car M2-N compatible DU
- renesas,du-r8a7794 # for R-Car E2 compatible DU
- renesas,du-r8a7795 # for R-Car H3 compatible DU
- renesas,du-r8a7796 # for R-Car M3-W compatible DU
- renesas,du-r8a77961 # for R-Car M3-W+ compatible DU
- renesas,du-r8a77965 # for R-Car M3-N compatible DU
- renesas,du-r8a77970 # for R-Car V3M compatible DU
- renesas,du-r8a77980 # for R-Car V3H compatible DU
- renesas,du-r8a77990 # for R-Car E3 compatible DU
- renesas,du-r8a77995 # for R-Car D3 compatible DU
reg:
maxItems: 1
# See compatible-specific constraints below.
clocks: true
clock-names: true
interrupts:
description: Interrupt specifiers, one per DU channel
resets: true
reset-names: true
ports:
$ref: /schemas/graph.yaml#/properties/port
description: |
The connections to the DU output video ports are modeled using the OF
graph bindings specified in Documentation/devicetree/bindings/graph.txt.
The number of ports and their assignment are model-dependent. Each port
shall have a single endpoint.
patternProperties:
"^port@[0-3]$":
$ref: /schemas/graph.yaml#/properties/port
unevaluatedProperties: false
required:
- port@0
- port@1
unevaluatedProperties: false
renesas,cmms:
$ref: "/schemas/types.yaml#/definitions/phandle-array"
description:
A list of phandles to the CMM instances present in the SoC, one for each
available DU channel.
renesas,vsps:
$ref: "/schemas/types.yaml#/definitions/phandle-array"
description:
A list of phandle and channel index tuples to the VSPs that handle the
memory interfaces for the DU channels. The phandle identifies the VSP
instance that serves the DU channel, and the channel index identifies
the LIF instance in that VSP.
required:
- compatible
- reg
- clocks
- interrupts
- resets
- ports
allOf:
- if:
properties:
compatible:
contains:
const: renesas,du-r8a7779
then:
properties:
clocks:
minItems: 1
maxItems: 3
items:
- description: Functional clock
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
clock-names:
minItems: 1
maxItems: 3
items:
- const: du.0
- pattern: '^dclkin\.[01]$'
- pattern: '^dclkin\.[01]$'
interrupts:
maxItems: 1
resets:
maxItems: 1
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: DPAD 1
# port@2 is TCON, not supported yet
port@2: false
port@3: false
required:
- port@0
- port@1
required:
- interrupts
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a7743
- renesas,du-r8a7744
- renesas,du-r8a7791
- renesas,du-r8a7793
then:
properties:
clocks:
minItems: 2
maxItems: 4
items:
- description: Functional clock for DU0
- description: Functional clock for DU1
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
clock-names:
minItems: 2
maxItems: 4
items:
- const: du.0
- const: du.1
- pattern: '^dclkin\.[01]$'
- pattern: '^dclkin\.[01]$'
interrupts:
maxItems: 2
resets:
maxItems: 1
reset-names:
items:
- const: du.0
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: LVDS 0
# port@2 is TCON, not supported yet
port@2: false
port@3: false
required:
- port@0
- port@1
required:
- clock-names
- interrupts
- resets
- reset-names
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a7745
- renesas,du-r8a7792
then:
properties:
clocks:
minItems: 2
maxItems: 4
items:
- description: Functional clock for DU0
- description: Functional clock for DU1
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
clock-names:
minItems: 2
maxItems: 4
items:
- const: du.0
- const: du.1
- pattern: '^dclkin\.[01]$'
- pattern: '^dclkin\.[01]$'
interrupts:
maxItems: 2
resets:
maxItems: 1
reset-names:
items:
- const: du.0
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: DPAD 1
port@2: false
port@3: false
required:
- port@0
- port@1
required:
- clock-names
- interrupts
- resets
- reset-names
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a7794
then:
properties:
clocks:
minItems: 2
maxItems: 4
items:
- description: Functional clock for DU0
- description: Functional clock for DU1
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
clock-names:
minItems: 2
maxItems: 4
items:
- const: du.0
- const: du.1
- pattern: '^dclkin\.[01]$'
- pattern: '^dclkin\.[01]$'
interrupts:
maxItems: 2
resets:
maxItems: 1
reset-names:
items:
- const: du.0
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: DPAD 1
# port@2 is TCON, not supported yet
port@2: false
port@3: false
required:
- port@0
- port@1
required:
- clock-names
- interrupts
- resets
- reset-names
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a77470
then:
properties:
clocks:
minItems: 2
maxItems: 4
items:
- description: Functional clock for DU0
- description: Functional clock for DU1
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
clock-names:
minItems: 2
maxItems: 4
items:
- const: du.0
- const: du.1
- pattern: '^dclkin\.[01]$'
- pattern: '^dclkin\.[01]$'
interrupts:
maxItems: 2
resets:
maxItems: 1
reset-names:
items:
- const: du.0
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: DPAD 1
port@2:
description: LVDS 0
# port@3 is DVENC, not supported yet
port@3: false
required:
- port@0
- port@1
- port@2
required:
- clock-names
- interrupts
- resets
- reset-names
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a7742
- renesas,du-r8a7790
then:
properties:
clocks:
minItems: 3
maxItems: 6
items:
- description: Functional clock for DU0
- description: Functional clock for DU1
- description: Functional clock for DU2
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
- description: DU_DOTCLKIN2 input clock
clock-names:
minItems: 3
maxItems: 6
items:
- const: du.0
- const: du.1
- const: du.2
- pattern: '^dclkin\.[012]$'
- pattern: '^dclkin\.[012]$'
- pattern: '^dclkin\.[012]$'
interrupts:
maxItems: 3
resets:
maxItems: 1
reset-names:
items:
- const: du.0
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: LVDS 0
port@2:
description: LVDS 1
# port@3 is TCON, not supported yet
port@3: false
required:
- port@0
- port@1
- port@2
required:
- clock-names
- interrupts
- resets
- reset-names
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a7795
then:
properties:
clocks:
minItems: 4
maxItems: 8
items:
- description: Functional clock for DU0
- description: Functional clock for DU1
- description: Functional clock for DU2
- description: Functional clock for DU4
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
- description: DU_DOTCLKIN2 input clock
- description: DU_DOTCLKIN3 input clock
clock-names:
minItems: 4
maxItems: 8
items:
- const: du.0
- const: du.1
- const: du.2
- const: du.3
- pattern: '^dclkin\.[0123]$'
- pattern: '^dclkin\.[0123]$'
- pattern: '^dclkin\.[0123]$'
- pattern: '^dclkin\.[0123]$'
interrupts:
maxItems: 4
resets:
maxItems: 2
reset-names:
items:
- const: du.0
- const: du.2
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: HDMI 0
port@2:
description: HDMI 1
port@3:
description: LVDS 0
required:
- port@0
- port@1
- port@2
- port@3
renesas,cmms:
minItems: 4
renesas,vsps:
minItems: 4
required:
- clock-names
- interrupts
- resets
- reset-names
- renesas,vsps
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a774a1
- renesas,du-r8a7796
- renesas,du-r8a77961
then:
properties:
clocks:
minItems: 3
maxItems: 6
items:
- description: Functional clock for DU0
- description: Functional clock for DU1
- description: Functional clock for DU2
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
- description: DU_DOTCLKIN2 input clock
clock-names:
minItems: 3
maxItems: 6
items:
- const: du.0
- const: du.1
- const: du.2
- pattern: '^dclkin\.[012]$'
- pattern: '^dclkin\.[012]$'
- pattern: '^dclkin\.[012]$'
interrupts:
maxItems: 3
resets:
maxItems: 2
reset-names:
items:
- const: du.0
- const: du.2
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: HDMI 0
port@2:
description: LVDS 0
port@3: false
required:
- port@0
- port@1
- port@2
renesas,cmms:
minItems: 3
renesas,vsps:
minItems: 3
required:
- clock-names
- interrupts
- resets
- reset-names
- renesas,vsps
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a774b1
- renesas,du-r8a774e1
- renesas,du-r8a77965
then:
properties:
clocks:
minItems: 3
maxItems: 6
items:
- description: Functional clock for DU0
- description: Functional clock for DU1
- description: Functional clock for DU3
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
- description: DU_DOTCLKIN3 input clock
clock-names:
minItems: 3
maxItems: 6
items:
- const: du.0
- const: du.1
- const: du.3
- pattern: '^dclkin\.[013]$'
- pattern: '^dclkin\.[013]$'
- pattern: '^dclkin\.[013]$'
interrupts:
maxItems: 3
resets:
maxItems: 2
reset-names:
items:
- const: du.0
- const: du.3
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: HDMI 0
port@2:
description: LVDS 0
port@3: false
required:
- port@0
- port@1
- port@2
renesas,cmms:
minItems: 3
renesas,vsps:
minItems: 3
required:
- clock-names
- interrupts
- resets
- reset-names
- renesas,vsps
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a77970
- renesas,du-r8a77980
then:
properties:
clocks:
minItems: 1
maxItems: 2
items:
- description: Functional clock for DU0
- description: DU_DOTCLKIN0 input clock
clock-names:
minItems: 1
maxItems: 2
items:
- const: du.0
- const: dclkin.0
interrupts:
maxItems: 1
resets:
maxItems: 1
reset-names:
items:
- const: du.0
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: LVDS 0
port@2: false
port@3: false
required:
- port@0
- port@1
renesas,vsps:
minItems: 1
required:
- clock-names
- interrupts
- resets
- reset-names
- renesas,vsps
- if:
properties:
compatible:
contains:
enum:
- renesas,du-r8a774c0
- renesas,du-r8a77990
- renesas,du-r8a77995
then:
properties:
clocks:
minItems: 2
maxItems: 4
items:
- description: Functional clock for DU0
- description: Functional clock for DU1
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
clock-names:
minItems: 2
maxItems: 4
items:
- const: du.0
- const: du.1
- pattern: '^dclkin\.[01]$'
- pattern: '^dclkin\.[01]$'
interrupts:
maxItems: 2
resets:
maxItems: 1
reset-names:
items:
- const: du.0
ports:
properties:
port@0:
description: DPAD 0
port@1:
description: LVDS 0
port@2:
description: LVDS 1
# port@3 is TCON, not supported yet
port@3: false
required:
- port@0
- port@1
- port@2
renesas,cmms:
minItems: 2
renesas,vsps:
minItems: 2
required:
- clock-names
- interrupts
- resets
- reset-names
- renesas,vsps
additionalProperties: false
examples:
# R-Car H3 ES2.0 DU
- |
#include <dt-bindings/clock/renesas-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
display@feb00000 {
compatible = "renesas,du-r8a7795";
reg = <0xfeb00000 0x80000>;
interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 724>,
<&cpg CPG_MOD 723>,
<&cpg CPG_MOD 722>,
<&cpg CPG_MOD 721>;
clock-names = "du.0", "du.1", "du.2", "du.3";
resets = <&cpg 724>, <&cpg 722>;
reset-names = "du.0", "du.2";
renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
endpoint {
remote-endpoint = <&adv7123_in>;
};
};
port@1 {
reg = <1>;
endpoint {
remote-endpoint = <&dw_hdmi0_in>;
};
};
port@2 {
reg = <2>;
endpoint {
remote-endpoint = <&dw_hdmi1_in>;
};
};
port@3 {
reg = <3>;
endpoint {
remote-endpoint = <&lvds0_in>;
};
};
};
};
...

74
Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
View File

@@ -1,74 +0,0 @@
Rockchip DWC HDMI TX Encoder
============================
The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
with a companion PHY IP.
These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
following device-specific properties.
Required properties:
- compatible: should be one of the following:
"rockchip,rk3228-dw-hdmi"
"rockchip,rk3288-dw-hdmi"
"rockchip,rk3328-dw-hdmi"
"rockchip,rk3399-dw-hdmi"
- reg: See dw_hdmi.txt.
- reg-io-width: See dw_hdmi.txt. Shall be 4.
- interrupts: HDMI interrupt number
- clocks: See dw_hdmi.txt.
- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
- ports: See dw_hdmi.txt. The DWC HDMI shall have a single port numbered 0
corresponding to the video input of the controller. The port shall have two
endpoints, numbered 0 and 1, connected respectively to the vopb and vopl.
- rockchip,grf: Shall reference the GRF to mux vopl/vopb.
Optional properties
- ddc-i2c-bus: The HDMI DDC bus can be connected to either a system I2C master
or the functionally-reduced I2C master contained in the DWC HDMI. When
connected to a system I2C master this property contains a phandle to that
I2C master controller.
- clock-names: See dw_hdmi.txt. The "cec" clock is optional.
- clock-names: May contain "cec" as defined in dw_hdmi.txt.
- clock-names: May contain "grf", power for grf io.
- clock-names: May contain "vpll", external clock for some hdmi phy.
- phys: from general PHY binding: the phandle for the PHY device.
- phy-names: Should be "hdmi" if phys references an external phy.
Optional pinctrl entry:
- If you have both a "unwedge" and "default" pinctrl entry, dw_hdmi
will switch to the unwedge pinctrl state for 10ms if it ever gets an
i2c timeout. It's intended that this unwedge pinctrl entry will
cause the SDA line to be driven low to work around a hardware
errata.
Example:
hdmi: hdmi@ff980000 {
compatible = "rockchip,rk3288-dw-hdmi";
reg = <0xff980000 0x20000>;
reg-io-width = <4>;
ddc-i2c-bus = <&i2c5>;
rockchip,grf = <&grf>;
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
clock-names = "iahb", "isfr";
ports {
hdmi_in: port {
#address-cells = <1>;
#size-cells = <0>;
hdmi_in_vopb: endpoint@0 {
reg = <0>;
remote-endpoint = <&vopb_out_hdmi>;
};
hdmi_in_vopl: endpoint@1 {
reg = <1>;
remote-endpoint = <&vopl_out_hdmi>;
};
};
};
};

156
Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml Normal file
View File

@@ -0,0 +1,156 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip DWC HDMI TX Encoder
maintainers:
- Mark Yao <markyao0591@gmail.com>
description: |
The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
with a companion PHY IP.
allOf:
- $ref: ../bridge/synopsys,dw-hdmi.yaml#
properties:
compatible:
enum:
- rockchip,rk3228-dw-hdmi
- rockchip,rk3288-dw-hdmi
- rockchip,rk3328-dw-hdmi
- rockchip,rk3399-dw-hdmi
reg-io-width:
const: 4
clocks:
minItems: 2
maxItems: 5
items:
- {}
- {}
# The next three clocks are all optional, but shall be specified in this
# order when present.
- description: The HDMI CEC controller main clock
- description: Power for GRF IO
- description: External clock for some HDMI PHY
clock-names:
minItems: 2
maxItems: 5
items:
- {}
- {}
- enum:
- cec
- grf
- vpll
- enum:
- grf
- vpll
- const: vpll
ddc-i2c-bus:
$ref: /schemas/types.yaml#/definitions/phandle
description:
The HDMI DDC bus can be connected to either a system I2C master or the
functionally-reduced I2C master contained in the DWC HDMI. When connected
to a system I2C master this property contains a phandle to that I2C
master controller.
phys:
maxItems: 1
description: The HDMI PHY
phy-names:
const: hdmi
pinctrl-names:
description:
The unwedge pinctrl entry shall drive the DDC SDA line low. This is
intended to work around a hardware errata that can cause the DDC I2C
bus to be wedged.
items:
- const: default
- const: unwedge
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: Input of the DWC HDMI TX
properties:
endpoint@0:
$ref: /schemas/graph.yaml#/properties/endpoint
description: Connection to the VOPB
endpoint@1:
$ref: /schemas/graph.yaml#/properties/endpoint
description: Connection to the VOPL
required:
- endpoint@0
- endpoint@1
required:
- port
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
phandle to the GRF to mux vopl/vopb.
required:
- compatible
- reg
- reg-io-width
- clocks
- clock-names
- interrupts
- ports
- rockchip,grf
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/rk3288-cru.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
hdmi: hdmi@ff980000 {
compatible = "rockchip,rk3288-dw-hdmi";
reg = <0xff980000 0x20000>;
reg-io-width = <4>;
ddc-i2c-bus = <&i2c5>;
rockchip,grf = <&grf>;
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
clock-names = "iahb", "isfr";
ports {
port {
#address-cells = <1>;
#size-cells = <0>;
hdmi_in_vopb: endpoint@0 {
reg = <0>;
remote-endpoint = <&vopb_out_hdmi>;
};
hdmi_in_vopl: endpoint@1 {
reg = <1>;
remote-endpoint = <&vopl_out_hdmi>;
};
};
};
};
...

6
Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
View File

@@ -10,19 +10,19 @@ Required properties:
- reg: I3C master registers
Mandatory properties defined by the generic binding (see
Documentation/devicetree/bindings/i3c/i3c.txt for more details):
Documentation/devicetree/bindings/i3c/i3c.yaml for more details):
- #address-cells: shall be set to 1
- #size-cells: shall be set to 0
Optional properties defined by the generic binding (see
Documentation/devicetree/bindings/i3c/i3c.txt for more details):
Documentation/devicetree/bindings/i3c/i3c.yaml for more details):
- i2c-scl-hz
- i3c-scl-hz
I3C device connected on the bus follow the generic description (see
Documentation/devicetree/bindings/i3c/i3c.txt for more details).
Documentation/devicetree/bindings/i3c/i3c.yaml for more details).
Example:

6
Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.txt
View File

@@ -9,19 +9,19 @@ Required properties:
- reg: Offset and length of I3C master registers
Mandatory properties defined by the generic binding (see
Documentation/devicetree/bindings/i3c/i3c.txt for more details):
Documentation/devicetree/bindings/i3c/i3c.yaml for more details):
- #address-cells: shall be set to 3
- #size-cells: shall be set to 0
Optional properties defined by the generic binding (see
Documentation/devicetree/bindings/i3c/i3c.txt for more details):
Documentation/devicetree/bindings/i3c/i3c.yaml for more details):
- i2c-scl-hz
- i3c-scl-hz
I3C device connected on the bus follow the generic description (see
Documentation/devicetree/bindings/i3c/i3c.txt for more details).
Documentation/devicetree/bindings/i3c/i3c.yaml for more details).
Example:

16
Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
View File

@@ -20,16 +20,12 @@ properties:
- const: allwinner,sun5i-a13-ir
- const: allwinner,sun6i-a31-ir
- items:
- const: allwinner,sun8i-a83t-ir
- const: allwinner,sun6i-a31-ir
- items:
- const: allwinner,sun8i-r40-ir
- const: allwinner,sun6i-a31-ir
- items:
- const: allwinner,sun50i-a64-ir
- const: allwinner,sun6i-a31-ir
- items:
- const: allwinner,sun50i-h6-ir
- enum:
- allwinner,sun8i-a83t-ir
- allwinner,sun8i-r40-ir
- allwinner,sun50i-a64-ir
- allwinner,sun50i-h6-ir
- allwinner,sun50i-h616-ir
- const: allwinner,sun6i-a31-ir
reg:

2
Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
View File

@@ -19,7 +19,7 @@ Required properties:
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
for details.
- iommus: should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
Example:

2
Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
View File

@@ -17,7 +17,7 @@ Required properties:
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
for details.
- iommus: should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
Example:

2
Documentation/devicetree/bindings/media/mediatek-mdp.txt
View File

@@ -25,7 +25,7 @@ Required properties (DMA function blocks, child node):
"mediatek,mt8173-mdp-wdma"
"mediatek,mt8173-mdp-wrot"
- iommus: should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
- mediatek,larb: must contain the local arbiters in the current Socs, see
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml

57
Documentation/devicetree/bindings/media/mediatek-vcodec.txt
View File

@@ -4,7 +4,9 @@ Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
supports high resolution encoding and decoding functionalities.
Required properties:
- compatible : "mediatek,mt8173-vcodec-enc" for MT8173 encoder
- compatible : must be one of the following string:
"mediatek,mt8173-vcodec-enc-vp8" for mt8173 vp8 encoder.
"mediatek,mt8173-vcodec-enc" for mt8173 avc encoder.
"mediatek,mt8183-vcodec-enc" for MT8183 encoder.
"mediatek,mt8173-vcodec-dec" for MT8173 decoder.
- reg : Physical base address of the video codec registers and length of
@@ -13,12 +15,12 @@ Required properties:
- mediatek,larb : must contain the local arbiters in the current Socs.
- clocks : list of clock specifiers, corresponding to entries in
the clock-names property.
- clock-names: encoder must contain "venc_sel_src", "venc_sel",,
"venc_lt_sel_src", "venc_lt_sel", decoder must contain "vcodecpll",
"univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
"venc_lt_sel", "vdec_bus_clk_src".
- clock-names: avc encoder must contain "venc_sel", vp8 encoder must
contain "venc_lt_sel", decoder must contain "vcodecpll", "univpll_d2",
"clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll", "venc_lt_sel",
"vdec_bus_clk_src".
- iommus : should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
One of the two following nodes:
- mediatek,vpu : the node of the video processor unit, if using VPU.
@@ -80,14 +82,10 @@ vcodec_dec: vcodec@16000000 {
assigned-clock-rates = <0>, <0>, <0>, <1482000000>, <800000000>;
};
vcodec_enc: vcodec@18002000 {
vcodec_enc_avc: vcodec@18002000 {
compatible = "mediatek,mt8173-vcodec-enc";
reg = <0 0x18002000 0 0x1000>, /*VENC_SYS*/
<0 0x19002000 0 0x1000>; /*VENC_LT_SYS*/
interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
<GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
mediatek,larb = <&larb3>,
<&larb5>;
reg = <0 0x18002000 0 0x1000>;
interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
iommus = <&iommu M4U_PORT_VENC_RCPU>,
<&iommu M4U_PORT_VENC_REC>,
<&iommu M4U_PORT_VENC_BSDMA>,
@@ -98,8 +96,20 @@ vcodec_dec: vcodec@16000000 {
<&iommu M4U_PORT_VENC_REF_LUMA>,
<&iommu M4U_PORT_VENC_REF_CHROMA>,
<&iommu M4U_PORT_VENC_NBM_RDMA>,
<&iommu M4U_PORT_VENC_NBM_WDMA>,
<&iommu M4U_PORT_VENC_RCPU_SET2>,
<&iommu M4U_PORT_VENC_NBM_WDMA>;
mediatek,larb = <&larb3>;
mediatek,vpu = <&vpu>;
clocks = <&topckgen CLK_TOP_VENC_SEL>;
clock-names = "venc_sel";
assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>;
};
vcodec_enc_vp8: vcodec@19002000 {
compatible = "mediatek,mt8173-vcodec-enc-vp8";
reg = <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
interrupts = <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
iommus = <&iommu M4U_PORT_VENC_RCPU_SET2>,
<&iommu M4U_PORT_VENC_REC_FRM_SET2>,
<&iommu M4U_PORT_VENC_BSDMA_SET2>,
<&iommu M4U_PORT_VENC_SV_COMA_SET2>,
@@ -108,17 +118,10 @@ vcodec_dec: vcodec@16000000 {
<&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
<&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
<&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
mediatek,larb = <&larb5>;
mediatek,vpu = <&vpu>;
clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
<&topckgen CLK_TOP_VENC_SEL>,
<&topckgen CLK_TOP_UNIVPLL1_D2>,
<&topckgen CLK_TOP_VENC_LT_SEL>;
clock-names = "venc_sel_src",
"venc_sel",
"venc_lt_sel_src",
"venc_lt_sel";
assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>,
<&topckgen CLK_TOP_VENC_LT_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_VENCPLL_D2>,
<&topckgen CLK_TOP_UNIVPLL1_D2>;
clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
clock-names = "venc_lt_sel";
assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>;
};

98
Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
View File

@@ -4,14 +4,19 @@
$id: http://devicetree.org/schemas/media/nxp,imx7-mipi-csi2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX7 Mipi CSI2
title: NXP i.MX7 MIPI CSI-2 receiver
maintainers:
- Rui Miguel Silva <rmfrfs@gmail.com>
description: |
This is the device node for the MIPI CSI-2 receiver core in i.MX7 soc. It is
compatible with previous version of samsung d-phy.
description: |-
The NXP i.MX7 SoC family includes a MIPI CSI-2 receiver IP core, documented
as "CSIS V3.3". The IP core seems to originate from Samsung, and may be
compatible with some of the Exynos4 ad S5P SoCs.
While the CSI-2 receiver is separate from the MIPI D-PHY IP core, the PHY is
completely wrapped by the CSIS and doesn't expose a control interface of its
own. This binding thus covers both IP cores.
properties:
compatible:
@@ -24,8 +29,10 @@ properties:
maxItems: 1
clocks:
minItems: 3
maxItems: 3
items:
- description: The peripheral clock (a.k.a. APB clock)
- description: The external clock (optionally used as the pixel clock)
- description: The MIPI D-PHY clock
clock-names:
items:
@@ -37,26 +44,16 @@ properties:
maxItems: 1
phy-supply:
description:
Phandle to a regulator that provides power to the PHY. This
regulator will be managed during the PHY power on/off sequence.
description: The MIPI D-PHY digital power supply
resets:
maxItems: 1
reset-names:
const: mrst
items:
- description: MIPI D-PHY slave reset
clock-frequency:
description:
The IP main (system bus) clock frequency in Hertz
description: The desired external clock ("wrap") frequency, in Hz
default: 166000000
fsl,csis-hs-settle:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Differential receiver (HS-RX) settle time
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -98,7 +95,6 @@ required:
- power-domains
- phy-supply
- resets
- reset-names
- ports
additionalProperties: false
@@ -111,43 +107,41 @@ examples:
#include <dt-bindings/reset/imx7-reset.h>
mipi_csi: mipi-csi@30750000 {
compatible = "fsl,imx7-mipi-csi2";
reg = <0x30750000 0x10000>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
compatible = "fsl,imx7-mipi-csi2";
reg = <0x30750000 0x10000>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_IPG_ROOT_CLK>,
<&clks IMX7D_MIPI_CSI_ROOT_CLK>,
<&clks IMX7D_MIPI_DPHY_ROOT_CLK>;
clock-names = "pclk", "wrap", "phy";
clock-frequency = <166000000>;
clocks = <&clks IMX7D_IPG_ROOT_CLK>,
<&clks IMX7D_MIPI_CSI_ROOT_CLK>,
<&clks IMX7D_MIPI_DPHY_ROOT_CLK>;
clock-names = "pclk", "wrap", "phy";
clock-frequency = <166000000>;
power-domains = <&pgc_mipi_phy>;
phy-supply = <&reg_1p0d>;
resets = <&src IMX7_RESET_MIPI_PHY_MRST>;
reset-names = "mrst";
fsl,csis-hs-settle = <3>;
power-domains = <&pgc_mipi_phy>;
phy-supply = <&reg_1p0d>;
resets = <&src IMX7_RESET_MIPI_PHY_MRST>;
ports {
#address-cells = <1>;
#size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
port@0 {
reg = <0>;
mipi_from_sensor: endpoint {
remote-endpoint = <&ov2680_to_mipi>;
data-lanes = <1>;
};
};
port@1 {
reg = <1>;
mipi_vc0_to_csi_mux: endpoint {
remote-endpoint = <&csi_mux_from_mipi_vc0>;
};
};
mipi_from_sensor: endpoint {
remote-endpoint = <&ov2680_to_mipi>;
data-lanes = <1>;
};
};
port@1 {
reg = <1>;
mipi_vc0_to_csi_mux: endpoint {
remote-endpoint = <&csi_mux_from_mipi_vc0>;
};
};
};
};
...

84
Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml Normal file
View File

@@ -0,0 +1,84 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: i.MX8QXP/QM JPEG decoder/encoder Device Tree Bindings
maintainers:
- Mirela Rabulea <mirela.rabulea@nxp.com>
description: |-
The JPEG decoder/encoder present in iMX8QXP and iMX8QM SoCs is an
ISO/IEC 10918-1 JPEG standard compliant decoder/encoder, for Baseline
and Extended Sequential DCT modes.
properties:
compatible:
items:
- enum:
# JPEG decoder
- nxp,imx8qxp-jpgdec
# JPEG encoder
- nxp,imx8qxp-jpgenc
reg:
maxItems: 1
interrupts:
description: |
There are 4 slots available in the IP, which the driver may use
If a certain slot is used, it should have an associated interrupt
The interrupt with index i is assumed to be for slot i
minItems: 1 # At least one slot is needed by the driver
maxItems: 4 # The IP has 4 slots available for use
power-domains:
description:
List of phandle and PM domain specifier as documented in
Documentation/devicetree/bindings/power/power_domain.txt
minItems: 2 # Wrapper and 1 slot
maxItems: 5 # Wrapper and 4 slots
required:
- compatible
- reg
- interrupts
- power-domains
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/firmware/imx/rsrc.h>
jpegdec: jpegdec@58400000 {
compatible = "nxp,imx8qxp-jpgdec";
reg = <0x58400000 0x00050000 >;
interrupts = <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&pd IMX_SC_R_MJPEG_DEC_MP>,
<&pd IMX_SC_R_MJPEG_DEC_S0>,
<&pd IMX_SC_R_MJPEG_DEC_S1>,
<&pd IMX_SC_R_MJPEG_DEC_S2>,
<&pd IMX_SC_R_MJPEG_DEC_S3>;
};
jpegenc: jpegenc@58450000 {
compatible = "nxp,imx8qxp-jpgenc";
reg = <0x58450000 0x00050000 >;
interrupts = <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&pd IMX_SC_R_MJPEG_ENC_MP>,
<&pd IMX_SC_R_MJPEG_ENC_S0>,
<&pd IMX_SC_R_MJPEG_ENC_S1>,
<&pd IMX_SC_R_MJPEG_ENC_S2>,
<&pd IMX_SC_R_MJPEG_ENC_S3>;
};
...

236
Documentation/devicetree/bindings/media/qcom,camss.txt
View File

@@ -1,236 +0,0 @@
Qualcomm Camera Subsystem
* Properties
- compatible:
Usage: required
Value type: <stringlist>
Definition: Should contain one of:
- "qcom,msm8916-camss"
- "qcom,msm8996-camss"
- "qcom,sdm660-camss"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: Register ranges as listed in the reg-names property.
- reg-names:
Usage: required
Value type: <stringlist>
Definition: Should contain the following entries:
- "csiphy0"
- "csiphy0_clk_mux"
- "csiphy1"
- "csiphy1_clk_mux"
- "csiphy2" (8996 only)
- "csiphy2_clk_mux" (8996 only)
- "csid0"
- "csid1"
- "csid2" (8996 only)
- "csid3" (8996 only)
- "ispif"
- "csi_clk_mux"
- "vfe0"
- "vfe1" (8996 only)
- interrupts:
Usage: required
Value type: <prop-encoded-array>
Definition: Interrupts as listed in the interrupt-names property.
- interrupt-names:
Usage: required
Value type: <stringlist>
Definition: Should contain the following entries:
- "csiphy0"
- "csiphy1"
- "csiphy2" (8996 only)
- "csid0"
- "csid1"
- "csid2" (8996 only)
- "csid3" (8996 only)
- "ispif"
- "vfe0"
- "vfe1" (8996 only)
- power-domains:
Usage: required
Value type: <prop-encoded-array>
Definition: A phandle and power domain specifier pairs to the
power domain which is responsible for collapsing
and restoring power to the peripheral.
- clocks:
Usage: required
Value type: <prop-encoded-array>
Definition: A list of phandle and clock specifier pairs as listed
in clock-names property.
- clock-names:
Usage: required
Value type: <stringlist>
Definition: Should contain the following entries:
- "top_ahb"
- "throttle_axi" (660 only)
- "ispif_ahb"
- "csiphy0_timer"
- "csiphy1_timer"
- "csiphy2_timer" (8996 only)
- "csiphy_ahb2crif" (660 only)
- "csi0_ahb"
- "csi0"
- "csi0_phy"
- "csi0_pix"
- "csi0_rdi"
- "cphy_csid0" (660 only)
- "csi1_ahb"
- "csi1"
- "csi1_phy"
- "csi1_pix"
- "csi1_rdi"
- "cphy_csid1" (660 only)
- "csi2_ahb" (8996 only)
- "csi2" (8996 only)
- "csi2_phy" (8996 only)
- "csi2_pix" (8996 only)
- "csi2_rdi" (8996 only)
- "cphy_csid2" (660 only)
- "csi3_ahb" (8996 only)
- "csi3" (8996 only)
- "csi3_phy" (8996 only)
- "csi3_pix" (8996 only)
- "csi3_rdi" (8996 only)
- "cphy_csid3" (660 only)
- "ahb"
- "vfe0"
- "csi_vfe0"
- "vfe0_ahb", (8996 only)
- "vfe0_stream", (8996 only)
- "vfe1", (8996 only)
- "csi_vfe1", (8996 only)
- "vfe1_ahb", (8996 only)
- "vfe1_stream", (8996 only)
- "vfe_ahb"
- "vfe_axi"
- vdda-supply:
Usage: required
Value type: <phandle>
Definition: A phandle to voltage supply for CSI2.
- iommus:
Usage: required
Value type: <prop-encoded-array>
Definition: A list of phandle and IOMMU specifier pairs.
* Nodes
- ports:
Usage: required
Definition: As described in video-interfaces.txt in same directory.
Properties:
- reg:
Usage: required
Value type: <u32>
Definition: Selects CSI2 PHY interface - PHY0, PHY1
or PHY2 (8996 only)
Endpoint node properties:
- clock-lanes:
Usage: required
Value type: <u32>
Definition: The physical clock lane index. On 8916
the value must always be <1> as the physical
clock lane is lane 1. On 8996 the value must
always be <7> as the hardware supports D-PHY
and C-PHY, indexes are in a common set and
D-PHY physical clock lane is labeled as 7.
- data-lanes:
Usage: required
Value type: <prop-encoded-array>
Definition: An array of physical data lanes indexes.
Position of an entry determines the logical
lane number, while the value of an entry
indicates physical lane index. Lane swapping
is supported. Physical lane indexes for
8916: 0, 2, 3, 4; for 8996: 0, 1, 2, 3.
* An Example
camss: camss@1b00000 {
compatible = "qcom,msm8916-camss";
reg = <0x1b0ac00 0x200>,
<0x1b00030 0x4>,
<0x1b0b000 0x200>,
<0x1b00038 0x4>,
<0x1b08000 0x100>,
<0x1b08400 0x100>,
<0x1b0a000 0x500>,
<0x1b00020 0x10>,
<0x1b10000 0x1000>;
reg-names = "csiphy0",
"csiphy0_clk_mux",
"csiphy1",
"csiphy1_clk_mux",
"csid0",
"csid1",
"ispif",
"csi_clk_mux",
"vfe0";
interrupts = <GIC_SPI 78 0>,
<GIC_SPI 79 0>,
<GIC_SPI 51 0>,
<GIC_SPI 52 0>,
<GIC_SPI 55 0>,
<GIC_SPI 57 0>;
interrupt-names = "csiphy0",
"csiphy1",
"csid0",
"csid1",
"ispif",
"vfe0";
power-domains = <&gcc VFE_GDSC>;
clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
<&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
<&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
<&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
<&gcc GCC_CAMSS_CSI0_AHB_CLK>,
<&gcc GCC_CAMSS_CSI0_CLK>,
<&gcc GCC_CAMSS_CSI0PHY_CLK>,
<&gcc GCC_CAMSS_CSI0PIX_CLK>,
<&gcc GCC_CAMSS_CSI0RDI_CLK>,
<&gcc GCC_CAMSS_CSI1_AHB_CLK>,
<&gcc GCC_CAMSS_CSI1_CLK>,
<&gcc GCC_CAMSS_CSI1PHY_CLK>,
<&gcc GCC_CAMSS_CSI1PIX_CLK>,
<&gcc GCC_CAMSS_CSI1RDI_CLK>,
<&gcc GCC_CAMSS_AHB_CLK>,
<&gcc GCC_CAMSS_VFE0_CLK>,
<&gcc GCC_CAMSS_CSI_VFE0_CLK>,
<&gcc GCC_CAMSS_VFE_AHB_CLK>,
<&gcc GCC_CAMSS_VFE_AXI_CLK>;
clock-names = "top_ahb",
"ispif_ahb",
"csiphy0_timer",
"csiphy1_timer",
"csi0_ahb",
"csi0",
"csi0_phy",
"csi0_pix",
"csi0_rdi",
"csi1_ahb",
"csi1",
"csi1_phy",
"csi1_pix",
"csi1_rdi",
"ahb",
"vfe0",
"csi_vfe0",
"vfe_ahb",
"vfe_axi";
vdda-supply = <&pm8916_l2>;
iommus = <&apps_iommu 3>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
csiphy0_ep: endpoint {
clock-lanes = <1>;
data-lanes = <0 2>;
remote-endpoint = <&ov5645_ep>;
};
};
};
};

256
Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml Normal file
View File

@@ -0,0 +1,256 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/qcom,msm8916-camss.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm CAMSS ISP
maintainers:
- Robert Foss <robert.foss@linaro.org>
- Todor Tomov <todor.too@gmail.com>
description: |
The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
properties:
compatible:
const: qcom,msm8916-camss
clocks:
minItems: 19
maxItems: 19
clock-names:
items:
- const: top_ahb
- const: ispif_ahb
- const: csiphy0_timer
- const: csiphy1_timer
- const: csi0_ahb
- const: csi0
- const: csi0_phy
- const: csi0_pix
- const: csi0_rdi
- const: csi1_ahb
- const: csi1
- const: csi1_phy
- const: csi1_pix
- const: csi1_rdi
- const: ahb
- const: vfe0
- const: csi_vfe0
- const: vfe_ahb
- const: vfe_axi
interrupts:
minItems: 6
maxItems: 6
interrupt-names:
items:
- const: csiphy0
- const: csiphy1
- const: csid0
- const: csid1
- const: ispif
- const: vfe0
iommus:
maxItems: 1
power-domains:
items:
- description: VFE GDSC - Video Front End, Global Distributed Switch Controller.
ports:
$ref: /schemas/graph.yaml#/properties/ports
description:
CSI input ports.
properties:
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 1
data-lanes:
description:
An array of physical data lanes indexes.
Position of an entry determines the logical
lane number, while the value of an entry
indicates physical lane index. Lane swapping
is supported. Physical lane indexes;
0, 2, 3, 4.
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
port@1:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 1
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
reg:
minItems: 9
maxItems: 9
reg-names:
items:
- const: csiphy0
- const: csiphy0_clk_mux
- const: csiphy1
- const: csiphy1_clk_mux
- const: csid0
- const: csid1
- const: ispif
- const: csi_clk_mux
- const: vfe0
vdda-supply:
description:
Definition of the regulator used as analog power supply.
required:
- clock-names
- clocks
- compatible
- interrupt-names
- interrupts
- iommus
- power-domains
- reg
- reg-names
- vdda-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-msm8916.h>
camss: camss@1b00000 {
compatible = "qcom,msm8916-camss";
clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
<&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
<&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
<&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
<&gcc GCC_CAMSS_CSI0_AHB_CLK>,
<&gcc GCC_CAMSS_CSI0_CLK>,
<&gcc GCC_CAMSS_CSI0PHY_CLK>,
<&gcc GCC_CAMSS_CSI0PIX_CLK>,
<&gcc GCC_CAMSS_CSI0RDI_CLK>,
<&gcc GCC_CAMSS_CSI1_AHB_CLK>,
<&gcc GCC_CAMSS_CSI1_CLK>,
<&gcc GCC_CAMSS_CSI1PHY_CLK>,
<&gcc GCC_CAMSS_CSI1PIX_CLK>,
<&gcc GCC_CAMSS_CSI1RDI_CLK>,
<&gcc GCC_CAMSS_AHB_CLK>,
<&gcc GCC_CAMSS_VFE0_CLK>,
<&gcc GCC_CAMSS_CSI_VFE0_CLK>,
<&gcc GCC_CAMSS_VFE_AHB_CLK>,
<&gcc GCC_CAMSS_VFE_AXI_CLK>;
clock-names = "top_ahb",
"ispif_ahb",
"csiphy0_timer",
"csiphy1_timer",
"csi0_ahb",
"csi0",
"csi0_phy",
"csi0_pix",
"csi0_rdi",
"csi1_ahb",
"csi1",
"csi1_phy",
"csi1_pix",
"csi1_rdi",
"ahb",
"vfe0",
"csi_vfe0",
"vfe_ahb",
"vfe_axi";
interrupts = <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 79 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 51 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 52 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 55 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "csiphy0",
"csiphy1",
"csid0",
"csid1",
"ispif",
"vfe0";
iommus = <&apps_iommu 3>;
power-domains = <&gcc VFE_GDSC>;
reg = <0x01b0ac00 0x200>,
<0x01b00030 0x4>,
<0x01b0b000 0x200>,
<0x01b00038 0x4>,
<0x01b08000 0x100>,
<0x01b08400 0x100>,
<0x01b0a000 0x500>,
<0x01b00020 0x10>,
<0x01b10000 0x1000>;
reg-names = "csiphy0",
"csiphy0_clk_mux",
"csiphy1",
"csiphy1_clk_mux",
"csid0",
"csid1",
"ispif",
"csi_clk_mux",
"vfe0";
vdda-supply = <&reg_2v8>;
ports {
#address-cells = <1>;
#size-cells = <0>;
};
};

387
Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml Normal file
View File

@@ -0,0 +1,387 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/qcom,msm8996-camss.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm CAMSS ISP
maintainers:
- Robert Foss <robert.foss@linaro.org>
- Todor Tomov <todor.too@gmail.com>
description: |
The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
properties:
compatible:
const: qcom,msm8996-camss
clocks:
minItems: 36
maxItems: 36
clock-names:
items:
- const: top_ahb
- const: ispif_ahb
- const: csiphy0_timer
- const: csiphy1_timer
- const: csiphy2_timer
- const: csi0_ahb
- const: csi0
- const: csi0_phy
- const: csi0_pix
- const: csi0_rdi
- const: csi1_ahb
- const: csi1
- const: csi1_phy
- const: csi1_pix
- const: csi1_rdi
- const: csi2_ahb
- const: csi2
- const: csi2_phy
- const: csi2_pix
- const: csi2_rdi
- const: csi3_ahb
- const: csi3
- const: csi3_phy
- const: csi3_pix
- const: csi3_rdi
- const: ahb
- const: vfe0
- const: csi_vfe0
- const: vfe0_ahb
- const: vfe0_stream
- const: vfe1
- const: csi_vfe1
- const: vfe1_ahb
- const: vfe1_stream
- const: vfe_ahb
- const: vfe_axi
interrupts:
minItems: 10
maxItems: 10
interrupt-names:
items:
- const: csiphy0
- const: csiphy1
- const: csiphy2
- const: csid0
- const: csid1
- const: csid2
- const: csid3
- const: ispif
- const: vfe0
- const: vfe1
iommus:
maxItems: 4
power-domains:
items:
- description: VFE0 GDSC - Video Front End, Global Distributed Switch Controller.
- description: VFE1 GDSC - Video Front End, Global Distributed Switch Controller.
ports:
$ref: /schemas/graph.yaml#/properties/ports
description:
CSI input ports.
properties:
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 7
data-lanes:
description:
An array of physical data lanes indexes.
Position of an entry determines the logical
lane number, while the value of an entry
indicates physical lane index. Lane swapping
is supported. Physical lane indexes are;
0, 1, 2, 3
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
port@1:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 7
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
port@2:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 7
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
port@3:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 7
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
reg:
minItems: 14
maxItems: 14
reg-names:
items:
- const: csiphy0
- const: csiphy0_clk_mux
- const: csiphy1
- const: csiphy1_clk_mux
- const: csiphy2
- const: csiphy2_clk_mux
- const: csid0
- const: csid1
- const: csid2
- const: csid3
- const: ispif
- const: csi_clk_mux
- const: vfe0
- const: vfe1
vdda-supply:
description:
Definition of the regulator used as analog power supply.
required:
- clock-names
- clocks
- compatible
- interrupt-names
- interrupts
- iommus
- power-domains
- reg
- reg-names
- vdda-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-msm8996.h>
#include <dt-bindings/clock/qcom,mmcc-msm8996.h>
camss: camss@a00000 {
compatible = "qcom,msm8996-camss";
clocks = <&mmcc CAMSS_TOP_AHB_CLK>,
<&mmcc CAMSS_ISPIF_AHB_CLK>,
<&mmcc CAMSS_CSI0PHYTIMER_CLK>,
<&mmcc CAMSS_CSI1PHYTIMER_CLK>,
<&mmcc CAMSS_CSI2PHYTIMER_CLK>,
<&mmcc CAMSS_CSI0_AHB_CLK>,
<&mmcc CAMSS_CSI0_CLK>,
<&mmcc CAMSS_CSI0PHY_CLK>,
<&mmcc CAMSS_CSI0PIX_CLK>,
<&mmcc CAMSS_CSI0RDI_CLK>,
<&mmcc CAMSS_CSI1_AHB_CLK>,
<&mmcc CAMSS_CSI1_CLK>,
<&mmcc CAMSS_CSI1PHY_CLK>,
<&mmcc CAMSS_CSI1PIX_CLK>,
<&mmcc CAMSS_CSI1RDI_CLK>,
<&mmcc CAMSS_CSI2_AHB_CLK>,
<&mmcc CAMSS_CSI2_CLK>,
<&mmcc CAMSS_CSI2PHY_CLK>,
<&mmcc CAMSS_CSI2PIX_CLK>,
<&mmcc CAMSS_CSI2RDI_CLK>,
<&mmcc CAMSS_CSI3_AHB_CLK>,
<&mmcc CAMSS_CSI3_CLK>,
<&mmcc CAMSS_CSI3PHY_CLK>,
<&mmcc CAMSS_CSI3PIX_CLK>,
<&mmcc CAMSS_CSI3RDI_CLK>,
<&mmcc CAMSS_AHB_CLK>,
<&mmcc CAMSS_VFE0_CLK>,
<&mmcc CAMSS_CSI_VFE0_CLK>,
<&mmcc CAMSS_VFE0_AHB_CLK>,
<&mmcc CAMSS_VFE0_STREAM_CLK>,
<&mmcc CAMSS_VFE1_CLK>,
<&mmcc CAMSS_CSI_VFE1_CLK>,
<&mmcc CAMSS_VFE1_AHB_CLK>,
<&mmcc CAMSS_VFE1_STREAM_CLK>,
<&mmcc CAMSS_VFE_AHB_CLK>,
<&mmcc CAMSS_VFE_AXI_CLK>;
clock-names = "top_ahb",
"ispif_ahb",
"csiphy0_timer",
"csiphy1_timer",
"csiphy2_timer",
"csi0_ahb",
"csi0",
"csi0_phy",
"csi0_pix",
"csi0_rdi",
"csi1_ahb",
"csi1",
"csi1_phy",
"csi1_pix",
"csi1_rdi",
"csi2_ahb",
"csi2",
"csi2_phy",
"csi2_pix",
"csi2_rdi",
"csi3_ahb",
"csi3",
"csi3_phy",
"csi3_pix",
"csi3_rdi",
"ahb",
"vfe0",
"csi_vfe0",
"vfe0_ahb",
"vfe0_stream",
"vfe1",
"csi_vfe1",
"vfe1_ahb",
"vfe1_stream",
"vfe_ahb",
"vfe_axi";
interrupts = <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 79 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 80 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 296 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 297 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 298 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 299 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 309 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 314 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 315 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "csiphy0",
"csiphy1",
"csiphy2",
"csid0",
"csid1",
"csid2",
"csid3",
"ispif",
"vfe0",
"vfe1";
iommus = <&vfe_smmu 0>,
<&vfe_smmu 1>,
<&vfe_smmu 2>,
<&vfe_smmu 3>;
power-domains = <&mmcc VFE0_GDSC>,
<&mmcc VFE1_GDSC>;
reg = <0x00a34000 0x1000>,
<0x00a00030 0x4>,
<0x00a35000 0x1000>,
<0x00a00038 0x4>,
<0x00a36000 0x1000>,
<0x00a00040 0x4>,
<0x00a30000 0x100>,
<0x00a30400 0x100>,
<0x00a30800 0x100>,
<0x00a30c00 0x100>,
<0x00a31000 0x500>,
<0x00a00020 0x10>,
<0x00a10000 0x1000>,
<0x00a14000 0x1000>;
reg-names = "csiphy0",
"csiphy0_clk_mux",
"csiphy1",
"csiphy1_clk_mux",
"csiphy2",
"csiphy2_clk_mux",
"csid0",
"csid1",
"csid2",
"csid3",
"ispif",
"csi_clk_mux",
"vfe0",
"vfe1";
vdda-supply = <&reg_2v8>;
ports {
#address-cells = <1>;
#size-cells = <0>;
};
};

398
Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml Normal file
View File

@@ -0,0 +1,398 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/qcom,sdm660-camss.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm CAMSS ISP
maintainers:
- Robert Foss <robert.foss@linaro.org>
- AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
description: |
The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
properties:
compatible:
const: qcom,sdm660-camss
clocks:
minItems: 42
maxItems: 42
clock-names:
items:
- const: ahb
- const: cphy_csid0
- const: cphy_csid1
- const: cphy_csid2
- const: cphy_csid3
- const: csi0_ahb
- const: csi0
- const: csi0_phy
- const: csi0_pix
- const: csi0_rdi
- const: csi1_ahb
- const: csi1
- const: csi1_phy
- const: csi1_pix
- const: csi1_rdi
- const: csi2_ahb
- const: csi2
- const: csi2_phy
- const: csi2_pix
- const: csi2_rdi
- const: csi3_ahb
- const: csi3
- const: csi3_phy
- const: csi3_pix
- const: csi3_rdi
- const: csiphy0_timer
- const: csiphy1_timer
- const: csiphy2_timer
- const: csiphy_ahb2crif
- const: csi_vfe0
- const: csi_vfe1
- const: ispif_ahb
- const: throttle_axi
- const: top_ahb
- const: vfe0_ahb
- const: vfe0
- const: vfe0_stream
- const: vfe1_ahb
- const: vfe1
- const: vfe1_stream
- const: vfe_ahb
- const: vfe_axi
interrupts:
minItems: 10
maxItems: 10
interrupt-names:
items:
- const: csid0
- const: csid1
- const: csid2
- const: csid3
- const: csiphy0
- const: csiphy1
- const: csiphy2
- const: ispif
- const: vfe0
- const: vfe1
iommus:
maxItems: 4
power-domains:
items:
- description: VFE0 GDSC - Video Front End, Global Distributed Switch Controller.
- description: VFE1 GDSC - Video Front End, Global Distributed Switch Controller.
ports:
$ref: /schemas/graph.yaml#/properties/ports
description:
CSI input ports.
properties:
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 7
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
port@1:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 7
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
port@2:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 7
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
port@3:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 7
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
reg:
minItems: 14
maxItems: 14
reg-names:
items:
- const: csi_clk_mux
- const: csid0
- const: csid1
- const: csid2
- const: csid3
- const: csiphy0
- const: csiphy0_clk_mux
- const: csiphy1
- const: csiphy1_clk_mux
- const: csiphy2
- const: csiphy2_clk_mux
- const: ispif
- const: vfe0
- const: vfe1
vdda-supply:
description:
Definition of the regulator used as analog power supply.
required:
- clock-names
- clocks
- compatible
- interrupt-names
- interrupts
- iommus
- power-domains
- reg
- reg-names
- vdda-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-sdm660.h>
#include <dt-bindings/clock/qcom,mmcc-sdm660.h>
camss: camss@ca00000 {
compatible = "qcom,sdm660-camss";
clocks = <&mmcc CAMSS_AHB_CLK>,
<&mmcc CAMSS_CPHY_CSID0_CLK>,
<&mmcc CAMSS_CPHY_CSID1_CLK>,
<&mmcc CAMSS_CPHY_CSID2_CLK>,
<&mmcc CAMSS_CPHY_CSID3_CLK>,
<&mmcc CAMSS_CSI0_AHB_CLK>,
<&mmcc CAMSS_CSI0_CLK>,
<&mmcc CAMSS_CPHY_CSID0_CLK>,
<&mmcc CAMSS_CSI0PIX_CLK>,
<&mmcc CAMSS_CSI0RDI_CLK>,
<&mmcc CAMSS_CSI1_AHB_CLK>,
<&mmcc CAMSS_CSI1_CLK>,
<&mmcc CAMSS_CPHY_CSID1_CLK>,
<&mmcc CAMSS_CSI1PIX_CLK>,
<&mmcc CAMSS_CSI1RDI_CLK>,
<&mmcc CAMSS_CSI2_AHB_CLK>,
<&mmcc CAMSS_CSI2_CLK>,
<&mmcc CAMSS_CPHY_CSID2_CLK>,
<&mmcc CAMSS_CSI2PIX_CLK>,
<&mmcc CAMSS_CSI2RDI_CLK>,
<&mmcc CAMSS_CSI3_AHB_CLK>,
<&mmcc CAMSS_CSI3_CLK>,
<&mmcc CAMSS_CPHY_CSID3_CLK>,
<&mmcc CAMSS_CSI3PIX_CLK>,
<&mmcc CAMSS_CSI3RDI_CLK>,
<&mmcc CAMSS_CSI0PHYTIMER_CLK>,
<&mmcc CAMSS_CSI1PHYTIMER_CLK>,
<&mmcc CAMSS_CSI2PHYTIMER_CLK>,
<&mmcc CSIPHY_AHB2CRIF_CLK>,
<&mmcc CAMSS_CSI_VFE0_CLK>,
<&mmcc CAMSS_CSI_VFE1_CLK>,
<&mmcc CAMSS_ISPIF_AHB_CLK>,
<&mmcc THROTTLE_CAMSS_AXI_CLK>,
<&mmcc CAMSS_TOP_AHB_CLK>,
<&mmcc CAMSS_VFE0_AHB_CLK>,
<&mmcc CAMSS_VFE0_CLK>,
<&mmcc CAMSS_VFE0_STREAM_CLK>,
<&mmcc CAMSS_VFE1_AHB_CLK>,
<&mmcc CAMSS_VFE1_CLK>,
<&mmcc CAMSS_VFE1_STREAM_CLK>,
<&mmcc CAMSS_VFE_VBIF_AHB_CLK>,
<&mmcc CAMSS_VFE_VBIF_AXI_CLK>;
clock-names = "ahb",
"cphy_csid0",
"cphy_csid1",
"cphy_csid2",
"cphy_csid3",
"csi0_ahb",
"csi0",
"csi0_phy",
"csi0_pix",
"csi0_rdi",
"csi1_ahb",
"csi1",
"csi1_phy",
"csi1_pix",
"csi1_rdi",
"csi2_ahb",
"csi2",
"csi2_phy",
"csi2_pix",
"csi2_rdi",
"csi3_ahb",
"csi3",
"csi3_phy",
"csi3_pix",
"csi3_rdi",
"csiphy0_timer",
"csiphy1_timer",
"csiphy2_timer",
"csiphy_ahb2crif",
"csi_vfe0",
"csi_vfe1",
"ispif_ahb",
"throttle_axi",
"top_ahb",
"vfe0_ahb",
"vfe0",
"vfe0_stream",
"vfe1_ahb",
"vfe1",
"vfe1_stream",
"vfe_ahb",
"vfe_axi";
interrupts = <GIC_SPI 296 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 297 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 298 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 299 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 78 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 79 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 80 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 309 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 314 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 315 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "csid0",
"csid1",
"csid2",
"csid3",
"csiphy0",
"csiphy1",
"csiphy2",
"ispif",
"vfe0",
"vfe1";
iommus = <&mmss_smmu 0xc00>,
<&mmss_smmu 0xc01>,
<&mmss_smmu 0xc02>,
<&mmss_smmu 0xc03>;
power-domains = <&mmcc CAMSS_VFE0_GDSC>,
<&mmcc CAMSS_VFE1_GDSC>;
reg = <0x0ca00020 0x10>,
<0x0ca30000 0x100>,
<0x0ca30400 0x100>,
<0x0ca30800 0x100>,
<0x0ca30c00 0x100>,
<0x0c824000 0x1000>,
<0x0ca00120 0x4>,
<0x0c825000 0x1000>,
<0x0ca00124 0x4>,
<0x0c826000 0x1000>,
<0x0ca00128 0x4>,
<0x0ca31000 0x500>,
<0x0ca10000 0x1000>,
<0x0ca14000 0x1000>;
reg-names = "csi_clk_mux",
"csid0",
"csid1",
"csid2",
"csid3",
"csiphy0",
"csiphy0_clk_mux",
"csiphy1",
"csiphy1_clk_mux",
"csiphy2",
"csiphy2_clk_mux",
"ispif",
"vfe0",
"vfe1";
vdda-supply = <&reg_2v8>;
ports {
#address-cells = <1>;
#size-cells = <0>;
};
};

371
Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml Normal file
View File

@@ -0,0 +1,371 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/qcom,sdm845-camss.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm CAMSS ISP
maintainers:
- Robert Foss <robert.foss@linaro.org>
description: |
The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
properties:
compatible:
const: qcom,sdm845-camss
clocks:
minItems: 36
maxItems: 36
clock-names:
items:
- const: camnoc_axi
- const: cpas_ahb
- const: cphy_rx_src
- const: csi0
- const: csi0_src
- const: csi1
- const: csi1_src
- const: csi2
- const: csi2_src
- const: csiphy0
- const: csiphy0_timer
- const: csiphy0_timer_src
- const: csiphy1
- const: csiphy1_timer
- const: csiphy1_timer_src
- const: csiphy2
- const: csiphy2_timer
- const: csiphy2_timer_src
- const: csiphy3
- const: csiphy3_timer
- const: csiphy3_timer_src
- const: gcc_camera_ahb
- const: gcc_camera_axi
- const: slow_ahb_src
- const: soc_ahb
- const: vfe0_axi
- const: vfe0
- const: vfe0_cphy_rx
- const: vfe0_src
- const: vfe1_axi
- const: vfe1
- const: vfe1_cphy_rx
- const: vfe1_src
- const: vfe_lite
- const: vfe_lite_cphy_rx
- const: vfe_lite_src
interrupts:
minItems: 10
maxItems: 10
interrupt-names:
items:
- const: csid0
- const: csid1
- const: csid2
- const: csiphy0
- const: csiphy1
- const: csiphy2
- const: csiphy3
- const: vfe0
- const: vfe1
- const: vfe_lite
iommus:
maxItems: 4
power-domains:
items:
- description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
- description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
- description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
ports:
$ref: /schemas/graph.yaml#/properties/ports
description:
CSI input ports.
properties:
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
maxItems: 1
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
port@1:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
items:
- const: 7
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
port@2:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
maxItems: 1
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
port@3:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port for receiving CSI data.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
maxItems: 1
data-lanes:
minItems: 1
maxItems: 4
required:
- clock-lanes
- data-lanes
reg:
minItems: 10
maxItems: 10
reg-names:
items:
- const: csid0
- const: csid1
- const: csid2
- const: csiphy0
- const: csiphy1
- const: csiphy2
- const: csiphy3
- const: vfe0
- const: vfe1
- const: vfe_lite
vdda-supply:
description:
Definition of the regulator used as analog power supply.
required:
- clock-names
- clocks
- compatible
- interrupt-names
- interrupts
- iommus
- power-domains
- reg
- reg-names
- vdda-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,camcc-sdm845.h>
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
camss: camss@a00000 {
compatible = "qcom,sdm845-camss";
clocks = <&clock_camcc CAM_CC_CAMNOC_AXI_CLK>,
<&clock_camcc CAM_CC_CPAS_AHB_CLK>,
<&clock_camcc CAM_CC_CPHY_RX_CLK_SRC>,
<&clock_camcc CAM_CC_IFE_0_CSID_CLK>,
<&clock_camcc CAM_CC_IFE_0_CSID_CLK_SRC>,
<&clock_camcc CAM_CC_IFE_1_CSID_CLK>,
<&clock_camcc CAM_CC_IFE_1_CSID_CLK_SRC>,
<&clock_camcc CAM_CC_IFE_LITE_CSID_CLK>,
<&clock_camcc CAM_CC_IFE_LITE_CSID_CLK_SRC>,
<&clock_camcc CAM_CC_CSIPHY0_CLK>,
<&clock_camcc CAM_CC_CSI0PHYTIMER_CLK>,
<&clock_camcc CAM_CC_CSI0PHYTIMER_CLK_SRC>,
<&clock_camcc CAM_CC_CSIPHY1_CLK>,
<&clock_camcc CAM_CC_CSI1PHYTIMER_CLK>,
<&clock_camcc CAM_CC_CSI1PHYTIMER_CLK_SRC>,
<&clock_camcc CAM_CC_CSIPHY2_CLK>,
<&clock_camcc CAM_CC_CSI2PHYTIMER_CLK>,
<&clock_camcc CAM_CC_CSI2PHYTIMER_CLK_SRC>,
<&clock_camcc CAM_CC_CSIPHY3_CLK>,
<&clock_camcc CAM_CC_CSI3PHYTIMER_CLK>,
<&clock_camcc CAM_CC_CSI3PHYTIMER_CLK_SRC>,
<&gcc GCC_CAMERA_AHB_CLK>,
<&gcc GCC_CAMERA_AXI_CLK>,
<&clock_camcc CAM_CC_SLOW_AHB_CLK_SRC>,
<&clock_camcc CAM_CC_SOC_AHB_CLK>,
<&clock_camcc CAM_CC_IFE_0_AXI_CLK>,
<&clock_camcc CAM_CC_IFE_0_CLK>,
<&clock_camcc CAM_CC_IFE_0_CPHY_RX_CLK>,
<&clock_camcc CAM_CC_IFE_0_CLK_SRC>,
<&clock_camcc CAM_CC_IFE_1_AXI_CLK>,
<&clock_camcc CAM_CC_IFE_1_CLK>,
<&clock_camcc CAM_CC_IFE_1_CPHY_RX_CLK>,
<&clock_camcc CAM_CC_IFE_1_CLK_SRC>,
<&clock_camcc CAM_CC_IFE_LITE_CLK>,
<&clock_camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
<&clock_camcc CAM_CC_IFE_LITE_CLK_SRC>;
clock-names = "camnoc_axi",
"cpas_ahb",
"cphy_rx_src",
"csi0",
"csi0_src",
"csi1",
"csi1_src",
"csi2",
"csi2_src",
"csiphy0",
"csiphy0_timer",
"csiphy0_timer_src",
"csiphy1",
"csiphy1_timer",
"csiphy1_timer_src",
"csiphy2",
"csiphy2_timer",
"csiphy2_timer_src",
"csiphy3",
"csiphy3_timer",
"csiphy3_timer_src",
"gcc_camera_ahb",
"gcc_camera_axi",
"slow_ahb_src",
"soc_ahb",
"vfe0_axi",
"vfe0",
"vfe0_cphy_rx",
"vfe0_src",
"vfe1_axi",
"vfe1",
"vfe1_cphy_rx",
"vfe1_src",
"vfe_lite",
"vfe_lite_cphy_rx",
"vfe_lite_src";
interrupts = <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "csid0",
"csid1",
"csid2",
"csiphy0",
"csiphy1",
"csiphy2",
"csiphy3",
"vfe0",
"vfe1",
"vfe_lite";
iommus = <&apps_smmu 0x0808 0x0>,
<&apps_smmu 0x0810 0x8>,
<&apps_smmu 0x0c08 0x0>,
<&apps_smmu 0x0c10 0x8>;
power-domains = <&clock_camcc IFE_0_GDSC>,
<&clock_camcc IFE_1_GDSC>,
<&clock_camcc TITAN_TOP_GDSC>;
reg = <0 0xacb3000 0 0x1000>,
<0 0xacba000 0 0x1000>,
<0 0xacc8000 0 0x1000>,
<0 0xac65000 0 0x1000>,
<0 0xac66000 0 0x1000>,
<0 0xac67000 0 0x1000>,
<0 0xac68000 0 0x1000>,
<0 0xacaf000 0 0x4000>,
<0 0xacb6000 0 0x4000>,
<0 0xacc4000 0 0x4000>;
reg-names = "csid0",
"csid1",
"csid2",
"csiphy0",
"csiphy1",
"csiphy2",
"csiphy3",
"vfe0",
"vfe1",
"vfe_lite";
vdda-supply = <&reg_2v8>;
ports {
#address-cells = <1>;
#size-cells = <0>;
};
};
};

1
Documentation/devicetree/bindings/media/rc.yaml
View File

@@ -154,6 +154,7 @@ properties:
- rc-winfast
- rc-winfast-usbii-deluxe
- rc-x96max
- rc-xbox-360
- rc-xbox-dvd
- rc-zx-irdec

177
Documentation/devicetree/bindings/media/renesas,drif.txt
View File

@@ -1,177 +0,0 @@
Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
------------------------------------------------------------
R-Car Gen3 DRIF is a SPI like receive only slave device. A general
representation of DRIF interfacing with a master device is shown below.
+---------------------+ +---------------------+
| |-----SCK------->|CLK |
| Master |-----SS-------->|SYNC DRIFn (slave) |
| |-----SD0------->|D0 |
| |-----SD1------->|D1 |
+---------------------+ +---------------------+
As per datasheet, each DRIF channel (drifn) is made up of two internal
channels (drifn0 & drifn1). These two internal channels share the common
CLK & SYNC. Each internal channel has its own dedicated resources like
irq, dma channels, address space & clock. This internal split is not
visible to the external master device.
The device tree model represents each internal channel as a separate node.
The internal channels sharing the CLK & SYNC are tied together by their
phandles using a property called "renesas,bonding". For the rest of
the documentation, unless explicitly stated, the word channel implies an
internal channel.
When both internal channels are enabled they need to be managed together
as one (i.e.) they cannot operate alone as independent devices. Out of the
two, one of them needs to act as a primary device that accepts common
properties of both the internal channels. This channel is identified by a
property called "renesas,primary-bond".
To summarize,
- When both the internal channels that are bonded together are enabled,
the zeroth channel is selected as primary-bond. This channels accepts
properties common to all the members of the bond.
- When only one of the bonded channels need to be enabled, the property
"renesas,bonding" or "renesas,primary-bond" will have no effect. That
enabled channel can act alone as any other independent device.
Required properties of an internal channel:
-------------------------------------------
- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of R8A7795 SoC.
"renesas,r8a7796-drif" if DRIF controller is a part of R8A7796 SoC.
"renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible device.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first
followed by the generic version.
- reg: offset and length of that channel.
- interrupts: associated with that channel.
- clocks: phandle and clock specifier of that channel.
- clock-names: clock input name string: "fck".
- dmas: phandles to the DMA channels.
- dma-names: names of the DMA channel: "rx".
- renesas,bonding: phandle to the other channel.
Optional properties of an internal channel:
-------------------------------------------
- power-domains: phandle to the respective power domain.
Required properties of an internal channel when:
- It is the only enabled channel of the bond (or)
- If it acts as primary among enabled bonds
--------------------------------------------------------
- pinctrl-0: pin control group to be used for this channel.
- pinctrl-names: must be "default".
- renesas,primary-bond: empty property indicating the channel acts as primary
among the bonded channels.
- port: child port node corresponding to the data input, in accordance with
the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The port
node must contain at least one endpoint.
Optional endpoint property:
---------------------------
- sync-active: Indicates sync signal polarity, 0/1 for low/high respectively.
This property maps to SYNCAC bit in the hardware manual. The
default is 1 (active high).
Example:
--------
(1) Both internal channels enabled:
-----------------------------------
When interfacing with a third party tuner device with two data pins as shown
below.
+---------------------+ +---------------------+
| |-----SCK------->|CLK |
| Master |-----SS-------->|SYNC DRIFn (slave) |
| |-----SD0------->|D0 |
| |-----SD1------->|D1 |
+---------------------+ +---------------------+
drif00: rif@e6f40000 {
compatible = "renesas,r8a7795-drif",
"renesas,rcar-gen3-drif";
reg = <0 0xe6f40000 0 0x64>;
interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 515>;
clock-names = "fck";
dmas = <&dmac1 0x20>, <&dmac2 0x20>;
dma-names = "rx", "rx";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
renesas,bonding = <&drif01>;
renesas,primary-bond;
pinctrl-0 = <&drif0_pins>;
pinctrl-names = "default";
port {
drif0_ep: endpoint {
remote-endpoint = <&tuner_ep>;
};
};
};
drif01: rif@e6f50000 {
compatible = "renesas,r8a7795-drif",
"renesas,rcar-gen3-drif";
reg = <0 0xe6f50000 0 0x64>;
interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 514>;
clock-names = "fck";
dmas = <&dmac1 0x22>, <&dmac2 0x22>;
dma-names = "rx", "rx";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
renesas,bonding = <&drif00>;
};
(2) Internal channel 1 alone is enabled:
----------------------------------------
When interfacing with a third party tuner device with one data pin as shown
below.
+---------------------+ +---------------------+
| |-----SCK------->|CLK |
| Master |-----SS-------->|SYNC DRIFn (slave) |
| | |D0 (unused) |
| |-----SD-------->|D1 |
+---------------------+ +---------------------+
drif00: rif@e6f40000 {
compatible = "renesas,r8a7795-drif",
"renesas,rcar-gen3-drif";
reg = <0 0xe6f40000 0 0x64>;
interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 515>;
clock-names = "fck";
dmas = <&dmac1 0x20>, <&dmac2 0x20>;
dma-names = "rx", "rx";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
renesas,bonding = <&drif01>;
};
drif01: rif@e6f50000 {
compatible = "renesas,r8a7795-drif",
"renesas,rcar-gen3-drif";
reg = <0 0xe6f50000 0 0x64>;
interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 514>;
clock-names = "fck";
dmas = <&dmac1 0x22>, <&dmac2 0x22>;
dma-names = "rx", "rx";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
renesas,bonding = <&drif00>;
pinctrl-0 = <&drif0_pins>;
pinctrl-names = "default";
port {
drif0_ep: endpoint {
remote-endpoint = <&tuner_ep>;
sync-active = <0>;
};
};
};

279
Documentation/devicetree/bindings/media/renesas,drif.yaml Normal file
View File

@@ -0,0 +1,279 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/renesas,drif.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car Gen3 Digital Radio Interface Controller (DRIF)
maintainers:
- Ramesh Shanmugasundaram <rashanmu@gmail.com>
- Fabrizio Castro <fabrizio.castro.jz@renesas.com>
description: |
R-Car Gen3 DRIF is a SPI like receive only slave device. A general
representation of DRIF interfacing with a master device is shown below.
+---------------------+ +---------------------+
| |-----SCK------->|CLK |
| Master |-----SS-------->|SYNC DRIFn (slave) |
| |-----SD0------->|D0 |
| |-----SD1------->|D1 |
+---------------------+ +---------------------+
As per datasheet, each DRIF channel (drifn) is made up of two internal
channels (drifn0 & drifn1). These two internal channels share the common
CLK & SYNC. Each internal channel has its own dedicated resources like
irq, dma channels, address space & clock. This internal split is not
visible to the external master device.
The device tree model represents each internal channel as a separate node.
The internal channels sharing the CLK & SYNC are tied together by their
phandles using a property called "renesas,bonding". For the rest of
the documentation, unless explicitly stated, the word channel implies an
internal channel.
When both internal channels are enabled they need to be managed together
as one (i.e.) they cannot operate alone as independent devices. Out of the
two, one of them needs to act as a primary device that accepts common
properties of both the internal channels. This channel is identified by a
property called "renesas,primary-bond".
To summarize,
* When both the internal channels that are bonded together are enabled,
the zeroth channel is selected as primary-bond. This channels accepts
properties common to all the members of the bond.
* When only one of the bonded channels need to be enabled, the property
"renesas,bonding" or "renesas,primary-bond" will have no effect. That
enabled channel can act alone as any other independent device.
properties:
compatible:
items:
- enum:
- renesas,r8a7795-drif # R-Car H3
- renesas,r8a7796-drif # R-Car M3-W
- renesas,r8a77965-drif # R-Car M3-N
- renesas,r8a77990-drif # R-Car E3
- const: renesas,rcar-gen3-drif # Generic R-Car Gen3 compatible device
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
clock-names:
maxItems: 1
items:
- const: fck
resets:
maxItems: 1
dmas:
minItems: 1
maxItems: 2
dma-names:
minItems: 1
maxItems: 2
items:
- const: rx
- const: rx
renesas,bonding:
$ref: /schemas/types.yaml#/definitions/phandle
description:
The phandle to the other internal channel of DRIF
power-domains:
maxItems: 1
renesas,primary-bond:
type: boolean
description:
Indicates that the channel acts as primary among the bonded channels.
port:
type: object
description:
Child port node corresponding to the data input, in accordance with the
video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
The port node must contain at least one endpoint.
properties:
endpoint:
type: object
properties:
remote-endpoint:
description:
A phandle to the remote tuner endpoint subnode in remote node
port.
sync-active:
enum: [0, 1]
description:
Indicates sync signal polarity, 0/1 for low/high respectively.
This property maps to SYNCAC bit in the hardware manual. The
default is 1 (active high).
additionalProperties: false
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- resets
- dmas
- dma-names
- renesas,bonding
- power-domains
allOf:
- if:
required:
- renesas,primary-bond
then:
required:
- pinctrl-0
- pinctrl-names
- port
- if:
required:
- port
then:
required:
- pinctrl-0
- pinctrl-names
else:
properties:
pinctrl-0: false
pinctrl-names: false
additionalProperties: false
examples:
# Example with both internal channels enabled.
#
# When interfacing with a third party tuner device with two data pins as shown
# below.
#
# +---------------------+ +---------------------+
# | |-----SCK------->|CLK |
# | Master |-----SS-------->|SYNC DRIFn (slave) |
# | |-----SD0------->|D0 |
# | |-----SD1------->|D1 |
# +---------------------+ +---------------------+
- |
#include <dt-bindings/clock/r8a7795-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7795-sysc.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
drif00: rif@e6f40000 {
compatible = "renesas,r8a7795-drif",
"renesas,rcar-gen3-drif";
reg = <0 0xe6f40000 0 0x64>;
interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 515>;
clock-names = "fck";
dmas = <&dmac1 0x20>, <&dmac2 0x20>;
dma-names = "rx", "rx";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
renesas,bonding = <&drif01>;
resets = <&cpg 515>;
renesas,primary-bond;
pinctrl-0 = <&drif0_pins>;
pinctrl-names = "default";
port {
drif0_ep: endpoint {
remote-endpoint = <&tuner_ep>;
};
};
};
drif01: rif@e6f50000 {
compatible = "renesas,r8a7795-drif",
"renesas,rcar-gen3-drif";
reg = <0 0xe6f50000 0 0x64>;
interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 514>;
clock-names = "fck";
dmas = <&dmac1 0x22>, <&dmac2 0x22>;
dma-names = "rx", "rx";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
renesas,bonding = <&drif00>;
resets = <&cpg 514>;
};
};
# Example with internal channel 1 alone enabled.
#
# When interfacing with a third party tuner device with one data pin as shown
# below.
#
# +---------------------+ +---------------------+
# | |-----SCK------->|CLK |
# | Master |-----SS-------->|SYNC DRIFn (slave) |
# | | |D0 (unused) |
# | |-----SD-------->|D1 |
# +---------------------+ +---------------------+
- |
#include <dt-bindings/clock/r8a7795-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7795-sysc.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
drif10: rif@e6f60000 {
compatible = "renesas,r8a7795-drif",
"renesas,rcar-gen3-drif";
reg = <0 0xe6f60000 0 0x64>;
interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 513>;
clock-names = "fck";
dmas = <&dmac1 0x24>, <&dmac2 0x24>;
dma-names = "rx", "rx";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 513>;
renesas,bonding = <&drif11>;
status = "disabled";
};
drif11: rif@e6f70000 {
compatible = "renesas,r8a7795-drif",
"renesas,rcar-gen3-drif";
reg = <0 0xe6f70000 0 0x64>;
interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 512>;
clock-names = "fck";
dmas = <&dmac1 0x26>, <&dmac2 0x26>;
dma-names = "rx", "rx";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 512>;
renesas,bonding = <&drif10>;
pinctrl-0 = <&drif1_pins>;
pinctrl-names = "default";
port {
drif1_ep: endpoint {
remote-endpoint = <&tuner_ep1>;
sync-active = <0>;
};
};
};
};
...

14
Documentation/devicetree/bindings/media/zx-irdec.txt
View File

@@ -1,14 +0,0 @@
IR Decoder (IRDEC) on ZTE ZX family SoCs
Required properties:
- compatible: Should be "zte,zx296718-irdec".
- reg: Physical base address and length of IRDEC registers.
- interrupts: Interrupt number of IRDEC.
Exmaples:
irdec: ir-decoder@111000 {
compatible = "zte,zx296718-irdec";
reg = <0x111000 0x1000>;
interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
};

76
Documentation/driver-api/dma-buf.rst
View File

@@ -257,3 +257,79 @@ fences in the kernel. This means:
userspace is allowed to use userspace fencing or long running compute
workloads. This also means no implicit fencing for shared buffers in these
cases.
Recoverable Hardware Page Faults Implications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Modern hardware supports recoverable page faults, which has a lot of
implications for DMA fences.
First, a pending page fault obviously holds up the work that's running on the
accelerator and a memory allocation is usually required to resolve the fault.
But memory allocations are not allowed to gate completion of DMA fences, which
means any workload using recoverable page faults cannot use DMA fences for
synchronization. Synchronization fences controlled by userspace must be used
instead.
On GPUs this poses a problem, because current desktop compositor protocols on
Linux rely on DMA fences, which means without an entirely new userspace stack
built on top of userspace fences, they cannot benefit from recoverable page
faults. Specifically this means implicit synchronization will not be possible.
The exception is when page faults are only used as migration hints and never to
on-demand fill a memory request. For now this means recoverable page
faults on GPUs are limited to pure compute workloads.
Furthermore GPUs usually have shared resources between the 3D rendering and
compute side, like compute units or command submission engines. If both a 3D
job with a DMA fence and a compute workload using recoverable page faults are
pending they could deadlock:
- The 3D workload might need to wait for the compute job to finish and release
hardware resources first.
- The compute workload might be stuck in a page fault, because the memory
allocation is waiting for the DMA fence of the 3D workload to complete.
There are a few options to prevent this problem, one of which drivers need to
ensure:
- Compute workloads can always be preempted, even when a page fault is pending
and not yet repaired. Not all hardware supports this.
- DMA fence workloads and workloads which need page fault handling have
independent hardware resources to guarantee forward progress. This could be
achieved through e.g. through dedicated engines and minimal compute unit
reservations for DMA fence workloads.
- The reservation approach could be further refined by only reserving the
hardware resources for DMA fence workloads when they are in-flight. This must
cover the time from when the DMA fence is visible to other threads up to
moment when fence is completed through dma_fence_signal().
- As a last resort, if the hardware provides no useful reservation mechanics,
all workloads must be flushed from the GPU when switching between jobs
requiring DMA fences or jobs requiring page fault handling: This means all DMA
fences must complete before a compute job with page fault handling can be
inserted into the scheduler queue. And vice versa, before a DMA fence can be
made visible anywhere in the system, all compute workloads must be preempted
to guarantee all pending GPU page faults are flushed.
- Only a fairly theoretical option would be to untangle these dependencies when
allocating memory to repair hardware page faults, either through separate
memory blocks or runtime tracking of the full dependency graph of all DMA
fences. This results very wide impact on the kernel, since resolving the page
on the CPU side can itself involve a page fault. It is much more feasible and
robust to limit the impact of handling hardware page faults to the specific
driver.
Note that workloads that run on independent hardware like copy engines or other
GPUs do not have any impact. This allows us to keep using DMA fences internally
in the kernel even for resolving hardware page faults, e.g. by using copy
engines to clear or copy memory needed to resolve the page fault.
In some ways this page fault problem is a special case of the `Infinite DMA
Fences` discussions: Infinite fences from compute workloads are allowed to
depend on DMA fences, but not the other way around. And not even the page fault
problem is new, because some other CPU thread in userspace might
hit a page fault which holds up a userspace fence - supporting page faults on
GPUs doesn't anything fundamentally new.

3
Documentation/driver-api/media/camera-sensor.rst
View File

@@ -144,8 +144,7 @@ of the device. This is because the power state of the device is only changed
after the power state transition has taken place. The ``s_ctrl`` callback can be
used to obtain device's power state after the power state transition:
.. c:function::
int pm_runtime_get_if_in_use(struct device *dev);
.. c:function:: int pm_runtime_get_if_in_use(struct device *dev);
The function returns a non-zero value if it succeeded getting the power count or
runtime PM was disabled, in either of which cases the driver may proceed to

2
Documentation/driver-api/media/index.rst
View File

@@ -28,6 +28,8 @@ Please see:
:maxdepth: 5
:numbered:
maintainer-entry-profile
v4l2-core
dtv-core
rc-core

206
Documentation/driver-api/media/maintainer-entry-profile.rst Normal file
View File

@@ -0,0 +1,206 @@
Media Subsystem Profile
=======================
Overview
--------
The media subsystem covers support for a variety of devices: stream
capture, analog and digital TV streams, cameras, remote controllers, HDMI CEC
and media pipeline control.
It covers, mainly, the contents of those directories:
- drivers/media
- drivers/staging/media
- Documentation/admin-guide/media
- Documentation/driver-api/media
- Documentation/userspace-api/media
- Documentation/devicetree/bindings/media/\ [1]_
- include/media
.. [1] Device tree bindings are maintained by the
OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS maintainers
(see the MAINTAINERS file). So, changes there must be reviewed
by them before being merged via the media subsystem's development
tree.
Both media userspace and Kernel APIs are documented and the documentation
must be kept in sync with the API changes. It means that all patches that
add new features to the subsystem must also bring changes to the
corresponding API files.
Due to the size and wide scope of the media subsystem, media's
maintainership model is to have sub-maintainers that have a broad
knowledge of a specific aspect of the subsystem. It is the sub-maintainers'
task to review the patches, providing feedback to users if the patches are
following the subsystem rules and are properly using the media kernel and
userspace APIs.
Patches for the media subsystem must be sent to the media mailing list
at linux-media@vger.kernel.org as plain text only e-mail. Emails with
HTML will be automatically rejected by the mail server. It could be wise
to also copy the sub-maintainer(s).
Media's workflow is heavily based on Patchwork, meaning that, once a patch
is submitted, the e-mail will first be accepted by the mailing list
server, and, after a while, it should appear at:
- https://patchwork.linuxtv.org/project/linux-media/list/
If it doesn't automatically appear there after a few minutes, then
probably something went wrong on your submission. Please check if the
email is in plain text\ [2]_ only and if your emailer is not mangling
whitespaces before complaining or submitting them again.
You can check if the mailing list server accepted your patch, by looking at:
- https://lore.kernel.org/linux-media/
.. [2] If your email contains HTML, the mailing list server will simply
drop it, without any further notice.
Media maintainers
+++++++++++++++++
At the media subsystem, we have a group of senior developers that
are responsible for doing the code reviews at the drivers (also known as
sub-maintainers), and another senior developer responsible for the
subsystem as a whole. For core changes, whenever possible, multiple
media maintainers do the review.
The media maintainers that work on specific areas of the subsystem are:
- Digital TV and remote controllers:
Sean Young <sean@mess.org>
- HDMI CEC:
Hans Verkuil <hverkuil@xs4all.nl>
- Media controller drivers:
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
- ISP, v4l2-async, v4l2-fwnode, v4l2-flash-led-class and Sensor drivers:
Sakari Ailus <sakari.ailus@linux.intel.com>
- V4L2 drivers and core V4L2 frameworks:
Hans Verkuil <hverkuil@xs4all.nl>
The subsystem maintainer is:
Mauro Carvalho Chehab <mchehab@kernel.org>
Media maintainers may delegate a patch to other media maintainers as needed.
On such case, checkpatch's ``delegate`` field indicates who's currently
responsible for reviewing a patch.
Submit Checklist Addendum
-------------------------
Patches that change the Open Firmware/Device Tree bindings must be
reviewed by the Device Tree maintainers. So, DT maintainers should be
Cc:ed when those are submitted via devicetree@vger.kernel.org mailing
list.
There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
that should be used in order to check if the drivers are properly
implementing the media APIs:
==================== =======================================================
Type Tool
==================== =======================================================
V4L2 drivers\ [3]_ ``v4l2-compliance``
V4L2 virtual drivers ``contrib/test/test-media``
CEC drivers ``cec-compliance``
==================== =======================================================
.. [3] The ``v4l2-compliance`` also covers the media controller usage inside
V4L2 drivers.
Other compilance tools are under development to check other parts of the
subsystem.
Those tests need to pass before the patches go upstream.
Also, please notice that we build the Kernel with::
make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script
Where the check script is::
#!/bin/bash
/devel/smatch/smatch -p=kernel $@ >&2
/devel/sparse/sparse $@ >&2
Be sure to not introduce new warnings on your patches without a
very good reason.
Style Cleanup Patches
+++++++++++++++++++++
Style cleanups are welcome when they come together with other changes
at the files where the style changes will affect.
We may accept pure standalone style cleanups, but they should ideally
be one patch for the whole subsystem (if the cleanup is low volume),
or at least be grouped per directory. So, for example, if you're doing a
big cleanup change set at drivers under drivers/media, please send a single
patch for all drivers under drivers/media/pci, another one for
drivers/media/usb and so on.
Coding Style Addendum
+++++++++++++++++++++
Media development uses ``checkpatch.pl`` on strict mode to verify the code
style, e.g.::
$ ./scripts/checkpatch.pl --strict --max-line-length=80
In principle, patches should follow the coding style rules, but exceptions
are allowed if there are good reasons. On such case, maintainers and reviewers
may question about the rationale for not addressing the ``checkpatch.pl``.
Please notice that the goal here is to improve code readability. On
a few cases, ``checkpatch.pl`` may actually point to something that would
look worse. So, you should use good sense.
Note that addressing one ``checkpatch.pl`` issue (of any kind) alone may lead
to having longer lines than 80 characters per line. While this is not
strictly prohibited, efforts should be made towards staying within 80
characters per line. This could include using re-factoring code that leads
to less indentation, shorter variable or function names and last but not
least, simply wrapping the lines.
In particular, we accept lines with more than 80 columns:
- on strings, as they shouldn't be broken due to line length limits;
- when a function or variable name need to have a big identifier name,
which keeps hard to honor the 80 columns limit;
- on arithmetic expressions, when breaking lines makes them harder to
read;
- when they avoid a line to end with an open parenthesis or an open
bracket.
Key Cycle Dates
---------------
New submissions can be sent at any time, but if they intend to hit the
next merge window they should be sent before -rc5, and ideally stabilized
in the linux-media branch by -rc6.
Review Cadence
--------------
Provided that your patch is at https://patchwork.linuxtv.org, it should
be sooner or later handled, so you don't need to re-submit a patch.
Except for bug fixes, we don't usually add new patches to the development
tree between -rc6 and the next -rc1.
Please notice that the media subsystem is a high traffic one, so it
could take a while for us to be able to review your patches. Feel free
to ping if you don't get a feedback in a couple of weeks or to ask
other developers to publicly add Reviewed-by and, more importantly,
``Tested-by:`` tags.
Please note that we expect a detailed description for ``Tested-by:``,
identifying what boards were used at the test and what it was tested.

4
Documentation/driver-api/media/v4l2-subdev.rst
View File

@@ -208,7 +208,7 @@ the needs of the driver.
:c:func:`v4l2_async_notifier_add_i2c_subdev` are for bridge and ISP drivers for
registering their async sub-devices with the notifier.
:c:func:`v4l2_async_register_subdev_sensor_common` is a helper function for
:c:func:`v4l2_async_register_subdev_sensor` is a helper function for
sensor drivers registering their own async sub-device, but it also registers a
notifier and further registers async sub-devices for lens and flash devices
found in firmware. The notifier for the sub-device is unregistered with the
@@ -252,7 +252,7 @@ contain several subdevs that use an I2C bus, but also a subdev that is
controlled through GPIO pins. This distinction is only relevant when setting
up the device, but once the subdev is registered it is completely transparent.
Once te subdev has been registered you can call an ops function either
Once the subdev has been registered you can call an ops function either
directly:
.. code-block:: c

12
Documentation/gpu/drm-kms-helpers.rst
View File

@@ -80,6 +80,18 @@ Atomic State Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c
:export:
GEM Atomic Helper Reference
---------------------------
.. kernel-doc:: drivers/gpu/drm/drm_gem_atomic_helper.c
:doc: overview
.. kernel-doc:: include/drm/drm_gem_atomic_helper.h
:internal:
.. kernel-doc:: drivers/gpu/drm/drm_gem_atomic_helper.c
:export:
Simple KMS Helper Reference
===========================

1
Documentation/gpu/index.rst
View File

@@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
vga-switcheroo
vgaarbiter
todo
rfc/index
.. only:: subproject and html

17
Documentation/gpu/rfc/index.rst Normal file
View File

@@ -0,0 +1,17 @@
===============
GPU RFC Section
===============
For complex work, especially new uapi, it is often good to nail the high level
design issues before getting lost in the code details. This section is meant to
host such documentation:
* Each RFC should be a section in this file, explaining the goal and main design
considerations. Especially for uapi make sure you Cc: all relevant project
mailing lists and involved people outside of dri-devel.
* For uapi structures add a file to this directory with and then pull the
kerneldoc in like with real uapi headers.
* Once the code has landed move all the documentation to the right places in
the main core, helper or driver sections.

76
Documentation/gpu/todo.rst
View File

@@ -459,52 +459,6 @@ Contact: Emil Velikov, respective driver maintainers
Level: Intermediate
Plumb drm_atomic_state all over
-------------------------------
Currently various atomic functions take just a single or a handful of
object states (eg. plane state). While that single object state can
suffice for some simple cases, we often have to dig out additional
object states for dealing with various dependencies between the individual
objects or the hardware they represent. The process of digging out the
additional states is rather non-intuitive and error prone.
To fix that most functions should rather take the overall
drm_atomic_state as one of their parameters. The other parameters
would generally be the object(s) we mainly want to interact with.
For example, instead of
.. code-block:: c
int (*atomic_check)(struct drm_plane *plane, struct drm_plane_state *state);
we would have something like
.. code-block:: c
int (*atomic_check)(struct drm_plane *plane, struct drm_atomic_state *state);
The implementation can then trivially gain access to any required object
state(s) via drm_atomic_get_plane_state(), drm_atomic_get_new_plane_state(),
drm_atomic_get_old_plane_state(), and their equivalents for
other object types.
Additionally many drivers currently access the object->state pointer
directly in their commit functions. That is not going to work if we
eg. want to allow deeper commit pipelines as those pointers could
then point to the states corresponding to a future commit instead of
the current commit we're trying to process. Also non-blocking commits
execute locklessly so there are serious concerns with dereferencing
the object->state pointers without holding the locks that protect them.
Use of drm_atomic_get_new_plane_state(), drm_atomic_get_old_plane_state(),
etc. avoids these problems as well since they relate to a specific
commit via the passed in drm_atomic_state.
Contact: Ville Syrjälä, Daniel Vetter
Level: Intermediate
Use struct dma_buf_map throughout codebase
------------------------------------------
@@ -596,20 +550,24 @@ Contact: Daniel Vetter
Level: Intermediate
KMS cleanups
------------
Object lifetime fixes
---------------------
Some of these date from the very introduction of KMS in 2008 ...
There's two related issues here
- Make ->funcs and ->helper_private vtables optional. There's a bunch of empty
function tables in drivers, but before we can remove them we need to make sure
that all the users in helpers and drivers do correctly check for a NULL
vtable.
- Cleanup up the various ->destroy callbacks, which often are all the same
simple code.
- Cleanup up the various ->destroy callbacks. A lot of them just wrapt the
drm_*_cleanup implementations and can be removed. Some tack a kfree() at the
end, for which we could add drm_*_cleanup_kfree(). And then there's the (for
historical reasons) misnamed drm_primary_helper_destroy() function.
- Lots of drivers erroneously allocate DRM modeset objects using devm_kzalloc,
which results in use-after free issues on driver unload. This can be serious
trouble even for drivers for hardware integrated on the SoC due to
EPROBE_DEFERRED backoff.
Both these problems can be solved by switching over to drmm_kzalloc(), and the
various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(),
drmm_universal_plane_alloc(), ... and so on.
Contact: Daniel Vetter
Level: Intermediate
@@ -666,8 +624,6 @@ See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal
internship task, since it only requires a virtual machine and can be sized to
fit the available time.
Contact: Daniel Vetter
Level: See details
Backlight Refactoring
@@ -721,7 +677,7 @@ Outside DRM
Convert fbdev drivers to DRM
----------------------------
There are plenty of fbdev drivers for older hardware. Some hwardware has
There are plenty of fbdev drivers for older hardware. Some hardware has
become obsolete, but some still provides good(-enough) framebuffers. The
drivers that are still useful should be converted to DRM and afterwards
removed from fbdev.

1
Documentation/maintainer/maintainer-entry-profile.rst
View File

@@ -102,3 +102,4 @@ to do something different in the near future.
../doc-guide/maintainer-profile
../nvdimm/maintainer-entry-profile
../riscv/patch-acceptance
../driver-api/media/maintainer-entry-profile

14
Documentation/s390/pci.rst
View File

@@ -50,7 +50,8 @@ Entries specific to zPCI functions and entries that hold zPCI information.
* /sys/bus/pci/slots/XXXXXXXX
The slot entries are set up using the function identifier (FID) of the
PCI function.
PCI function. The format depicted as XXXXXXXX above is 8 hexadecimal digits
with 0 padding and lower case hexadecimal digitis.
- /sys/bus/pci/slots/XXXXXXXX/power
@@ -88,8 +89,15 @@ Entries specific to zPCI functions and entries that hold zPCI information.
is attached to.
- uid
The unique identifier (UID) is defined when configuring an LPAR and is
unique in the LPAR.
The user identifier (UID) may be defined as part of the machine
configuration or the z/VM or KVM guest configuration. If the accompanying
uid_is_unique attribute is 1 the platform guarantees that the UID is unique
within that instance and no devices with the same UID can be attached
during the lifetime of the system.
- uid_is_unique
Indicates whether the user identifier (UID) is guaranteed to be and remain
unique within this Linux instance.
- pfip/segmentX
The segments determine the isolation of a function.

10
Documentation/scheduler/sched-domains.rst
View File

@@ -74,8 +74,8 @@ for a given topology level by creating a sched_domain_topology_level array and
calling set_sched_topology() with this array as the parameter.
The sched-domains debugging infrastructure can be enabled by enabling
CONFIG_SCHED_DEBUG and adding 'sched_debug' to your cmdline. If you forgot to
tweak your cmdline, you can also flip the /sys/kernel/debug/sched_debug
knob. This enables an error checking parse of the sched domains which should
catch most possible errors (described above). It also prints out the domain
structure in a visual format.
CONFIG_SCHED_DEBUG and adding 'sched_debug_verbose' to your cmdline. If you
forgot to tweak your cmdline, you can also flip the
/sys/kernel/debug/sched/verbose knob. This enables an error checking parse of
the sched domains which should catch most possible errors (described above). It
also prints out the domain structure in a visual format.

4
Documentation/userspace-api/media/cec/cec-ioc-adap-g-caps.rst
View File

@@ -35,7 +35,7 @@ device information, applications call the ioctl with a pointer to a
struct :c:type:`cec_caps`. The driver fills the structure and
returns the information to the application. The ioctl never fails.
.. tabularcolumns:: |p{1.2cm}|p{2.5cm}|p{13.8cm}|
.. tabularcolumns:: |p{1.2cm}|p{2.5cm}|p{13.6cm}|
.. c:type:: cec_caps
@@ -63,7 +63,7 @@ returns the information to the application. The ioctl never fails.
- CEC Framework API version, formatted with the ``KERNEL_VERSION()``
macro.
.. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.6cm}|
.. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.4cm}|
.. _cec-capabilities:

6
Documentation/userspace-api/media/cec/cec-ioc-adap-g-conn-info.rst
View File

@@ -39,7 +39,7 @@ provide a pointer to a cec_connector_info struct which will be populated
by the kernel with the info provided by the adapter's driver. This ioctl
is only available if the ``CEC_CAP_CONNECTOR_INFO`` capability is set.
.. tabularcolumns:: |p{1.0cm}|p{4.4cm}|p{2.5cm}|p{9.6cm}|
.. tabularcolumns:: |p{1.0cm}|p{4.4cm}|p{2.5cm}|p{9.2cm}|
.. c:type:: cec_connector_info
@@ -59,7 +59,7 @@ is only available if the ``CEC_CAP_CONNECTOR_INFO`` capability is set.
* - }
-
.. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.6cm}|
.. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.4cm}|
.. _connector-type:
@@ -82,7 +82,7 @@ is only available if the ``CEC_CAP_CONNECTOR_INFO`` capability is set.
Information about the connector can be found in
:ref:`cec-drm-connector-info`.
.. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.6cm}|
.. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.4cm}|
.. c:type:: cec_drm_connector_info

12
Documentation/userspace-api/media/cec/cec-ioc-adap-g-log-addrs.rst
View File

@@ -67,7 +67,7 @@ logical address types are already defined will return with error ``EBUSY``.
.. c:type:: cec_log_addrs
.. tabularcolumns:: |p{1.0cm}|p{8.0cm}|p{7.5cm}|
.. tabularcolumns:: |p{1.0cm}|p{8.0cm}|p{8.0cm}|
.. cssclass:: longtable
@@ -150,7 +150,7 @@ logical address types are already defined will return with error ``EBUSY``.
give the CEC framework more information about the device type, even
though the framework won't use it directly in the CEC message.
.. tabularcolumns:: |p{7.8cm}|p{1.0cm}|p{8.7cm}|
.. tabularcolumns:: |p{7.8cm}|p{1.0cm}|p{8.5cm}|
.. _cec-log-addrs-flags:
@@ -186,7 +186,7 @@ logical address types are already defined will return with error ``EBUSY``.
All other messages are ignored.
.. tabularcolumns:: |p{7.8cm}|p{1.0cm}|p{8.7cm}|
.. tabularcolumns:: |p{7.8cm}|p{1.0cm}|p{8.5cm}|
.. _cec-versions:
@@ -211,7 +211,7 @@ logical address types are already defined will return with error ``EBUSY``.
- 6
- CEC version according to the HDMI 2.0 standard.
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.5cm}|
.. _cec-prim-dev-types:
@@ -256,7 +256,7 @@ logical address types are already defined will return with error ``EBUSY``.
- 7
- Use for a video processor device.
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.5cm}|
.. _cec-log-addr-types:
@@ -304,7 +304,7 @@ logical address types are already defined will return with error ``EBUSY``.
Control).
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.5cm}|
.. _cec-all-dev-types-flags:

10
Documentation/userspace-api/media/cec/cec-ioc-dqevent.rst
View File

@@ -44,7 +44,7 @@ two :ref:`CEC_EVENT_STATE_CHANGE <CEC-EVENT-STATE-CHANGE>` events with
the same state). In that case the intermediate state changes were lost but
it is guaranteed that the state did change in between the two events.
.. tabularcolumns:: |p{1.2cm}|p{2.9cm}|p{13.4cm}|
.. tabularcolumns:: |p{1.2cm}|p{2.9cm}|p{13.2cm}|
.. c:type:: cec_event_state_change
@@ -74,7 +74,7 @@ it is guaranteed that the state did change in between the two events.
.. c:type:: cec_event_lost_msgs
.. tabularcolumns:: |p{1.0cm}|p{2.0cm}|p{14.5cm}|
.. tabularcolumns:: |p{1.0cm}|p{2.0cm}|p{14.3cm}|
.. flat-table:: struct cec_event_lost_msgs
:header-rows: 0
@@ -93,7 +93,7 @@ it is guaranteed that the state did change in between the two events.
replied to within a second according to the CEC specification,
this is more than enough.
.. tabularcolumns:: |p{1.0cm}|p{4.4cm}|p{2.5cm}|p{9.6cm}|
.. tabularcolumns:: |p{1.0cm}|p{4.4cm}|p{2.5cm}|p{9.2cm}|
.. c:type:: cec_event
@@ -128,7 +128,7 @@ it is guaranteed that the state did change in between the two events.
* - }
-
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{10.8cm}|
.. _cec-events:
@@ -201,7 +201,7 @@ it is guaranteed that the state did change in between the two events.
if the 5V is high, then an initial event will be generated for that
filehandle.
.. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}|
.. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.7cm}|
.. _cec-event-flags:

4
Documentation/userspace-api/media/cec/cec-ioc-g-mode.rst
View File

@@ -72,7 +72,7 @@ always call :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>`.
Available initiator modes are:
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{10.8cm}|
.. _cec-mode-initiator_e:
@@ -106,7 +106,7 @@ Available initiator modes are:
Available follower modes are:
.. tabularcolumns:: |p{6.6cm}|p{0.9cm}|p{10.0cm}|
.. tabularcolumns:: |p{6.6cm}|p{0.9cm}|p{9.8cm}|
.. _cec-mode-follower_e:

8
Documentation/userspace-api/media/cec/cec-ioc-receive.rst
View File

@@ -84,7 +84,7 @@ physical address, but the cable is still connected and CEC still works.
In order to detect/wake up the device it is allowed to send poll and 'Image/Text
View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
.. tabularcolumns:: |p{1.0cm}|p{3.5cm}|p{13.0cm}|
.. tabularcolumns:: |p{1.0cm}|p{3.5cm}|p{12.8cm}|
.. c:type:: cec_msg
@@ -196,7 +196,7 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
supports this, otherwise it is always 0. This counter is only
valid if the :ref:`CEC_TX_STATUS_ERROR <CEC-TX-STATUS-ERROR>` status bit is set.
.. tabularcolumns:: |p{6.2cm}|p{1.0cm}|p{10.3cm}|
.. tabularcolumns:: |p{6.2cm}|p{1.0cm}|p{10.1cm}|
.. _cec-msg-flags:
@@ -229,7 +229,7 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
capability. If that is not set, then the ``EPERM`` error code is
returned.
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{10.8cm}|
.. _cec-tx-status:
@@ -298,7 +298,7 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
- The transmit timed out. This should not normally happen and this
indicates a driver problem.
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{10.8cm}|
.. _cec-rx-status:

2
Documentation/userspace-api/media/cec/cec-pin-error-inj.rst
View File

@@ -44,7 +44,7 @@ error injection status::
# <op>[,<mode>] rx-low-drive <bit> force a low-drive condition at this bit position
# <op>[,<mode>] rx-add-byte add a spurious byte to the received CEC message
# <op>[,<mode>] rx-remove-byte remove the last byte from the received CEC message
# <op>[,<mode>] rx-arb-lost <poll> generate a POLL message to trigger an arbitration lost
# any[,<mode>] rx-arb-lost [<poll>] generate a POLL message to trigger an arbitration lost
#
# TX error injection settings:
# tx-ignore-nack-until-eom ignore early NACKs until EOM

2
Documentation/userspace-api/media/dvb/fe-type-t.rst
View File

@@ -11,7 +11,7 @@ fe_type_t type, defined as:
.. c:type:: fe_type
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.5cm}|
.. flat-table:: Frontend types
:header-rows: 1

2
Documentation/userspace-api/media/mediactl/media-ioc-device-info.rst
View File

@@ -39,7 +39,7 @@ ioctl never fails.
.. c:type:: media_device_info
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.5cm}|
.. flat-table:: struct media_device_info
:header-rows: 0

2
Documentation/userspace-api/media/mediactl/media-ioc-enum-entities.rst
View File

@@ -50,7 +50,7 @@ id's until they get an error.
.. c:type:: media_entity_desc
.. tabularcolumns:: |p{1.5cm}|p{1.7cm}|p{1.6cm}|p{1.5cm}|p{11.2cm}|
.. tabularcolumns:: |p{1.5cm}|p{1.7cm}|p{1.6cm}|p{1.5cm}|p{10.6cm}|
.. flat-table:: struct media_entity_desc
:header-rows: 0

6
Documentation/userspace-api/media/mediactl/media-ioc-enum-links.rst
View File

@@ -54,7 +54,7 @@ returned during the enumeration process.
.. c:type:: media_links_enum
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.5cm}|
.. flat-table:: struct media_links_enum
:header-rows: 0
@@ -82,7 +82,7 @@ returned during the enumeration process.
.. c:type:: media_pad_desc
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.5cm}|
.. flat-table:: struct media_pad_desc
:header-rows: 0
@@ -109,7 +109,7 @@ returned during the enumeration process.
.. c:type:: media_link_desc
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.5cm}|
.. flat-table:: struct media_link_desc
:header-rows: 0

12
Documentation/userspace-api/media/mediactl/media-ioc-g-topology.rst
View File

@@ -46,7 +46,7 @@ other values untouched.
If the ``topology_version`` remains the same, the ioctl should fill the
desired arrays with the media graph elements.
.. tabularcolumns:: |p{1.6cm}|p{3.4cm}|p{12.5cm}|
.. tabularcolumns:: |p{1.6cm}|p{3.4cm}|p{12.3cm}|
.. c:type:: media_v2_topology
@@ -119,7 +119,7 @@ desired arrays with the media graph elements.
converted to a 64-bits integer. It can be zero. if zero, the ioctl
won't store the links. It will just update ``num_links``
.. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
.. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.5cm}|
.. c:type:: media_v2_entity
@@ -156,7 +156,7 @@ desired arrays with the media graph elements.
- Reserved for future extensions. Drivers and applications must set
this array to zero.
.. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
.. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.5cm}|
.. c:type:: media_v2_interface
@@ -189,7 +189,7 @@ desired arrays with the media graph elements.
- Used only for device node interfaces. See
:c:type:`media_v2_intf_devnode` for details.
.. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
.. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.5cm}|
.. c:type:: media_v2_intf_devnode
@@ -206,7 +206,7 @@ desired arrays with the media graph elements.
- ``minor``
- Device node minor number.
.. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
.. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.5cm}|
.. c:type:: media_v2_pad
@@ -241,7 +241,7 @@ desired arrays with the media graph elements.
- Reserved for future extensions. Drivers and applications must set
this array to zero.
.. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
.. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.5cm}|
.. c:type:: media_v2_link

4
Documentation/userspace-api/media/mediactl/media-types.rst
View File

@@ -5,7 +5,7 @@
Types and flags used to represent the media graph elements
==========================================================
.. tabularcolumns:: |p{8.2cm}|p{10.3cm}|
.. tabularcolumns:: |p{8.2cm}|p{9.3cm}|
.. _media-entity-functions:
.. _MEDIA-ENT-F-UNKNOWN:
@@ -251,7 +251,7 @@ Types and flags used to represent the media graph elements
- The entity represents a connector.
.. tabularcolumns:: |p{6.5cm}|p{6.0cm}|p{5.0cm}|
.. tabularcolumns:: |p{6.5cm}|p{6.0cm}|p{4.8cm}|
.. _media-intf-type:
.. _MEDIA-INTF-T-DVB-FE:

2
Documentation/userspace-api/media/rc/rc-tables.rst
View File

@@ -25,7 +25,7 @@ the remote via /dev/input/event devices.
.. _rc_standard_keymap:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.5cm}|
.. flat-table:: IR default keymapping
:header-rows: 0

22
Documentation/userspace-api/media/v4l/buffer.rst
View File

@@ -157,7 +157,7 @@ of appropriately sized buffers for each use case).
struct v4l2_buffer
==================
.. tabularcolumns:: |p{2.8cm}|p{2.5cm}|p{1.6cm}|p{10.2cm}|
.. tabularcolumns:: |p{2.9cm}|p{2.4cm}|p{12.0cm}|
.. cssclass:: longtable
@@ -314,7 +314,7 @@ struct v4l2_buffer
struct v4l2_plane
=================
.. tabularcolumns:: |p{3.5cm}|p{3.5cm}|p{3.5cm}|p{7.0cm}|
.. tabularcolumns:: |p{3.5cm}|p{3.5cm}|p{10.3cm}|
.. cssclass:: longtable
@@ -389,7 +389,7 @@ enum v4l2_buf_type
.. cssclass:: longtable
.. tabularcolumns:: |p{7.8cm}|p{0.6cm}|p{9.1cm}|
.. tabularcolumns:: |p{7.8cm}|p{0.6cm}|p{8.9cm}|
.. flat-table::
:header-rows: 0
@@ -452,16 +452,16 @@ Buffer Flags
.. raw:: latex
\small
\footnotesize
.. tabularcolumns:: |p{7.0cm}|p{2.1cm}|p{8.4cm}|
.. tabularcolumns:: |p{6.5cm}|p{1.8cm}|p{9.0cm}|
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 3 1 4
:widths: 65 18 70
* .. _`V4L2-BUF-FLAG-MAPPED`:
@@ -585,7 +585,7 @@ Buffer Flags
- ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF``
- 0x00000200
- Only valid if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` is
- Only valid if struct :c:type:`v4l2_requestbuffers` flag ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` is
set. It is typically used with stateless decoders where multiple
output buffers each decode to a slice of the decoded frame.
Applications can set this flag when queueing the output buffer
@@ -681,7 +681,7 @@ Buffer Flags
enum v4l2_memory
================
.. tabularcolumns:: |p{5.0cm}|p{0.8cm}|p{11.7cm}|
.. tabularcolumns:: |p{5.0cm}|p{0.8cm}|p{11.5cm}|
.. flat-table::
:header-rows: 0
@@ -715,7 +715,7 @@ The :c:type:`v4l2_buffer_timecode` structure is designed to hold a
struct v4l2_timecode
--------------------
.. tabularcolumns:: |p{1.4cm}|p{2.8cm}|p{12.3cm}|
.. tabularcolumns:: |p{1.4cm}|p{2.8cm}|p{13.1cm}|
.. flat-table::
:header-rows: 0
@@ -751,8 +751,6 @@ struct v4l2_timecode
Timecode Types
--------------
.. tabularcolumns:: |p{5.6cm}|p{0.8cm}|p{11.1cm}|
.. flat-table::
:header-rows: 0
:stub-columns: 0
@@ -780,7 +778,7 @@ Timecode Types
Timecode Flags
--------------
.. tabularcolumns:: |p{6.6cm}|p{1.4cm}|p{9.5cm}|
.. tabularcolumns:: |p{6.6cm}|p{1.4cm}|p{9.3cm}|
.. flat-table::
:header-rows: 0

31
Documentation/userspace-api/media/v4l/colorspaces-details.rst
View File

@@ -17,10 +17,6 @@ PAL and by SDTV in general. The default transfer function is
range. The chromaticities of the primary colors and the white reference
are:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. flat-table:: SMPTE 170M Chromaticities
:header-rows: 1
:stub-columns: 0
@@ -98,10 +94,6 @@ default Y'CbCr encoding is ``V4L2_YCBCR_ENC_709``. The default Y'CbCr
quantization is limited range. The chromaticities of the primary colors
and the white reference are:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. flat-table:: Rec. 709 Chromaticities
:header-rows: 1
:stub-columns: 0
@@ -225,10 +217,6 @@ would break how applications interpret the quantization range.
The chromaticities of the primary colors and the white reference are:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. flat-table:: sRGB Chromaticities
:header-rows: 1
:stub-columns: 0
@@ -308,9 +296,6 @@ would break how applications interpret the quantization range.
The chromaticities of the primary colors and the white reference are:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. flat-table:: opRGB Chromaticities
:header-rows: 1
:stub-columns: 0
@@ -373,10 +358,6 @@ definition television (UHDTV). The default transfer function is
``V4L2_YCBCR_ENC_BT2020``. The default Y'CbCr quantization is limited range.
The chromaticities of the primary colors and the white reference are:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. flat-table:: BT.2020 Chromaticities
:header-rows: 1
:stub-columns: 0
@@ -478,9 +459,6 @@ is ``V4L2_XFER_FUNC_DCI_P3``. The default Y'CbCr encoding is
The chromaticities of the primary colors and the white reference are:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. flat-table:: DCI-P3 Chromaticities
:header-rows: 1
:stub-columns: 0
@@ -532,9 +510,6 @@ quantization is limited range. The chromaticities of the primary colors
and the white reference are:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. flat-table:: SMPTE 240M Chromaticities
:header-rows: 1
:stub-columns: 0
@@ -603,9 +578,6 @@ limited range. The chromaticities of the primary colors and the white
reference are:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. flat-table:: NTSC 1953 Chromaticities
:header-rows: 1
:stub-columns: 0
@@ -683,9 +655,6 @@ range. The chromaticities of the primary colors and the white reference
are:
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. flat-table:: EBU Tech. 3213 Chromaticities
:header-rows: 1
:stub-columns: 0

1
Documentation/userspace-api/media/v4l/common.rst
View File

@@ -51,6 +51,7 @@ applicable to all devices.
ext-ctrls-fm-tx
ext-ctrls-fm-rx
ext-ctrls-detect
ext-ctrls-colorimetry
fourcc
format
planar-apis

13
Documentation/userspace-api/media/v4l/control.rst
View File

@@ -154,10 +154,13 @@ Control IDs
``V4L2_CID_POWER_LINE_FREQUENCY`` ``(enum)``
Enables a power line frequency filter to avoid flicker. Possible
values for ``enum v4l2_power_line_frequency`` are:
``V4L2_CID_POWER_LINE_FREQUENCY_DISABLED`` (0),
``V4L2_CID_POWER_LINE_FREQUENCY_50HZ`` (1),
``V4L2_CID_POWER_LINE_FREQUENCY_60HZ`` (2) and
``V4L2_CID_POWER_LINE_FREQUENCY_AUTO`` (3).
========================================== ==
``V4L2_CID_POWER_LINE_FREQUENCY_DISABLED`` 0
``V4L2_CID_POWER_LINE_FREQUENCY_50HZ`` 1
``V4L2_CID_POWER_LINE_FREQUENCY_60HZ`` 2
``V4L2_CID_POWER_LINE_FREQUENCY_AUTO`` 3
========================================== ==
``V4L2_CID_HUE_AUTO`` ``(boolean)``
Enables automatic hue control by the device. The effect of setting
@@ -197,7 +200,7 @@ Control IDs
.. tabularcolumns:: |p{5.5cm}|p{12cm}|
.. tabularcolumns:: |p{5.7cm}|p{11.8cm}|
.. flat-table::
:header-rows: 0

2
Documentation/userspace-api/media/v4l/dev-meta.rst
View File

@@ -49,7 +49,7 @@ to 0.
.. c:type:: v4l2_meta_format
.. tabularcolumns:: |p{1.4cm}|p{2.2cm}|p{13.9cm}|
.. tabularcolumns:: |p{1.4cm}|p{2.4cm}|p{13.5cm}|
.. flat-table:: struct v4l2_meta_format
:header-rows: 0

9
Documentation/userspace-api/media/v4l/dev-overlay.rst
View File

@@ -37,6 +37,10 @@ capturing and overlay. Optionally these drivers may also permit
capturing and overlay with a single file descriptor for compatibility
with V4L and earlier versions of V4L2. [#f1]_
A common application of two file descriptors is the X11
:ref:`Xv/V4L <xvideo>` interface driver and a V4L2 application.
While the X server controls video overlay, the application can take
advantage of memory mapping and DMA.
Querying Capabilities
=====================
@@ -289,11 +293,6 @@ To start or stop the frame buffer overlay applications call the
:ref:`VIDIOC_OVERLAY` ioctl.
.. [#f1]
A common application of two file descriptors is the XFree86
:ref:`Xv/V4L <xvideo>` interface driver and a V4L2 application.
While the X server controls video overlay, the application can take
advantage of memory mapping and DMA.
In the opinion of the designers of this API, no driver writer taking
the efforts to support simultaneous capturing and overlay will
restrict this ability by requiring a single file descriptor, as in

4
Documentation/userspace-api/media/v4l/dev-raw-vbi.rst
View File

@@ -97,7 +97,7 @@ VBI devices must implement both the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does.
:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is optional.
.. tabularcolumns:: |p{1.6cm}|p{4.2cm}|p{11.7cm}|
.. tabularcolumns:: |p{1.6cm}|p{4.2cm}|p{11.5cm}|
.. c:type:: v4l2_vbi_format
@@ -180,7 +180,7 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does
- This array is reserved for future extensions. Drivers and
applications must set it to zero.
.. tabularcolumns:: |p{4.4cm}|p{1.5cm}|p{11.6cm}|
.. tabularcolumns:: |p{4.4cm}|p{1.5cm}|p{11.4cm}|
.. _vbifmt-flags:

4
Documentation/userspace-api/media/v4l/dev-rds.rst
View File

@@ -91,8 +91,6 @@ RDS datastructures
.. c:type:: v4l2_rds_data
.. tabularcolumns:: |p{2.5cm}|p{2.5cm}|p{12.5cm}|
.. flat-table:: struct v4l2_rds_data
:header-rows: 0
:stub-columns: 0
@@ -133,7 +131,7 @@ RDS datastructures
.. _v4l2-rds-block-codes:
.. tabularcolumns:: |p{6.4cm}|p{2.0cm}|p{1.2cm}|p{7.9cm}|
.. tabularcolumns:: |p{6.4cm}|p{2.0cm}|p{1.2cm}|p{7.0cm}|
.. flat-table:: Block defines
:header-rows: 0

2
Documentation/userspace-api/media/v4l/dev-sdr.rst
View File

@@ -80,7 +80,7 @@ data transfer, set by the driver in order to inform application.
.. c:type:: v4l2_sdr_format
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.5cm}|
.. flat-table:: struct v4l2_sdr_format
:header-rows: 0

50
Documentation/userspace-api/media/v4l/dev-sliced-vbi.rst
View File

@@ -108,7 +108,7 @@ struct v4l2_sliced_vbi_format
\scriptsize
\setlength{\tabcolsep}{2pt}
.. tabularcolumns:: |p{.85cm}|p{3.3cm}|p{4.4cm}|p{4.4cm}|p{4.4cm}|
.. tabularcolumns:: |p{.85cm}|p{3.3cm}|p{4.45cm}|p{4.45cm}|p{4.45cm}|
.. cssclass:: longtable
@@ -213,9 +213,9 @@ Sliced VBI services
.. raw:: latex
\scriptsize
\footnotesize
.. tabularcolumns:: |p{4.1cm}|p{1.1cm}|p{2.4cm}|p{2.0cm}|p{7.3cm}|
.. tabularcolumns:: |p{4.2cm}|p{1.1cm}|p{2.1cm}|p{2.0cm}|p{6.5cm}|
.. flat-table::
:header-rows: 1
@@ -253,13 +253,7 @@ Sliced VBI services
:ref:`en300294`
- PAL/SECAM line 23
-
::
Byte 0 1
msb lsb msb lsb
Bit 7 6 5 4 3 2 1 0 x x 13 12 11 10 9
- See :ref:`v4l2-sliced-wss-625-payload` below.
* - ``V4L2_SLICED_VBI_525``
- 0x1000
- :cspan:`2` Set of services applicable to 525 line systems.
@@ -282,6 +276,21 @@ format while i/o is in progress (between a
:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` call, and after the first
:c:func:`read()` or :c:func:`write()` call).
.. _v4l2-sliced-wss-625-payload:
V4L2_SLICED_WSS_625 payload
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The payload for ``V4L2_SLICED_WSS_625`` is:
+-----+------------------+-----------------------+
|Byte | 0 | 1 |
+-----+--------+---------+-----------+-----------+
| | msb | lsb | msb | lsb |
| +-+-+-+--+--+-+-+--+--+-+--+---+---+--+-+--+
| Bit |7|6|5|4 | 3|2|1|0 | x|x|13|12 | 11|10|9|8 |
+-----+-+-+-+--+--+-+-+--+--+-+--+---+---+--+-+--+
Reading and writing sliced VBI data
===================================
@@ -298,7 +307,7 @@ struct :c:type:`v4l2_sliced_vbi_data` elements must be zero.
struct v4l2_sliced_vbi_data
---------------------------
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. tabularcolumns:: |p{1.2cm}|p{2.2cm}|p{13.9cm}|
.. flat-table::
:header-rows: 0
@@ -455,7 +464,7 @@ number).
struct v4l2_mpeg_vbi_fmt_ivtv
-----------------------------
.. tabularcolumns:: |p{1.0cm}|p{3.8cm}|p{1.0cm}|p{11.2cm}|
.. tabularcolumns:: |p{4.2cm}|p{2.0cm}|p{11.1cm}|
.. flat-table::
:header-rows: 0
@@ -490,7 +499,7 @@ struct v4l2_mpeg_vbi_fmt_ivtv
Magic Constants for struct v4l2_mpeg_vbi_fmt_ivtv magic field
-------------------------------------------------------------
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.5cm}|
.. flat-table::
:header-rows: 1
@@ -519,7 +528,11 @@ Magic Constants for struct v4l2_mpeg_vbi_fmt_ivtv magic field
structs v4l2_mpeg_vbi_itv0 and v4l2_mpeg_vbi_ITV0
-------------------------------------------------
.. tabularcolumns:: |p{5.2cm}|p{2.4cm}|p{9.9cm}|
.. raw:: latex
\footnotesize
.. tabularcolumns:: |p{4.6cm}|p{2.0cm}|p{10.7cm}|
.. flat-table::
:header-rows: 0
@@ -560,13 +573,16 @@ structs v4l2_mpeg_vbi_itv0 and v4l2_mpeg_vbi_ITV0
one line of unspecified data that should be ignored by
applications.
.. raw:: latex
\normalsize
.. _v4l2-mpeg-vbi-itv0-1:
struct v4l2_mpeg_vbi_ITV0
-------------------------
.. tabularcolumns:: |p{5.2cm}|p{2.4cm}|p{9.9cm}|
.. tabularcolumns:: |p{5.2cm}|p{2.4cm}|p{9.7cm}|
.. flat-table::
:header-rows: 0
@@ -587,7 +603,7 @@ struct v4l2_mpeg_vbi_ITV0
struct v4l2_mpeg_vbi_itv0_line
------------------------------
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.5cm}|
.. flat-table::
:header-rows: 0
@@ -609,7 +625,7 @@ struct v4l2_mpeg_vbi_itv0_line
Line Identifiers for struct v4l2_mpeg_vbi_itv0_line id field
------------------------------------------------------------
.. tabularcolumns:: |p{7.0cm}|p{1.8cm}|p{8.7cm}|
.. tabularcolumns:: |p{7.0cm}|p{1.8cm}|p{8.5cm}|
.. flat-table::
:header-rows: 1

6
Documentation/userspace-api/media/v4l/dev-subdev.rst
View File

@@ -209,9 +209,11 @@ list entity names and pad numbers).
.. raw:: latex
\begingroup
\scriptsize
\setlength{\tabcolsep}{2pt}
.. tabularcolumns:: |p{2.0cm}|p{2.3cm}|p{2.3cm}|p{2.3cm}|p{2.3cm}|p{2.3cm}|p{2.3cm}|
.. tabularcolumns:: |p{2.0cm}|p{2.1cm}|p{2.1cm}|p{2.1cm}|p{2.1cm}|p{2.1cm}|p{2.1cm}|
.. _sample-pipeline-config:
@@ -298,7 +300,7 @@ list entity names and pad numbers).
.. raw:: latex
\normalsize
\endgroup
1. Initial state. The sensor source pad format is set to its native 3MP
size and V4L2_MBUS_FMT_SGRBG8_1X8 media bus code. Formats on the

10
Documentation/userspace-api/media/v4l/diff-v4l.rst
View File

@@ -72,7 +72,11 @@ and radio devices supporting a set of related functions like video
capturing, video overlay and VBI capturing. See :ref:`open` for an
introduction.
.. tabularcolumns:: |p{5.5cm}|p{6.5cm}|p{5.5cm}
.. raw:: latex
\small
.. tabularcolumns:: |p{5.3cm}|p{6.7cm}|p{5.3cm}|
.. cssclass:: longtable
@@ -148,6 +152,10 @@ introduction.
- ``-``
- See above.
.. raw:: latex
\normalsize
The ``audios`` field was replaced by ``capabilities`` flag
``V4L2_CAP_AUDIO``, indicating *if* the device has any audio inputs or
outputs. To determine their number applications can enumerate audio

14
Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst
View File

@@ -32,6 +32,7 @@ enum v4l2_exposure_auto_type -
should ignore such requests. Possible values are:
.. tabularcolumns:: |p{7.1cm}|p{10.4cm}|
.. flat-table::
:header-rows: 0
@@ -81,7 +82,7 @@ enum v4l2_exposure_metering -
Determines how the camera measures the amount of light available for
the frame exposure. Possible values are:
.. tabularcolumns:: |p{8.7cm}|p{8.8cm}|
.. tabularcolumns:: |p{8.7cm}|p{8.7cm}|
.. flat-table::
:header-rows: 0
@@ -173,7 +174,7 @@ enum v4l2_exposure_metering -
control may stop updates of the ``V4L2_CID_AUTO_FOCUS_STATUS``
control value.
.. tabularcolumns:: |p{6.7cm}|p{10.8cm}|
.. tabularcolumns:: |p{6.8cm}|p{10.7cm}|
.. flat-table::
:header-rows: 0
@@ -199,7 +200,7 @@ enum v4l2_exposure_metering -
enum v4l2_auto_focus_range -
Determines auto focus distance range for which lens may be adjusted.
.. tabularcolumns:: |p{6.8cm}|p{10.7cm}|
.. tabularcolumns:: |p{6.9cm}|p{10.6cm}|
.. flat-table::
:header-rows: 0
@@ -274,7 +275,7 @@ enum v4l2_auto_n_preset_white_balance -
representation. The following white balance presets are listed in
order of increasing color temperature.
.. tabularcolumns:: |p{7.2 cm}|p{10.3cm}|
.. tabularcolumns:: |p{7.4cm}|p{10.1cm}|
.. flat-table::
:header-rows: 0
@@ -384,7 +385,9 @@ enum v4l2_scene_mode -
\small
.. tabularcolumns:: |p{5.9cm}|p{11.5cm}|
.. tabularcolumns:: |p{5.9cm}|p{11.6cm}|
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
@@ -519,6 +522,7 @@ enum v4l2_scene_mode -
have the ``V4L2_CAMERA_ORIENTATION_EXTERNAL`` orientation.
.. tabularcolumns:: |p{7.7cm}|p{9.8cm}|
.. flat-table::
:header-rows: 0

519
Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
View File

@@ -34,7 +34,11 @@ Stateless Codec Control ID
.. c:type:: v4l2_ctrl_h264_sps
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{1.2cm}|p{8.6cm}|p{7.5cm}|
.. flat-table:: struct v4l2_ctrl_h264_sps
:header-rows: 0
@@ -96,6 +100,10 @@ Stateless Codec Control ID
- ``flags``
- See :ref:`Sequence Parameter Set Flags <h264_sps_flags>`
.. raw:: latex
\normalsize
.. _h264_sps_constraints_set_flags:
``Sequence Parameter Set Constraints Set Flags``
@@ -171,7 +179,9 @@ Stateless Codec Control ID
.. c:type:: v4l2_ctrl_h264_pps
.. cssclass:: longtable
.. raw:: latex
\small
.. flat-table:: struct v4l2_ctrl_h264_pps
:header-rows: 0
@@ -212,43 +222,57 @@ Stateless Codec Control ID
- ``flags``
- See :ref:`Picture Parameter Set Flags <h264_pps_flags>`
.. raw:: latex
\normalsize
.. _h264_pps_flags:
``Picture Parameter Set Flags``
.. cssclass:: longtable
.. raw:: latex
\begingroup
\scriptsize
\setlength{\tabcolsep}{2pt}
.. tabularcolumns:: |p{9.8cm}|p{1.0cm}|p{6.5cm}|
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
:widths: 10 1 4
* - ``V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE``
- 0x00000001
- 0x0001
-
* - ``V4L2_H264_PPS_FLAG_BOTTOM_FIELD_PIC_ORDER_IN_FRAME_PRESENT``
- 0x00000002
- 0x0002
-
* - ``V4L2_H264_PPS_FLAG_WEIGHTED_PRED``
- 0x00000004
- 0x0004
-
* - ``V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT``
- 0x00000008
- 0x0008
-
* - ``V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED``
- 0x00000010
- 0x0010
-
* - ``V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT``
- 0x00000020
- 0x0020
-
* - ``V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE``
- 0x00000040
- 0x0040
-
* - ``V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT``
- 0x00000080
- Indicates that ``V4L2_CID_STATELESS_H264_SCALING_MATRIX``
- 0x0080
- ``V4L2_CID_STATELESS_H264_SCALING_MATRIX``
must be used for this picture.
.. raw:: latex
\endgroup
``V4L2_CID_STATELESS_H264_SCALING_MATRIX (struct)``
Specifies the scaling matrix (as extracted from the bitstream) for
the associated H264 slice data. The bitstream parameters are
@@ -259,7 +283,11 @@ Stateless Codec Control ID
.. c:type:: v4l2_ctrl_h264_scaling_matrix
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{0.6cm}|p{4.8cm}|p{11.9cm}|
.. flat-table:: struct v4l2_ctrl_h264_scaling_matrix
:header-rows: 0
@@ -290,7 +318,11 @@ Stateless Codec Control ID
.. c:type:: v4l2_ctrl_h264_slice_params
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{4.0cm}|p{5.9cm}|p{7.4cm}|
.. flat-table:: struct v4l2_ctrl_h264_slice_params
:header-rows: 0
@@ -333,11 +365,11 @@ Stateless Codec Control ID
* - __u8
- ``num_ref_idx_l0_active_minus1``
- If num_ref_idx_active_override_flag is not set, this field must be
set to the value of num_ref_idx_l0_default_active_minus1.
set to the value of num_ref_idx_l0_default_active_minus1
* - __u8
- ``num_ref_idx_l1_active_minus1``
- If num_ref_idx_active_override_flag is not set, this field must be
set to the value of num_ref_idx_l1_default_active_minus1.
set to the value of num_ref_idx_l1_default_active_minus1
* - __u8
- ``reserved``
- Applications and drivers must set this to zero.
@@ -351,6 +383,10 @@ Stateless Codec Control ID
- ``flags``
- See :ref:`Slice Parameter Flags <h264_slice_flags>`
.. raw:: latex
\normalsize
.. _h264_slice_flags:
``Slice Parameter Set Flags``
@@ -378,7 +414,11 @@ Stateless Codec Control ID
.. c:type:: v4l2_ctrl_h264_pred_weights
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{4.9cm}|p{4.9cm}|p{7.5cm}|
.. flat-table:: struct v4l2_ctrl_h264_pred_weights
:header-rows: 0
@@ -396,9 +436,17 @@ Stateless Codec Control ID
- The weight factors at index 0 are the weight factors for the reference
list 0, the one at index 1 for the reference list 1.
.. raw:: latex
\normalsize
.. c:type:: v4l2_h264_weight_factors
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{1.0cm}|p{4.5cm}|p{11.8cm}|
.. flat-table:: struct v4l2_h264_weight_factors
:header-rows: 0
@@ -418,6 +466,10 @@ Stateless Codec Control ID
- ``chroma_offset[32][2]``
-
.. raw:: latex
\normalsize
``Picture Reference``
.. c:type:: v4l2_h264_reference
@@ -440,7 +492,11 @@ Stateless Codec Control ID
``Reference Fields``
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{5.4cm}|p{0.8cm}|p{11.1cm}|
.. flat-table::
:header-rows: 0
@@ -458,6 +514,10 @@ Stateless Codec Control ID
- The frame (or the top/bottom fields, if it's a field pair)
is used for short-term reference.
.. raw:: latex
\normalsize
``V4L2_CID_STATELESS_H264_DECODE_PARAMS (struct)``
Specifies the decode parameters (as extracted from the bitstream)
for the associated H264 slice data. This includes the necessary
@@ -469,7 +529,11 @@ Stateless Codec Control ID
.. c:type:: v4l2_ctrl_h264_decode_params
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{4.0cm}|p{5.9cm}|p{7.4cm}|
.. flat-table:: struct v4l2_ctrl_h264_decode_params
:header-rows: 0
@@ -524,11 +588,19 @@ Stateless Codec Control ID
- ``flags``
- See :ref:`Decode Parameters Flags <h264_decode_params_flags>`
.. raw:: latex
\normalsize
.. _h264_decode_params_flags:
``Decode Parameters Flags``
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{8.3cm}|p{2.1cm}|p{6.9cm}|
.. flat-table::
:header-rows: 0
@@ -545,9 +617,17 @@ Stateless Codec Control ID
- 0x00000004
-
.. raw:: latex
\normalsize
.. c:type:: v4l2_h264_dpb_entry
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{1.0cm}|p{4.9cm}|p{11.4cm}|
.. flat-table:: struct v4l2_h264_dpb_entry
:header-rows: 0
@@ -583,11 +663,19 @@ Stateless Codec Control ID
- ``flags``
- See :ref:`DPB Entry Flags <h264_dpb_flags>`
.. raw:: latex
\normalsize
.. _h264_dpb_flags:
``DPB Entries Flags``
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{7.7cm}|p{2.1cm}|p{7.5cm}|
.. flat-table::
:header-rows: 0
@@ -607,6 +695,10 @@ Stateless Codec Control ID
- 0x00000008
- The DPB entry is a single field or a complementary field pair.
.. raw:: latex
\normalsize
``V4L2_CID_STATELESS_H264_DECODE_MODE (enum)``
Specifies the decoding mode to use. Currently exposes slice-based and
frame-based decoding but new modes might be added later on.
@@ -619,7 +711,11 @@ Stateless Codec Control ID
.. c:type:: v4l2_stateless_h264_decode_mode
.. cssclass:: longtable
.. raw:: latex
\scriptsize
.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}|
.. flat-table::
:header-rows: 0
@@ -644,6 +740,10 @@ Stateless Codec Control ID
selected, the ``V4L2_CID_STATELESS_H264_SLICE_PARAMS``
control shall not be set.
.. raw:: latex
\normalsize
``V4L2_CID_STATELESS_H264_START_CODE (enum)``
Specifies the H264 slice start code expected for each slice.
This control is used as a modifier for V4L2_PIX_FMT_H264_SLICE
@@ -655,23 +755,32 @@ Stateless Codec Control ID
.. c:type:: v4l2_stateless_h264_start_code
.. cssclass:: longtable
.. raw:: latex
\small
.. tabularcolumns:: |p{7.9cm}|p{0.4cm}|p{9.0cm}|
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
:widths: 4 1 4
* - ``V4L2_STATELESS_H264_START_CODE_NONE``
- 0
- Selecting this value specifies that H264 slices are passed
to the driver without any start code.
to the driver without any start code. The bitstream data should be
according to :ref:`h264` 7.3.1 NAL unit syntax, hence contains
emulation prevention bytes when required.
* - ``V4L2_STATELESS_H264_START_CODE_ANNEX_B``
- 1
- Selecting this value specifies that H264 slices are expected
to be prefixed by Annex B start codes. According to :ref:`h264`
valid start codes can be 3-bytes 0x000001 or 4-bytes 0x00000001.
.. raw:: latex
\normalsize
.. _codec-stateless-fwht:
@@ -683,9 +792,11 @@ Stateless Codec Control ID
.. c:type:: v4l2_ctrl_fwht_params
.. cssclass:: longtable
.. raw:: latex
.. tabularcolumns:: |p{1.4cm}|p{4.3cm}|p{11.8cm}|
\small
.. tabularcolumns:: |p{1.4cm}|p{3.9cm}|p{12.0cm}|
.. flat-table:: struct v4l2_ctrl_fwht_params
:header-rows: 0
@@ -724,16 +835,20 @@ Stateless Codec Control ID
- ``quantization``
- The quantization range, from enum :c:type:`v4l2_quantization`.
.. raw:: latex
\normalsize
.. _fwht-flags:
FWHT Flags
==========
.. cssclass:: longtable
.. raw:: latex
.. tabularcolumns:: |p{6.8cm}|p{2.4cm}|p{8.3cm}|
\small
.. tabularcolumns:: |p{7.0cm}|p{2.3cm}|p{8.0cm}|
.. flat-table::
:header-rows: 0
@@ -778,7 +893,7 @@ FWHT Flags
- Set if this is an I-frame.
* - ``V4L2_FWHT_FL_COMPONENTS_NUM_MSK``
- 0x00070000
- The number of color components - 1.
- The number of color components minus one.
* - ``V4L2_FWHT_FL_PIXENC_MSK``
- 0x00180000
- The mask for the pixel encoding.
@@ -791,3 +906,341 @@ FWHT Flags
* - ``V4L2_FWHT_FL_PIXENC_HSV``
- 0x00180000
- Set if the pixel encoding is HSV.
.. raw:: latex
\normalsize
.. _v4l2-codec-stateless-vp8:
``V4L2_CID_STATELESS_VP8_FRAME (struct)``
Specifies the frame parameters for the associated VP8 parsed frame data.
This includes the necessary parameters for
configuring a stateless hardware decoding pipeline for VP8.
The bitstream parameters are defined according to :ref:`vp8`.
.. c:type:: v4l2_ctrl_vp8_frame
.. raw:: latex
\small
.. tabularcolumns:: |p{7.0cm}|p{4.6cm}|p{5.7cm}|
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_vp8_frame
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - struct :c:type:`v4l2_vp8_segment`
- ``segment``
- Structure with segment-based adjustments metadata.
* - struct :c:type:`v4l2_vp8_loop_filter`
- ``lf``
- Structure with loop filter level adjustments metadata.
* - struct :c:type:`v4l2_vp8_quantization`
- ``quant``
- Structure with VP8 dequantization indices metadata.
* - struct :c:type:`v4l2_vp8_entropy`
- ``entropy``
- Structure with VP8 entropy coder probabilities metadata.
* - struct :c:type:`v4l2_vp8_entropy_coder_state`
- ``coder_state``
- Structure with VP8 entropy coder state.
* - __u16
- ``width``
- The width of the frame. Must be set for all frames.
* - __u16
- ``height``
- The height of the frame. Must be set for all frames.
* - __u8
- ``horizontal_scale``
- Horizontal scaling factor.
* - __u8
- ``vertical_scaling factor``
- Vertical scale.
* - __u8
- ``version``
- Bitstream version.
* - __u8
- ``prob_skip_false``
- Indicates the probability that the macroblock is not skipped.
* - __u8
- ``prob_intra``
- Indicates the probability that a macroblock is intra-predicted.
* - __u8
- ``prob_last``
- Indicates the probability that the last reference frame is used
for inter-prediction
* - __u8
- ``prob_gf``
- Indicates the probability that the golden reference frame is used
for inter-prediction
* - __u8
- ``num_dct_parts``
- Number of DCT coefficients partitions. Must be one of: 1, 2, 4, or 8.
* - __u32
- ``first_part_size``
- Size of the first partition, i.e. the control partition.
* - __u32
- ``first_part_header_bits``
- Size in bits of the first partition header portion.
* - __u32
- ``dct_part_sizes[8]``
- DCT coefficients sizes.
* - __u64
- ``last_frame_ts``
- Timestamp for the V4L2 capture buffer to use as last reference frame, used
with inter-coded frames. The timestamp refers to the ``timestamp`` field in
struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()`
function to convert the struct :c:type:`timeval` in struct
:c:type:`v4l2_buffer` to a __u64.
* - __u64
- ``golden_frame_ts``
- Timestamp for the V4L2 capture buffer to use as last reference frame, used
with inter-coded frames. The timestamp refers to the ``timestamp`` field in
struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()`
function to convert the struct :c:type:`timeval` in struct
:c:type:`v4l2_buffer` to a __u64.
* - __u64
- ``alt_frame_ts``
- Timestamp for the V4L2 capture buffer to use as alternate reference frame, used
with inter-coded frames. The timestamp refers to the ``timestamp`` field in
struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()`
function to convert the struct :c:type:`timeval` in struct
:c:type:`v4l2_buffer` to a __u64.
* - __u64
- ``flags``
- See :ref:`Frame Flags <vp8_frame_flags>`
.. raw:: latex
\normalsize
.. _vp8_frame_flags:
``Frame Flags``
.. tabularcolumns:: |p{9.8cm}|p{0.8cm}|p{6.7cm}|
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_VP8_FRAME_FLAG_KEY_FRAME``
- 0x01
- Indicates if the frame is a key frame.
* - ``V4L2_VP8_FRAME_FLAG_EXPERIMENTAL``
- 0x02
- Experimental bitstream.
* - ``V4L2_VP8_FRAME_FLAG_SHOW_FRAME``
- 0x04
- Show frame flag, indicates if the frame is for display.
* - ``V4L2_VP8_FRAME_FLAG_MB_NO_SKIP_COEFF``
- 0x08
- Enable/disable skipping of macroblocks with no non-zero coefficients.
* - ``V4L2_VP8_FRAME_FLAG_SIGN_BIAS_GOLDEN``
- 0x10
- Sign of motion vectors when the golden frame is referenced.
* - ``V4L2_VP8_FRAME_FLAG_SIGN_BIAS_ALT``
- 0x20
- Sign of motion vectors when the alt frame is referenced.
.. c:type:: v4l2_vp8_entropy_coder_state
.. cssclass:: longtable
.. tabularcolumns:: |p{1.0cm}|p{2.0cm}|p{14.3cm}|
.. flat-table:: struct v4l2_vp8_entropy_coder_state
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``range``
- coder state value for "Range"
* - __u8
- ``value``
- coder state value for "Value"-
* - __u8
- ``bit_count``
- number of bits left.
* - __u8
- ``padding``
- Applications and drivers must set this to zero.
.. c:type:: v4l2_vp8_segment
.. cssclass:: longtable
.. tabularcolumns:: |p{1.2cm}|p{4.0cm}|p{12.1cm}|
.. flat-table:: struct v4l2_vp8_segment
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __s8
- ``quant_update[4]``
- Signed quantizer value update.
* - __s8
- ``lf_update[4]``
- Signed loop filter level value update.
* - __u8
- ``segment_probs[3]``
- Segment probabilities.
* - __u8
- ``padding``
- Applications and drivers must set this to zero.
* - __u32
- ``flags``
- See :ref:`Segment Flags <vp8_segment_flags>`
.. _vp8_segment_flags:
``Segment Flags``
.. raw:: latex
\small
.. tabularcolumns:: |p{10cm}|p{1.0cm}|p{6.3cm}|
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_VP8_SEGMENT_FLAG_ENABLED``
- 0x01
- Enable/disable segment-based adjustments.
* - ``V4L2_VP8_SEGMENT_FLAG_UPDATE_MAP``
- 0x02
- Indicates if the macroblock segmentation map is updated in this frame.
* - ``V4L2_VP8_SEGMENT_FLAG_UPDATE_FEATURE_DATA``
- 0x04
- Indicates if the segment feature data is updated in this frame.
* - ``V4L2_VP8_SEGMENT_FLAG_DELTA_VALUE_MODE``
- 0x08
- If is set, the segment feature data mode is delta-value.
If cleared, it's absolute-value.
.. raw:: latex
\normalsize
.. c:type:: v4l2_vp8_loop_filter
.. cssclass:: longtable
.. tabularcolumns:: |p{1.5cm}|p{3.9cm}|p{11.9cm}|
.. flat-table:: struct v4l2_vp8_loop_filter
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __s8
- ``ref_frm_delta[4]``
- Reference adjustment (signed) delta value.
* - __s8
- ``mb_mode_delta[4]``
- Macroblock prediction mode adjustment (signed) delta value.
* - __u8
- ``sharpness_level``
- Sharpness level
* - __u8
- ``level``
- Filter level
* - __u16
- ``padding``
- Applications and drivers must set this to zero.
* - __u32
- ``flags``
- See :ref:`Loop Filter Flags <vp8_loop_filter_flags>`
.. _vp8_loop_filter_flags:
``Loop Filter Flags``
.. tabularcolumns:: |p{7.0cm}|p{1.2cm}|p{9.1cm}|
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_VP8_LF_ADJ_ENABLE``
- 0x01
- Enable/disable macroblock-level loop filter adjustment.
* - ``V4L2_VP8_LF_DELTA_UPDATE``
- 0x02
- Indicates if the delta values used in an adjustment are updated.
* - ``V4L2_VP8_LF_FILTER_TYPE_SIMPLE``
- 0x04
- If set, indicates the filter type is simple.
If cleared, the filter type is normal.
.. c:type:: v4l2_vp8_quantization
.. tabularcolumns:: |p{1.5cm}|p{3.5cm}|p{12.3cm}|
.. flat-table:: struct v4l2_vp8_quantization
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``y_ac_qi``
- Luma AC coefficient table index.
* - __s8
- ``y_dc_delta``
- Luma DC delta vaue.
* - __s8
- ``y2_dc_delta``
- Y2 block DC delta value.
* - __s8
- ``y2_ac_delta``
- Y2 block AC delta value.
* - __s8
- ``uv_dc_delta``
- Chroma DC delta value.
* - __s8
- ``uv_ac_delta``
- Chroma AC delta value.
* - __u16
- ``padding``
- Applications and drivers must set this to zero.
.. c:type:: v4l2_vp8_entropy
.. cssclass:: longtable
.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}|
.. flat-table:: struct v4l2_vp8_entropy
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``coeff_probs[4][8][3][11]``
- Coefficient update probabilities.
* - __u8
- ``y_mode_probs[4]``
- Luma mode update probabilities.
* - __u8
- ``uv_mode_probs[3]``
- Chroma mode update probabilities.
* - __u8
- ``mv_probs[2][19]``
- MV decoding update probabilities.
* - __u8
- ``padding[3]``
- Applications and drivers must set this to zero.

672
Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
View File

File diff suppressed because it is too large Load Diff

93
Documentation/userspace-api/media/v4l/ext-ctrls-colorimetry.rst Normal file
View File

@@ -0,0 +1,93 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _colorimetry-controls:
*****************************
Colorimetry Control Reference
*****************************
The Colorimetry class includes controls for High Dynamic Range
imaging for representing colors in digital images and video. The
controls should be used for video and image encoding and decoding
as well as in HDMI receivers and transmitters.
Colorimetry Control IDs
-----------------------
.. _colorimetry-control-id:
``V4L2_CID_COLORIMETRY_CLASS (class)``
The Colorimetry class descriptor. Calling
:ref:`VIDIOC_QUERYCTRL` for this control will
return a description of this control class.
``V4L2_CID_COLORIMETRY_HDR10_CLL_INFO (struct)``
The Content Light Level defines upper bounds for the nominal target
brightness light level of the pictures.
.. c:type:: v4l2_ctrl_hdr10_cll_info
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_hdr10_cll_info
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u16
- ``max_content_light_level``
- The upper bound for the maximum light level among all individual
samples for the pictures of a video sequence, cd/m\ :sup:`2`.
When equal to 0 no such upper bound is present.
* - __u16
- ``max_pic_average_light_level``
- The upper bound for the maximum average light level among the
samples for any individual picture of a video sequence,
cd/m\ :sup:`2`. When equal to 0 no such upper bound is present.
``V4L2_CID_COLORIMETRY_HDR10_MASTERING_DISPLAY (struct)``
The mastering display defines the color volume (the color primaries,
white point and luminance range) of a display considered to be the
mastering display for the current video content.
.. c:type:: v4l2_ctrl_hdr10_mastering_display
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_hdr10_mastering_display
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u16
- ``display_primaries_x[3]``
- Specifies the normalized x chromaticity coordinate of the color
primary component c of the mastering display in increments of 0.00002.
For describing the mastering display that uses Red, Green and Blue
color primaries, index value c equal to 0 corresponds to the Green
primary, c equal to 1 corresponds to Blue primary and c equal to 2
corresponds to the Red color primary.
* - __u16
- ``display_primaries_y[3]``
- Specifies the normalized y chromaticity coordinate of the color
primary component c of the mastering display in increments of 0.00002.
For describing the mastering display that uses Red, Green and Blue
color primaries, index value c equal to 0 corresponds to the Green
primary, c equal to 1 corresponds to Blue primary and c equal to 2
corresponds to Red color primary.
* - __u16
- ``white_point_x``
- Specifies the normalized x chromaticity coordinate of the white
point of the mastering display in increments of 0.00002.
* - __u16
- ``white_point_y``
- Specifies the normalized y chromaticity coordinate of the white
point of the mastering display in increments of 0.00002.
* - __u32
- ``max_luminance``
- Specifies the nominal maximum display luminance of the mastering
display in units of 0.0001 cd/m\ :sup:`2`.
* - __u32
- ``min_luminance``
- specifies the nominal minimum display luminance of the mastering
display in units of 0.0001 cd/m\ :sup:`2`.

2
Documentation/userspace-api/media/v4l/ext-ctrls-dv.rst
View File

@@ -99,7 +99,7 @@ enum v4l2_dv_it_content_type -
or an analog source. The enum v4l2_dv_it_content_type defines
the possible content types:
.. tabularcolumns:: |p{7.3cm}|p{10.4cm}|
.. tabularcolumns:: |p{7.3cm}|p{10.2cm}|
.. flat-table::
:header-rows: 0

7
Documentation/userspace-api/media/v4l/ext-ctrls-flash.rst
View File

@@ -63,6 +63,7 @@ Flash Control IDs
presence of some faults. See V4L2_CID_FLASH_FAULT.
.. tabularcolumns:: |p{5.7cm}|p{11.8cm}|
.. flat-table::
:header-rows: 0
@@ -73,14 +74,16 @@ Flash Control IDs
* - ``V4L2_FLASH_LED_MODE_FLASH``
- Flash mode.
* - ``V4L2_FLASH_LED_MODE_TORCH``
- Torch mode. See V4L2_CID_FLASH_TORCH_INTENSITY.
- Torch mode.
See V4L2_CID_FLASH_TORCH_INTENSITY.
``V4L2_CID_FLASH_STROBE_SOURCE (menu)``
Defines the source of the flash LED strobe.
.. tabularcolumns:: |p{7.5cm}|p{10.0cm}|
.. tabularcolumns:: |p{7.5cm}|p{7.5cm}|
.. flat-table::
:header-rows: 0

13
Documentation/userspace-api/media/v4l/ext-ctrls-jpeg.rst
View File

@@ -64,13 +64,12 @@ JPEG Control IDs
.. _jpeg-quality-control:
``V4L2_CID_JPEG_COMPRESSION_QUALITY (integer)``
``V4L2_CID_JPEG_COMPRESSION_QUALITY`` control determines trade-off
between image quality and size. It provides simpler method for
applications to control image quality, without a need for direct
reconfiguration of luminance and chrominance quantization tables. In
cases where a driver uses quantization tables configured directly by
an application, using interfaces defined elsewhere,
``V4L2_CID_JPEG_COMPRESSION_QUALITY`` control should be set by
Determines trade-off between image quality and size.
It provides simpler method for applications to control image quality,
without a need for direct reconfiguration of luminance and chrominance
quantization tables. In cases where a driver uses quantization tables
configured directly by an application, using interfaces defined
elsewhere, ``V4L2_CID_JPEG_COMPRESSION_QUALITY`` control should be set by
driver to 0.
The value range of this control is driver-specific. Only positive,

2
Documentation/userspace-api/media/v4l/field-order.rst
View File

@@ -62,7 +62,7 @@ enum v4l2_field
.. c:type:: v4l2_field
.. tabularcolumns:: |p{5.8cm}|p{0.6cm}|p{11.1cm}|
.. tabularcolumns:: |p{5.8cm}|p{0.6cm}|p{10.9cm}|
.. cssclass:: longtable

27
Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
View File

@@ -7,7 +7,13 @@ Compressed Formats
.. _compressed-formats:
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. raw:: latex
\small
.. tabularcolumns:: |p{5.8cm}|p{1.2cm}|p{10.3cm}|
.. cssclass:: longtable
.. flat-table:: Compressed Image Formats
:header-rows: 1
@@ -147,22 +153,17 @@ Compressed Formats
- ``V4L2_PIX_FMT_VP8_FRAME``
- 'VP8F'
- VP8 parsed frame, as extracted from the container.
This format is adapted for stateless video decoders that implement a
VP8 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`).
- VP8 parsed frame, including the frame header, as extracted from the container.
This format is adapted for stateless video decoders that implement an
VP8 pipeline with the :ref:`stateless_decoder`.
Metadata associated with the frame to decode is required to be passed
through the ``V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER`` control.
See the :ref:`associated Codec Control IDs <v4l2-mpeg-vp8>`.
through the ``V4L2_CID_STATELESS_VP8_FRAME`` control.
See the :ref:`associated Codec Control IDs <v4l2-codec-stateless-vp8>`.
Exactly one output and one capture buffer must be provided for use with
this pixel format. The output buffer must contain the appropriate number
of macroblocks to decode a full corresponding frame to the matching
capture buffer.
.. note::
This format is not yet part of the public kernel API and it
is expected to change.
* .. _V4L2-PIX-FMT-VP9:
- ``V4L2_PIX_FMT_VP9``
@@ -220,3 +221,7 @@ Compressed Formats
Metadata associated with the frame to decode is required to be passed
through the ``V4L2_CID_STATELESS_FWHT_PARAMS`` control.
See the :ref:`associated Codec Control ID <codec-stateless-fwht>`.
.. raw:: latex
\normalsize

36
Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
View File

@@ -36,10 +36,10 @@ Cb\ :sub:`5-0` Cr\ :sub:`4-0`], and stored in memory in two bytes,
.. raw:: latex
\begingroup
\tiny
\scriptsize
\setlength{\tabcolsep}{2pt}
.. tabularcolumns:: |p{2.5cm}|p{0.69cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|
.. tabularcolumns:: |p{3.5cm}|p{0.96cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|p{0.52cm}|
.. flat-table:: Packed YUV 4:4:4 Image Formats (less than 8bpc)
:header-rows: 2
@@ -220,6 +220,16 @@ the second byte and Y'\ :sub:`7-0` in the third byte.
- Y'\ :sub:`7-0`
- X\ :sub:`7-0`
* .. _V4L2-PIX-FMT-YUV24:
- ``V4L2_PIX_FMT_YUV24``
- 'YUV3'
- Y'\ :sub:`7-0`
- Cb\ :sub:`7-0`
- Cr\ :sub:`7-0`
- -\
.. note::
- The alpha component is expected to contain a meaningful value that can be
@@ -234,6 +244,12 @@ the second byte and Y'\ :sub:`7-0` in the third byte.
These formats, commonly referred to as YUYV or YUY2, subsample the chroma
components horizontally by 2, storing 2 pixels in 4 bytes.
.. raw:: latex
\footnotesize
.. tabularcolumns:: |p{3.4cm}|p{1.2cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
.. flat-table:: Packed YUV 4:2:2 Formats
:header-rows: 1
:stub-columns: 0
@@ -301,6 +317,10 @@ components horizontally by 2, storing 2 pixels in 4 bytes.
- Y'\ :sub:`3`
- Cb\ :sub:`2`
.. raw:: latex
\normalsize
**Color Sample Location:**
Chroma samples are :ref:`interstitially sited<yuv-chroma-centered>`
horizontally.
@@ -312,6 +332,12 @@ horizontally.
This format subsamples the chroma components horizontally by 4, storing 8
pixels in 12 bytes.
.. raw:: latex
\scriptsize
.. tabularcolumns:: |p{2.9cm}|p{0.8cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|p{0.5cm}|
.. flat-table:: Packed YUV 4:1:1 Formats
:header-rows: 1
:stub-columns: 0
@@ -348,11 +374,15 @@ pixels in 12 bytes.
- Y'\ :sub:`6`
- Y'\ :sub:`7`
.. raw:: latex
\normalsize
.. note::
Do not confuse ``V4L2_PIX_FMT_Y41P`` with
:ref:`V4L2_PIX_FMT_YUV411P <V4L2-PIX-FMT-YUV411P>`. Y41P is derived from
"YUV 4:1:1 *packed*", while YUV411P stands for "YUV 4:1:1 *planar*".
"YUV 4:1:1 **packed**", while YUV411P stands for "YUV 4:1:1 **planar**".
**Color Sample Location:**
Chroma samples are :ref:`interstitially sited<yuv-chroma-centered>`

10
Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
View File

@@ -17,7 +17,11 @@ you think your format should be listed in a standard format section
please make a proposal on the linux-media mailing list.
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.5cm}|
.. raw:: latex
\small
.. _reserved-formats:
@@ -256,3 +260,7 @@ please make a proposal on the linux-media mailing list.
of tiles, resulting in 32-aligned resolutions for the luminance plane
and 16-aligned resolutions for the chrominance plane (with 2x2
subsampling).
.. raw:: latex
\normalsize

9
Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
View File

@@ -655,12 +655,7 @@ nomenclature that instead use the order of components as seen in a 24- or
.. raw:: latex
\begingroup
\tiny
\setlength{\tabcolsep}{2pt}
.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|
\small
.. flat-table:: RGB Formats With 8 Bits Per Component
:header-rows: 1
@@ -765,7 +760,7 @@ nomenclature that instead use the order of components as seen in a 24- or
.. raw:: latex
\endgroup
\normalsize
Deprecated RGB Formats

12
Documentation/userspace-api/media/v4l/pixfmt-srggb10-ipu3.rst
View File

@@ -9,7 +9,9 @@
V4L2_PIX_FMT_IPU3_SBGGR10 ('ip3b'), V4L2_PIX_FMT_IPU3_SGBRG10 ('ip3g'), V4L2_PIX_FMT_IPU3_SGRBG10 ('ip3G'), V4L2_PIX_FMT_IPU3_SRGGB10 ('ip3r')
**********************************************************************************************************************************************
====================
10-bit Bayer formats
====================
Description
===========
@@ -25,7 +27,11 @@ Below is an example of a small image in V4L2_PIX_FMT_IPU3_SBGGR10 format.
**Byte Order.**
Each cell is one byte.
.. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}|p{4.0cm}|p{4.0cm}|
.. raw:: latex
\small
.. tabularcolumns:: |p{0.8cm}|p{3.3cm}|p{3.3cm}|p{3.3cm}|p{3.3cm}|
.. flat-table::
@@ -333,3 +339,7 @@ Each cell is one byte.
- R\ :sub:`0323high`
- G\ :sub:`0324low`
- G\ :sub:`0324high`\ (bits 1--0)
.. raw:: latex
\normalsize

Some files were not shown because too many files have changed in this diff Show More