shinys000114/linux
1
0
Fork 0
mirror of https://github.com/hardkernel/linux.git synced 2026-06-07 11:26:02 +09:00
Code Issues Packages Projects Releases Wiki Activity

Merge 449dc8c970 ("Merge tag 'for-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply") into android-mainline

Browse Source 
Merges along the way to 5.9-rc1

resolves conflicts in:
	Documentation/ABI/testing/sysfs-class-power
	drivers/power/supply/power_supply_sysfs.c
	fs/crypto/inline_crypt.c

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia087834f54fb4e5269d68c3c404747ceed240701
This commit is contained in:
Greg Kroah-Hartman
2020-08-08 13:07:20 +02:00
parent fe0d068d7c 449dc8c970
commit a17a563d16
1659 changed files with 47145 additions and 31970 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
Documentation/ABI/stable/sysfs-driver-dma-idxd
View File

@@ -1,47 +1,47 @@
What: sys/bus/dsa/devices/dsa<m>/version
What: /sys/bus/dsa/devices/dsa<m>/version
Date: Apr 15, 2020
KernelVersion: 5.8.0
Contact: dmaengine@vger.kernel.org
Description: The hardware version number.
What: sys/bus/dsa/devices/dsa<m>/cdev_major
What: /sys/bus/dsa/devices/dsa<m>/cdev_major
Date: Oct 25, 2019
KernelVersion: 5.6.0
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The major number that the character device driver assigned to
this device.
What: sys/bus/dsa/devices/dsa<m>/errors
What: /sys/bus/dsa/devices/dsa<m>/errors
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The error information for this device.
What: sys/bus/dsa/devices/dsa<m>/max_batch_size
What: /sys/bus/dsa/devices/dsa<m>/max_batch_size
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The largest number of work descriptors in a batch.
What: sys/bus/dsa/devices/dsa<m>/max_work_queues_size
What: /sys/bus/dsa/devices/dsa<m>/max_work_queues_size
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The maximum work queue size supported by this device.
What: sys/bus/dsa/devices/dsa<m>/max_engines
What: /sys/bus/dsa/devices/dsa<m>/max_engines
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The maximum number of engines supported by this device.
What: sys/bus/dsa/devices/dsa<m>/max_groups
What: /sys/bus/dsa/devices/dsa<m>/max_groups
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The maximum number of groups can be created under this device.
What: sys/bus/dsa/devices/dsa<m>/max_tokens
What: /sys/bus/dsa/devices/dsa<m>/max_tokens
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
@@ -50,7 +50,7 @@ Description: The total number of bandwidth tokens supported by this device.
implementation, and these resources are allocated by engines to
support operations.
What: sys/bus/dsa/devices/dsa<m>/max_transfer_size
What: /sys/bus/dsa/devices/dsa<m>/max_transfer_size
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
@@ -58,57 +58,57 @@ Description: The number of bytes to be read from the source address to
perform the operation. The maximum transfer size is dependent on
the workqueue the descriptor was submitted to.
What: sys/bus/dsa/devices/dsa<m>/max_work_queues
What: /sys/bus/dsa/devices/dsa<m>/max_work_queues
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The maximum work queue number that this device supports.
What: sys/bus/dsa/devices/dsa<m>/numa_node
What: /sys/bus/dsa/devices/dsa<m>/numa_node
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The numa node number for this device.
What: sys/bus/dsa/devices/dsa<m>/op_cap
What: /sys/bus/dsa/devices/dsa<m>/op_cap
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The operation capability bit mask specify the operation types
supported by the this device.
What: sys/bus/dsa/devices/dsa<m>/state
What: /sys/bus/dsa/devices/dsa<m>/state
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The state information of this device. It can be either enabled
or disabled.
What: sys/bus/dsa/devices/dsa<m>/group<m>.<n>
What: /sys/bus/dsa/devices/dsa<m>/group<m>.<n>
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The assigned group under this device.
What: sys/bus/dsa/devices/dsa<m>/engine<m>.<n>
What: /sys/bus/dsa/devices/dsa<m>/engine<m>.<n>
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The assigned engine under this device.
What: sys/bus/dsa/devices/dsa<m>/wq<m>.<n>
What: /sys/bus/dsa/devices/dsa<m>/wq<m>.<n>
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The assigned work queue under this device.
What: sys/bus/dsa/devices/dsa<m>/configurable
What: /sys/bus/dsa/devices/dsa<m>/configurable
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: To indicate if this device is configurable or not.
What: sys/bus/dsa/devices/dsa<m>/token_limit
What: /sys/bus/dsa/devices/dsa<m>/token_limit
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
@@ -116,19 +116,19 @@ Description: The maximum number of bandwidth tokens that may be in use at
one time by operations that access low bandwidth memory in the
device.
What: sys/bus/dsa/devices/wq<m>.<n>/group_id
What: /sys/bus/dsa/devices/wq<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The group id that this work queue belongs to.
What: sys/bus/dsa/devices/wq<m>.<n>/size
What: /sys/bus/dsa/devices/wq<m>.<n>/size
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The work queue size for this work queue.
What: sys/bus/dsa/devices/wq<m>.<n>/type
What: /sys/bus/dsa/devices/wq<m>.<n>/type
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
@@ -136,20 +136,20 @@ Description: The type of this work queue, it can be "kernel" type for work
queue usages in the kernel space or "user" type for work queue
usages by applications in user space.
What: sys/bus/dsa/devices/wq<m>.<n>/cdev_minor
What: /sys/bus/dsa/devices/wq<m>.<n>/cdev_minor
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The minor number assigned to this work queue by the character
device driver.
What: sys/bus/dsa/devices/wq<m>.<n>/mode
What: /sys/bus/dsa/devices/wq<m>.<n>/mode
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The work queue mode type for this work queue.
What: sys/bus/dsa/devices/wq<m>.<n>/priority
What: /sys/bus/dsa/devices/wq<m>.<n>/priority
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
@@ -157,20 +157,20 @@ Description: The priority value of this work queue, it is a vlue relative to
other work queue in the same group to control quality of service
for dispatching work from multiple workqueues in the same group.
What: sys/bus/dsa/devices/wq<m>.<n>/state
What: /sys/bus/dsa/devices/wq<m>.<n>/state
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The current state of the work queue.
What: sys/bus/dsa/devices/wq<m>.<n>/threshold
What: /sys/bus/dsa/devices/wq<m>.<n>/threshold
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The number of entries in this work queue that may be filled
via a limited portal.
What: sys/bus/dsa/devices/engine<m>.<n>/group_id
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org

7
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
View File

@@ -43,6 +43,13 @@ Description: read only
This sysfs interface exposes the number of cores per chip
present in the system.
What: /sys/devices/hv_24x7/interface/cpumask
Date: July 2020
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description: read only
This sysfs file exposes the cpumask which is designated to make
HCALLs to retrieve hv-24x7 pmu event counter data.
What: /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name>
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>

27
Documentation/ABI/testing/sysfs-bus-papr-pmem
View File

@@ -25,3 +25,30 @@ Description:
NVDIMM have been scrubbed.
* "locked" : Indicating that NVDIMM contents cant
be modified until next power cycle.
What: /sys/bus/nd/devices/nmemX/papr/perf_stats
Date: May, 2020
KernelVersion: v5.9
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
Description:
(RO) Report various performance stats related to papr-scm NVDIMM
device. Each stat is reported on a new line with each line
composed of a stat-identifier followed by it value. Below are
currently known dimm performance stats which are reported:
* "CtlResCt" : Controller Reset Count
* "CtlResTm" : Controller Reset Elapsed Time
* "PonSecs " : Power-on Seconds
* "MemLife " : Life Remaining
* "CritRscU" : Critical Resource Utilization
* "HostLCnt" : Host Load Count
* "HostSCnt" : Host Store Count
* "HostSDur" : Host Store Duration
* "HostLDur" : Host Load Duration
* "MedRCnt " : Media Read Count
* "MedWCnt " : Media Write Count
* "MedRDur " : Media Read Duration
* "MedWDur " : Media Write Duration
* "CchRHCnt" : Cache Read Hit Count
* "CchWHCnt" : Cache Write Hit Count
* "FastWCnt" : Fast Write Count

11
Documentation/ABI/testing/sysfs-class-ocxl
View File

@@ -33,3 +33,14 @@ Date: January 2018
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Give access the global mmio area for the AFU
What: /sys/class/ocxl/<afu name>/reload_on_reset
Date: February 2020
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Control whether the FPGA is reloaded on a link reset. Enabled
through a vendor-specific logic block on the FPGA.
0 Do not reload FPGA image from flash
1 Reload FPGA image from flash
unavailable
The device does not support this capability

4
Documentation/ABI/testing/sysfs-class-power
View File

@@ -205,8 +205,8 @@ Description:
Valid values: "Unknown", "Good", "Overheat", "Dead",
"Over voltage", "Unspecified failure", "Cold",
"Watchdog timer expire", "Safety timer expire",
"Over current", "Calibration required",
"Warm", "Cool", "Hot"
"Over current", "Calibration required", "Warm",
"Cool", "Hot"
What: /sys/class/power_supply/<supply_name>/precharge_current
Date: June 2017

4
Documentation/ABI/testing/sysfs-class-power-wilco
View File

@@ -14,6 +14,10 @@ Description:
Charging begins when level drops below
charge_control_start_threshold, and ceases when
level is above charge_control_end_threshold.
Long Life: Customized charge rate for last longer battery life.
On Wilco device this mode is pre-configured in the factory
through EC's private PID. Swiching to a different mode will
be denied by Wilco EC when Long Life mode is enabled.
What: /sys/class/power_supply/wilco-charger/charge_control_start_threshold
Date: April 2019

8
Documentation/PCI/pci-error-recovery.rst
View File

@@ -79,7 +79,7 @@ This structure has the form::
struct pci_error_handlers
{
int (*error_detected)(struct pci_dev *dev, enum pci_channel_state);
int (*error_detected)(struct pci_dev *dev, pci_channel_state_t);
int (*mmio_enabled)(struct pci_dev *dev);
int (*slot_reset)(struct pci_dev *dev);
void (*resume)(struct pci_dev *dev);
@@ -87,11 +87,11 @@ This structure has the form::
The possible channel states are::
enum pci_channel_state {
typedef enum {
pci_channel_io_normal, /* I/O channel is in normal state */
pci_channel_io_frozen, /* I/O to channel is blocked */
pci_channel_io_perm_failure, /* PCI card is dead */
};
} pci_channel_state_t;
Possible return values are::
@@ -348,7 +348,7 @@ STEP 6: Permanent Failure
-------------------------
A "permanent failure" has occurred, and the platform cannot recover
the device. The platform will call error_detected() with a
pci_channel_state value of pci_channel_io_perm_failure.
pci_channel_state_t value of pci_channel_io_perm_failure.
The device driver should, at this point, assume the worst. It should
cancel all pending I/O, refuse all new I/O, returning -EIO to

9
Documentation/PCI/pci.rst
View File

@@ -17,7 +17,7 @@ PCI device drivers.
A more complete resource is the third edition of "Linux Device Drivers"
by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman.
LDD3 is available for free (under Creative Commons License) from:
http://lwn.net/Kernel/LDD3/.
https://lwn.net/Kernel/LDD3/.
However, keep in mind that all documents are subject to "bit rot".
Refer to the source code if things are not working as described here.
@@ -214,7 +214,7 @@ the PCI device by calling pci_enable_device(). This will:
problem and unlikely to get fixed soon.
This has been discussed before but not changed as of 2.6.19:
http://lkml.org/lkml/2006/3/2/194
https://lore.kernel.org/r/20060302180025.GC28895@flint.arm.linux.org.uk/
pci_set_master() will enable DMA by setting the bus master bit
@@ -514,9 +514,8 @@ your driver if they're helpful, or just use plain hex constants.
The device IDs are arbitrary hex numbers (vendor controlled) and normally used
only in a single location, the pci_device_id table.
Please DO submit new vendor/device IDs to http://pci-ids.ucw.cz/.
There are mirrors of the pci.ids file at http://pciids.sourceforge.net/
and https://github.com/pciutils/pciids.
Please DO submit new vendor/device IDs to https://pci-ids.ucw.cz/.
There's a mirror of the pci.ids file at https://github.com/pciutils/pciids.
Obsolete functions

11
Documentation/admin-guide/bootconfig.rst
View File

@@ -71,6 +71,16 @@ For example,::
foo = bar, baz
foo = qux # !ERROR! we can not re-define same key
If you want to update the value, you must use the override operator
``:=`` explicitly. For example::
foo = bar, baz
foo := qux
then, the ``qux`` is assigned to ``foo`` key. This is useful for
overriding the default value by adding (partial) custom bootconfigs
without parsing the default bootconfig.
If you want to append the value to existing key as an array member,
you can use ``+=`` operator. For example::
@@ -84,6 +94,7 @@ For example, following config is NOT allowed.::
foo = value1
foo.bar = value2 # !ERROR! subkey "bar" and value "value1" can NOT co-exist
foo.bar := value2 # !ERROR! even with the override operator, this is NOT allowed.
Comments

32
Documentation/admin-guide/device-mapper/dm-dust.rst
View File

@@ -69,10 +69,11 @@ Create the dm-dust device:
$ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 4096'
Check the status of the read behavior ("bypass" indicates that all I/O
will be passed through to the underlying device)::
will be passed through to the underlying device; "verbose" indicates that
bad block additions, removals, and remaps will be verbosely logged)::
$ sudo dmsetup status dust1
0 33552384 dust 252:17 bypass
0 33552384 dust 252:17 bypass verbose
$ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=128 iflag=direct
128+0 records in
@@ -164,7 +165,7 @@ following message command::
A message will print with the number of bad blocks currently
configured on the device::
kernel: device-mapper: dust: countbadblocks: 895 badblock(s) found
countbadblocks: 895 badblock(s) found
Querying for specific bad blocks
--------------------------------
@@ -176,11 +177,11 @@ following message command::
The following message will print if the block is in the list::
device-mapper: dust: queryblock: block 72 found in badblocklist
dust_query_block: block 72 found in badblocklist
The following message will print if the block is not in the list::
device-mapper: dust: queryblock: block 72 not found in badblocklist
dust_query_block: block 72 not found in badblocklist
The "queryblock" message command will work in both the "enabled"
and "disabled" modes, allowing the verification of whether a block
@@ -198,12 +199,28 @@ following message command::
After clearing the bad block list, the following message will appear::
kernel: device-mapper: dust: clearbadblocks: badblocks cleared
dust_clear_badblocks: badblocks cleared
If there were no bad blocks to clear, the following message will
appear::
kernel: device-mapper: dust: clearbadblocks: no badblocks found
dust_clear_badblocks: no badblocks found
Listing the bad block list
--------------------------
To list all bad blocks in the bad block list (using an example device
with blocks 1 and 2 in the bad block list), run the following message
command::
$ sudo dmsetup message dust1 0 listbadblocks
1
2
If there are no bad blocks in the bad block list, the command will
execute with no output::
$ sudo dmsetup message dust1 0 listbadblocks
Message commands list
---------------------
@@ -223,6 +240,7 @@ Single argument message commands::
countbadblocks
clearbadblocks
listbadblocks
disable
enable
quiet

4
Documentation/admin-guide/device-mapper/verity.rst
View File

@@ -83,6 +83,10 @@ restart_on_corruption
not compatible with ignore_corruption and requires user space support to
avoid restart loops.
panic_on_corruption
Panic the device when a corrupted block is discovered. This option is
not compatible with ignore_corruption and restart_on_corruption.
ignore_zero_blocks
Do not verify blocks that are expected to contain zeroes and always return
zeroes instead. This may be useful if the partition contains unused blocks

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

@@ -916,6 +916,10 @@
disable_radix [PPC]
Disable RADIX MMU mode on POWER9
radix_hcall_invalidate=on [PPC/PSERIES]
Disable RADIX GTSE feature and use hcall for TLB
invalidate.
disable_tlbie [PPC]
Disable TLBIE instruction. Currently does not work
with KVM, with HASH MMU, or with coherent accelerators.
@@ -4689,7 +4693,7 @@
fragmentation. Defaults to 1 for systems with
more than 32MB of RAM, 0 otherwise.
slub_debug[=options[,slabs]] [MM, SLUB]
slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB]
Enabling slub_debug allows one to determine the
culprit if slab objects become corrupted. Enabling
slub_debug can create guard zones around objects and

6
Documentation/admin-guide/media/fimc.rst
View File

@@ -2,7 +2,7 @@
.. include:: <isonum.txt>
The Samsung S5P/EXYNOS4 FIMC driver
The Samsung S5P/Exynos4 FIMC driver
===================================
Copyright |copy| 2012 - 2013 Samsung Electronics Co., Ltd.
@@ -19,7 +19,7 @@ drivers/media/platform/exynos4-is directory.
Supported SoCs
--------------
S5PC100 (mem-to-mem only), S5PV210, EXYNOS4210
S5PC100 (mem-to-mem only), S5PV210, Exynos4210
Supported features
------------------
@@ -45,7 +45,7 @@ Media device interface
~~~~~~~~~~~~~~~~~~~~~~
The driver supports Media Controller API as defined at :ref:`media_controller`.
The media device driver name is "SAMSUNG S5P FIMC".
The media device driver name is "Samsung S5P FIMC".
The purpose of this interface is to allow changing assignment of FIMC instances
to the SoC peripheral camera input at runtime and optionally to control internal

9
Documentation/admin-guide/media/vivid.rst
View File

@@ -293,6 +293,15 @@ all configurable using the following module options:
- 0: vmalloc
- 1: dma-contig
- cache_hints:
specifies if the device should set queues' user-space cache and memory
consistency hint capability (V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS).
The hints are valid only when using MMAP streaming I/O. Default is 0.
- 0: forbid hints
- 1: allow hints
Taken together, all these module options allow you to precisely customize
the driver behavior and test your application with all sorts of permutations.
It is also very suitable to emulate hardware that is not yet available, e.g.

7
Documentation/core-api/cpu_hotplug.rst
View File

@@ -50,13 +50,6 @@ Command Line Switches
This option is limited to the X86 and S390 architecture.
``cede_offline={"off","on"}``
Use this option to disable/enable putting offlined processors to an extended
``H_CEDE`` state on supported pseries platforms. If nothing is specified,
``cede_offline`` is set to "on".
This option is limited to the PowerPC architecture.
``cpu0_hotplug``
Allow to shutdown CPU0.

10
Documentation/dev-tools/kasan.rst
View File

@@ -13,11 +13,8 @@ KASAN uses compile-time instrumentation to insert validity checks before every
memory access, and therefore requires a compiler version that supports that.
Generic KASAN is supported in both GCC and Clang. With GCC it requires version
4.9.2 or later for basic support and version 5.0 or later for detection of
out-of-bounds accesses for stack and global variables and for inline
instrumentation mode (see the Usage section). With Clang it requires version
7.0.0 or later and it doesn't support detection of out-of-bounds accesses for
global variables yet.
8.3.0 or later. With Clang it requires version 7.0.0 or later, but detection of
out-of-bounds accesses for global variables is only supported since Clang 11.
Tag-based KASAN is only supported in Clang and requires version 7.0.0 or later.
@@ -193,6 +190,9 @@ function calls GCC directly inserts the code to check the shadow memory.
This option significantly enlarges kernel but it gives x1.1-x2 performance
boost over outline instrumented kernel.
Generic KASAN prints up to 2 call_rcu() call stacks in reports, the last one
and the second to last.
Software tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~

14
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
View File

@@ -1,14 +0,0 @@
Raspberry Pi VideoCore firmware driver
Required properties:
- compatible: Should be "raspberrypi,bcm2835-firmware"
- mboxes: Phandle to the firmware device's Mailbox.
(See: ../mailbox/mailbox.txt for more information)
Example:
firmware {
compatible = "raspberrypi,bcm2835-firmware";
mboxes = <&mailbox>;
};

59
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml Normal file
View File

@@ -0,0 +1,59 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Raspberry Pi VideoCore firmware driver
maintainers:
- Eric Anholt <eric@anholt.net>
- Stefan Wahren <wahrenst@gmx.net>
properties:
compatible:
items:
- const: raspberrypi,bcm2835-firmware
- const: simple-bus
mboxes:
$ref: '/schemas/types.yaml#/definitions/phandle'
description: |
Phandle to the firmware device's Mailbox.
(See: ../mailbox/mailbox.txt for more information)
clocks:
type: object
properties:
compatible:
const: raspberrypi,firmware-clocks
"#clock-cells":
const: 1
description: >
The argument is the ID of the clocks contained by the
firmware messages.
required:
- compatible
- "#clock-cells"
additionalProperties: false
required:
- compatible
- mboxes
examples:
- |
firmware {
compatible = "raspberrypi,bcm2835-firmware", "simple-bus";
mboxes = <&mailbox>;
firmware_clocks: clocks {
compatible = "raspberrypi,firmware-clocks";
#clock-cells = <1>;
};
};
...

69
Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml Normal file
View File

@@ -0,0 +1,69 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra194 CPU Complex device tree bindings
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jonathan Hunter <jonathanh@nvidia.com>
- Sumit Gupta <sumitg@nvidia.com>
description: |+
Tegra194 SOC has homogeneous architecture where each cluster has two
symmetric cores. Compatible string in "cpus" node represents the CPU
Complex having all clusters.
properties:
$nodename:
const: cpus
compatible:
enum:
- nvidia,tegra194-ccplex
nvidia,bpmp:
$ref: '/schemas/types.yaml#/definitions/phandle'
description: |
Specifies the bpmp node that needs to be queried to get
operating point data for all CPUs.
examples:
- |
cpus {
compatible = "nvidia,tegra194-ccplex";
nvidia,bpmp = <&bpmp>;
#address-cells = <1>;
#size-cells = <0>;
cpu0_0: cpu@0 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x0>;
enable-method = "psci";
};
cpu0_1: cpu@1 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x001>;
enable-method = "psci";
};
cpu1_0: cpu@100 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x100>;
enable-method = "psci";
};
cpu1_1: cpu@101 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x101>;
enable-method = "psci";
};
};
...

47
Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml Normal file
View File

@@ -0,0 +1,47 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/brcm,bcm2711-dvp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM2711 HDMI DVP Device Tree Bindings
maintainers:
- Maxime Ripard <mripard@kernel.org>
properties:
"#clock-cells":
const: 1
"#reset-cells":
const: 1
compatible:
const: brcm,brcm2711-dvp
reg:
maxItems: 1
clocks:
maxItems: 1
required:
- "#clock-cells"
- "#reset-cells"
- compatible
- reg
- clocks
additionalProperties: false
examples:
- |
dvp: clock@7ef00000 {
compatible = "brcm,brcm2711-dvp";
reg = <0x7ef00000 0x10>;
clocks = <&clk_108MHz>;
#clock-cells = <1>;
#reset-cells = <1>;
};
...

2
Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.txt
View File

@@ -3,6 +3,8 @@ Gated Clock Controller Bindings for MIPS based BCM63XX SoCs
Required properties:
- compatible: must be one of:
"brcm,bcm3368-clocks"
"brcm,bcm6318-clocks"
"brcm,bcm6318-ubus-clocks"
"brcm,bcm6328-clocks"
"brcm,bcm6358-clocks"
"brcm,bcm6362-clocks"

2
Documentation/devicetree/bindings/clock/clock-bindings.txt
View File

@@ -9,7 +9,7 @@ specifier is an array of zero, one or more cells identifying the clock
output on a device. The length of a clock specifier is defined by the
value of a #clock-cells property in the clock provider node.
[1] http://patchwork.ozlabs.org/patch/31551/
[1] https://patchwork.ozlabs.org/patch/31551/
==Clock providers==

33
Documentation/devicetree/bindings/clock/idt,versaclock5.txt
View File

@@ -31,6 +31,29 @@ Required properties:
- 5p49v5933 and
- 5p49v5935: (optional) property not present or "clkin".
For all output ports, a corresponding, optional child node named OUT1,
OUT2, etc. can represent a each output, and the node can be used to
specify the following:
- itd,mode: can be one of the following:
- VC5_LVPECL
- VC5_CMOS
- VC5_HCSL33
- VC5_LVDS
- VC5_CMOS2
- VC5_CMOSD
- VC5_HCSL25
- idt,voltage-microvolts: can be one of the following
- 1800000
- 2500000
- 3300000
- idt,slew-percent: Percent of normal, can be one of
- 80
- 85
- 90
- 100
==Mapping between clock specifier and physical pins==
When referencing the provided clock in the DT using phandle and
@@ -81,6 +104,16 @@ i2c-master-node {
/* Connect XIN input to 25MHz reference */
clocks = <&ref25m>;
clock-names = "xin";
OUT1 {
itd,mode = <VC5_CMOS>;
idt,voltage-microvolts = <1800000>;
idt,slew-percent = <80>;
};
OUT2 {
...
};
...
};
};

21
Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
View File

@@ -15,7 +15,9 @@ description:
properties:
compatible:
const: qcom,msm8916-a53pll
enum:
- qcom,ipq6018-a53pll
- qcom,msm8916-a53pll
reg:
maxItems: 1
@@ -23,6 +25,14 @@ properties:
'#clock-cells':
const: 0
clocks:
items:
- description: board XO clock
clock-names:
items:
- const: xo
required:
- compatible
- reg
@@ -38,3 +48,12 @@ examples:
reg = <0xb016000 0x40>;
#clock-cells = <0>;
};
#Example 2 - A53 PLL found on IPQ6018 devices
- |
a53pll_ipq: clock-controller@b116000 {
compatible = "qcom,ipq6018-a53pll";
reg = <0x0b116000 0x40>;
#clock-cells = <0>;
clocks = <&xo>;
clock-names = "xo";
};

56
Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml Normal file
View File

@@ -0,0 +1,56 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,kryocc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm clock controller for MSM8996 CPUs
maintainers:
- Loic Poulain <loic.poulain@linaro.org>
description: |
Qualcomm CPU clock controller for MSM8996 CPUs, clock 0 is for Power cluster
and clock 1 is for Perf cluster.
properties:
compatible:
enum:
- qcom,msm8996-apcc
reg:
maxItems: 1
'#clock-cells':
const: 1
clocks:
items:
- description: Primary PLL clock for power cluster (little)
- description: Primary PLL clock for perf cluster (big)
- description: Alternate PLL clock for power cluster (little)
- description: Alternate PLL clock for perf cluster (big)
clock-names:
items:
- const: pwrcl_pll
- const: perfcl_pll
- const: pwrcl_alt_pll
- const: perfcl_alt_pll
required:
- compatible
- reg
- '#clock-cells'
additionalProperties: false
examples:
# Example for msm8996
- |
kryocc: clock-controller@6400000 {
compatible = "qcom,msm8996-apcc";
reg = <0x6400000 0x90000>;
#clock-cells = <1>;
};
...

4
Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
View File

@@ -13,13 +13,17 @@ Required properties :
"qcom,rpmcc-msm8660", "qcom,rpmcc"
"qcom,rpmcc-apq8060", "qcom,rpmcc"
"qcom,rpmcc-msm8916", "qcom,rpmcc"
"qcom,rpmcc-msm8936", "qcom,rpmcc"
"qcom,rpmcc-msm8974", "qcom,rpmcc"
"qcom,rpmcc-msm8976", "qcom,rpmcc"
"qcom,rpmcc-apq8064", "qcom,rpmcc"
"qcom,rpmcc-ipq806x", "qcom,rpmcc"
"qcom,rpmcc-msm8992",·"qcom,rpmcc"
"qcom,rpmcc-msm8994",·"qcom,rpmcc"
"qcom,rpmcc-msm8996", "qcom,rpmcc"
"qcom,rpmcc-msm8998", "qcom,rpmcc"
"qcom,rpmcc-qcs404", "qcom,rpmcc"
"qcom,rpmcc-sdm660", "qcom,rpmcc"
- #clock-cells : shall contain 1

241
Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml Normal file
View File

@@ -0,0 +1,241 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/renesas,cpg-clocks.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Clock Pulse Generator (CPG)
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
description:
The Clock Pulse Generator (CPG) generates core clocks for the SoC. It
includes PLLs, and fixed and variable ratio dividers.
The CPG may also provide a Clock Domain for SoC devices, in combination with
the CPG Module Stop (MSTP) Clocks.
properties:
compatible:
oneOf:
- const: renesas,r8a73a4-cpg-clocks # R-Mobile APE6
- const: renesas,r8a7740-cpg-clocks # R-Mobile A1
- const: renesas,r8a7778-cpg-clocks # R-Car M1
- const: renesas,r8a7779-cpg-clocks # R-Car H1
- items:
- enum:
- renesas,r7s72100-cpg-clocks # RZ/A1H
- const: renesas,rz-cpg-clocks # RZ/A1
- const: renesas,sh73a0-cpg-clocks # SH-Mobile AG5
reg:
maxItems: 1
clocks: true
'#clock-cells':
const: 1
clock-output-names: true
renesas,mode:
description: Board-specific settings of the MD_CK* bits on R-Mobile A1
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 7
'#power-domain-cells':
const: 0
required:
- compatible
- reg
- clocks
- '#clock-cells'
- clock-output-names
allOf:
- if:
properties:
compatible:
contains:
const: renesas,r8a73a4-cpg-clocks
then:
properties:
clocks:
items:
- description: extal1
- description: extal2
clock-output-names:
items:
- const: main
- const: pll0
- const: pll1
- const: pll2
- const: pll2s
- const: pll2h
- const: z
- const: z2
- const: i
- const: m3
- const: b
- const: m1
- const: m2
- const: zx
- const: zs
- const: hp
- if:
properties:
compatible:
contains:
const: renesas,r8a7740-cpg-clocks
then:
properties:
clocks:
items:
- description: extal1
- description: extal2
- description: extalr
clock-output-names:
items:
- const: system
- const: pllc0
- const: pllc1
- const: pllc2
- const: r
- const: usb24s
- const: i
- const: zg
- const: b
- const: m1
- const: hp
- const: hpp
- const: usbp
- const: s
- const: zb
- const: m3
- const: cp
required:
- renesas,mode
- if:
properties:
compatible:
contains:
const: renesas,r8a7778-cpg-clocks
then:
properties:
clocks:
maxItems: 1
clock-output-names:
items:
- const: plla
- const: pllb
- const: b
- const: out
- const: p
- const: s
- const: s1
- if:
properties:
compatible:
contains:
const: renesas,r8a7779-cpg-clocks
then:
properties:
clocks:
maxItems: 1
clock-output-names:
items:
- const: plla
- const: z
- const: zs
- const: s
- const: s1
- const: p
- const: b
- const: out
- if:
properties:
compatible:
contains:
const: renesas,r7s72100-cpg-clocks
then:
properties:
clocks:
items:
- description: extal1
- description: usb_x1
clock-output-names:
items:
- const: pll
- const: i
- const: g
- if:
properties:
compatible:
contains:
const: renesas,sh73a0-cpg-clocks
then:
properties:
clocks:
items:
- description: extal1
- description: extal2
clock-output-names:
items:
- const: main
- const: pll0
- const: pll1
- const: pll2
- const: pll3
- const: dsi0phy
- const: dsi1phy
- const: zg
- const: m3
- const: b
- const: m1
- const: m2
- const: z
- const: zx
- const: hp
- if:
properties:
compatible:
contains:
enum:
- renesas,r8a7778-cpg-clocks
- renesas,r8a7779-cpg-clocks
- renesas,rz-cpg-clocks
then:
required:
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/r8a7740-clock.h>
cpg_clocks: cpg_clocks@e6150000 {
compatible = "renesas,r8a7740-cpg-clocks";
reg = <0xe6150000 0x10000>;
clocks = <&extal1_clk>, <&extal2_clk>, <&extalr_clk>;
#clock-cells = <1>;
clock-output-names = "system", "pllc0", "pllc1", "pllc2", "r",
"usb24s", "i", "zg", "b", "m1", "hp", "hpp",
"usbp", "s", "zb", "m3", "cp";
renesas,mode = <0x05>;
};

1
Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
View File

@@ -33,6 +33,7 @@ properties:
- renesas,r8a774a1-cpg-mssr # RZ/G2M
- renesas,r8a774b1-cpg-mssr # RZ/G2N
- renesas,r8a774c0-cpg-mssr # RZ/G2E
- renesas,r8a774e1-cpg-mssr # RZ/G2H
- renesas,r8a7790-cpg-mssr # R-Car H2
- renesas,r8a7791-cpg-mssr # R-Car M2-W
- renesas,r8a7792-cpg-mssr # R-Car V2H

33
Documentation/devicetree/bindings/clock/renesas,r8a73a4-cpg-clocks.txt
View File

@@ -1,33 +0,0 @@
* Renesas R8A73A4 Clock Pulse Generator (CPG)
The CPG generates core clocks for the R8A73A4 SoC. It includes five PLLs
and several fixed ratio dividers.
Required Properties:
- compatible: Must be "renesas,r8a73a4-cpg-clocks"
- reg: Base address and length of the memory resource used by the CPG
- clocks: Reference to the parent clocks ("extal1" and "extal2")
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "main",
"pll0", "pll1", "pll2", "pll2s", "pll2h", "z", "z2", "i", "m3", "b",
"m1", "m2", "zx", "zs", and "hp".
Example
-------
cpg_clocks: cpg_clocks@e6150000 {
compatible = "renesas,r8a73a4-cpg-clocks";
reg = <0 0xe6150000 0 0x10000>;
clocks = <&extal1_clk>, <&extal2_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0", "pll1", "pll2",
"pll2s", "pll2h", "z", "z2",
"i", "m3", "b", "m1", "m2",
"zx", "zs", "hp";
};

41
Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt
View File

@@ -1,41 +0,0 @@
These bindings should be considered EXPERIMENTAL for now.
* Renesas R8A7740 Clock Pulse Generator (CPG)
The CPG generates core clocks for the R8A7740 SoC. It includes three PLLs
and several fixed ratio and variable ratio dividers.
Required Properties:
- compatible: Must be "renesas,r8a7740-cpg-clocks"
- reg: Base address and length of the memory resource used by the CPG
- clocks: Reference to the three parent clocks
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are
"system", "pllc0", "pllc1", "pllc2", "r", "usb24s", "i", "zg", "b",
"m1", "hp", "hpp", "usbp", "s", "zb", "m3", and "cp".
- renesas,mode: board-specific settings of the MD_CK* bits
Example
-------
cpg_clocks: cpg_clocks@e6150000 {
compatible = "renesas,r8a7740-cpg-clocks";
reg = <0xe6150000 0x10000>;
clocks = <&extal1_clk>, <&extal2_clk>, <&extalr_clk>;
#clock-cells = <1>;
clock-output-names = "system", "pllc0", "pllc1",
"pllc2", "r",
"usb24s",
"i", "zg", "b", "m1", "hp",
"hpp", "usbp", "s", "zb", "m3",
"cp";
};
&cpg_clocks {
renesas,mode = <0x05>;
};

47
Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.txt
View File

@@ -1,47 +0,0 @@
* Renesas R8A7778 Clock Pulse Generator (CPG)
The CPG generates core clocks for the R8A7778. It includes two PLLs and
several fixed ratio dividers.
The CPG also provides a Clock Domain for SoC devices, in combination with the
CPG Module Stop (MSTP) Clocks.
Required Properties:
- compatible: Must be "renesas,r8a7778-cpg-clocks"
- reg: Base address and length of the memory resource used by the CPG
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are
"plla", "pllb", "b", "out", "p", "s", and "s1".
- #power-domain-cells: Must be 0
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
through an MSTP clock should refer to the CPG device node in their
"power-domains" property, as documented by the generic PM domain bindings in
Documentation/devicetree/bindings/power/power_domain.txt.
Examples
--------
- CPG device node:
cpg_clocks: cpg_clocks@ffc80000 {
compatible = "renesas,r8a7778-cpg-clocks";
reg = <0xffc80000 0x80>;
#clock-cells = <1>;
clocks = <&extal_clk>;
clock-output-names = "plla", "pllb", "b",
"out", "p", "s", "s1";
#power-domain-cells = <0>;
};
- CPG/MSTP Clock Domain member device node:
sdhi0: sd@ffe4c000 {
compatible = "renesas,sdhi-r8a7778";
reg = <0xffe4c000 0x100>;
interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7778_CLK_SDHI0>;
power-domains = <&cpg_clocks>;
};

49
Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt
View File

@@ -1,49 +0,0 @@
* Renesas R8A7779 Clock Pulse Generator (CPG)
The CPG generates core clocks for the R8A7779. It includes one PLL and
several fixed ratio dividers.
The CPG also provides a Clock Domain for SoC devices, in combination with the
CPG Module Stop (MSTP) Clocks.
Required Properties:
- compatible: Must be "renesas,r8a7779-cpg-clocks"
- reg: Base address and length of the memory resource used by the CPG
- clocks: Reference to the parent clock
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "plla",
"z", "zs", "s", "s1", "p", "b", "out".
- #power-domain-cells: Must be 0
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
through an MSTP clock should refer to the CPG device node in their
"power-domains" property, as documented by the generic PM domain bindings in
Documentation/devicetree/bindings/power/power_domain.txt.
Examples
--------
- CPG device node:
cpg_clocks: cpg_clocks@ffc80000 {
compatible = "renesas,r8a7779-cpg-clocks";
reg = <0xffc80000 0x30>;
clocks = <&extal_clk>;
#clock-cells = <1>;
clock-output-names = "plla", "z", "zs", "s", "s1", "p",
"b", "out";
#power-domain-cells = <0>;
};
- CPG/MSTP Clock Domain member device node:
sata: sata@fc600000 {
compatible = "renesas,sata-r8a7779", "renesas,rcar-sata";
reg = <0xfc600000 0x2000>;
interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp1_clks R8A7779_CLK_SATA>;
power-domains = <&cpg_clocks>;
};

53
Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt
View File

@@ -1,53 +0,0 @@
* Renesas RZ/A1 Clock Pulse Generator (CPG)
The CPG generates core clocks for the RZ/A1 SoCs. It includes the PLL, variable
CPU and GPU clocks, and several fixed ratio dividers.
The CPG also provides a Clock Domain for SoC devices, in combination with the
CPG Module Stop (MSTP) Clocks.
Required Properties:
- compatible: Must be one of
- "renesas,r7s72100-cpg-clocks" for the r7s72100 CPG
and "renesas,rz-cpg-clocks" as a fallback.
- reg: Base address and length of the memory resource used by the CPG
- clocks: References to possible parent clocks. Order must match clock modes
in the datasheet. For the r7s72100, this is extal, usb_x1.
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "pll",
"i", and "g"
- #power-domain-cells: Must be 0
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
through an MSTP clock should refer to the CPG device node in their
"power-domains" property, as documented by the generic PM domain bindings in
Documentation/devicetree/bindings/power/power_domain.txt.
Examples
--------
- CPG device node:
cpg_clocks: cpg_clocks@fcfe0000 {
#clock-cells = <1>;
compatible = "renesas,r7s72100-cpg-clocks",
"renesas,rz-cpg-clocks";
reg = <0xfcfe0000 0x18>;
clocks = <&extal_clk>, <&usb_x1_clk>;
clock-output-names = "pll", "i", "g";
#power-domain-cells = <0>;
};
- CPG/MSTP Clock Domain member device node:
mtu2: timer@fcff0000 {
compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
reg = <0xfcff0000 0x400>;
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "tgi0a";
clocks = <&mstp3_clks R7S72100_CLK_MTU2>;
clock-names = "fck";
power-domains = <&cpg_clocks>;
};

35
Documentation/devicetree/bindings/clock/renesas,sh73a0-cpg-clocks.txt
View File

@@ -1,35 +0,0 @@
These bindings should be considered EXPERIMENTAL for now.
* Renesas SH73A0 Clock Pulse Generator (CPG)
The CPG generates core clocks for the SH73A0 SoC. It includes four PLLs
and several fixed ratio dividers.
Required Properties:
- compatible: Must be "renesas,sh73a0-cpg-clocks"
- reg: Base address and length of the memory resource used by the CPG
- clocks: Reference to the parent clocks ("extal1" and "extal2")
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "main",
"pll0", "pll1", "pll2", "pll3", "dsi0phy", "dsi1phy", "zg", "m3", "b",
"m1", "m2", "z", "zx", and "hp".
Example
-------
cpg_clocks: cpg_clocks@e6150000 {
compatible = "renesas,sh73a0-cpg-clocks";
reg = <0 0xe6150000 0 0x10000>;
clocks = <&extal1_clk>, <&extal2_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0", "pll1", "pll2",
"pll3", "dsi0phy", "dsi1phy",
"zg", "m3", "b", "m1", "m2",
"z", "zx", "hp";
};

2
Documentation/devicetree/bindings/clock/silabs,si514.txt
View File

@@ -6,7 +6,7 @@ found in the datasheet[2].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Si514 datasheet
http://www.silabs.com/Support%20Documents/TechnicalDocs/si514.pdf
https://www.silabs.com/Support%20Documents/TechnicalDocs/si514.pdf
Required properties:
- compatible: Shall be "silabs,si514"

2
Documentation/devicetree/bindings/clock/silabs,si5351.txt
View File

@@ -2,7 +2,7 @@ Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
Reference
[1] Si5351A/B/C Data Sheet
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
The Si5351a/b/c are programmable i2c clock generators with up to 8 output
clocks. Si5351a also has a reduced pin-count package (MSOP10) where only

4
Documentation/devicetree/bindings/clock/silabs,si570.txt
View File

@@ -7,9 +7,9 @@ found in the data sheets[2][3].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Si570/571 Data Sheet
http://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
https://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
[3] Si598/599 Data Sheet
http://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf
https://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf
Required properties:
- compatible: Shall be one of "silabs,si570", "silabs,si571",

2
Documentation/devicetree/bindings/clock/ti,cdce706.txt
View File

@@ -1,7 +1,7 @@
Bindings for Texas Instruments CDCE706 programmable 3-PLL clock
synthesizer/multiplier/divider.
Reference: http://www.ti.com/lit/ds/symlink/cdce706.pdf
Reference: https://www.ti.com/lit/ds/symlink/cdce706.pdf
I2C device node required properties:
- compatible: shall be "ti,cdce706".

8
Documentation/devicetree/bindings/clock/ti,cdce925.txt
View File

@@ -4,10 +4,10 @@ Reference
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] http://www.ti.com/product/cdce913
[3] http://www.ti.com/product/cdce925
[4] http://www.ti.com/product/cdce937
[5] http://www.ti.com/product/cdce949
[2] https://www.ti.com/product/cdce913
[3] https://www.ti.com/product/cdce925
[4] https://www.ti.com/product/cdce937
[5] https://www.ti.com/product/cdce949
The driver provides clock sources for each output Y1 through Y5.

1
Documentation/devicetree/bindings/dma/arm-pl330.txt
View File

@@ -16,6 +16,7 @@ Optional properties:
- dma-channels: contains the total number of DMA channels supported by the DMAC
- dma-requests: contains the total number of DMA requests supported by the DMAC
- arm,pl330-broken-no-flushp: quirk for avoiding to execute DMAFLUSHP
- arm,pl330-periph-burst: quirk for performing burst transfer only
- resets: contains an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: must contain at least "dma", and optional is "dma-ocp".

47
Documentation/devicetree/bindings/dma/owl-dma.txt
View File

@@ -1,47 +0,0 @@
* Actions Semi Owl SoCs DMA controller
This binding follows the generic DMA bindings defined in dma.txt.
Required properties:
- compatible: Should be "actions,s900-dma".
- reg: Should contain DMA registers location and length.
- interrupts: Should contain 4 interrupts shared by all channel.
- #dma-cells: Must be <1>. Used to represent the number of integer
cells in the dmas property of client device.
- dma-channels: Physical channels supported.
- dma-requests: Number of DMA request signals supported by the controller.
Refer to Documentation/devicetree/bindings/dma/dma.txt
- clocks: Phandle and Specifier of the clock feeding the DMA controller.
Example:
Controller:
dma: dma-controller@e0260000 {
compatible = "actions,s900-dma";
reg = <0x0 0xe0260000 0x0 0x1000>;
interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
#dma-cells = <1>;
dma-channels = <12>;
dma-requests = <46>;
clocks = <&clock CLK_DMAC>;
};
Client:
DMA clients connected to the Actions Semi Owl SoCs DMA controller must
use the format described in the dma.txt file, using a two-cell specifier
for each channel.
The two cells in order are:
1. A phandle pointing to the DMA controller.
2. The channel id.
uart5: serial@e012a000 {
...
dma-names = "tx", "rx";
dmas = <&dma 26>, <&dma 27>;
...
};

79
Documentation/devicetree/bindings/dma/owl-dma.yaml Normal file
View File

@@ -0,0 +1,79 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/owl-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Actions Semi Owl SoCs DMA controller
description: |
The OWL DMA is a general-purpose direct memory access controller capable of
supporting 10 and 12 independent DMA channels for S700 and S900 SoCs
respectively.
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
allOf:
- $ref: "dma-controller.yaml#"
properties:
compatible:
enum:
- actions,s900-dma
- actions,s700-dma
reg:
maxItems: 1
interrupts:
description:
controller supports 4 interrupts, which are freely assignable to the
DMA channels.
maxItems: 4
"#dma-cells":
const: 1
dma-channels:
maximum: 12
dma-requests:
maximum: 46
clocks:
maxItems: 1
description:
Phandle and Specifier of the clock feeding the DMA controller.
power-domains:
maxItems: 1
required:
- compatible
- reg
- interrupts
- "#dma-cells"
- dma-channels
- dma-requests
- clocks
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
dma: dma-controller@e0260000 {
compatible = "actions,s900-dma";
reg = <0xe0260000 0x1000>;
interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
#dma-cells = <1>;
dma-channels = <12>;
dma-requests = <46>;
clocks = <&clock 22>;
};
...

1
Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
View File

@@ -23,6 +23,7 @@ properties:
- renesas,dmac-r8a774a1 # RZ/G2M
- renesas,dmac-r8a774b1 # RZ/G2N
- renesas,dmac-r8a774c0 # RZ/G2E
- renesas,dmac-r8a774e1 # RZ/G2H
- renesas,dmac-r8a7790 # R-Car H2
- renesas,dmac-r8a7791 # R-Car M2-W
- renesas,dmac-r8a7792 # R-Car V2H

2
Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
View File

@@ -16,6 +16,7 @@ properties:
compatible:
items:
- enum:
- renesas,r8a7742-usb-dmac # RZ/G1H
- renesas,r8a7743-usb-dmac # RZ/G1M
- renesas,r8a7744-usb-dmac # RZ/G1N
- renesas,r8a7745-usb-dmac # RZ/G1E
@@ -23,6 +24,7 @@ properties:
- renesas,r8a774a1-usb-dmac # RZ/G2M
- renesas,r8a774b1-usb-dmac # RZ/G2N
- renesas,r8a774c0-usb-dmac # RZ/G2E
- renesas,r8a774e1-usb-dmac # RZ/G2H
- renesas,r8a7790-usb-dmac # R-Car H2
- renesas,r8a7791-usb-dmac # R-Car M2-W
- renesas,r8a7793-usb-dmac # R-Car M2-N

176
Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml Normal file
View File

@@ -0,0 +1,176 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/snps,dma-spear1340.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Synopsys Designware DMA Controller
maintainers:
- Viresh Kumar <vireshk@kernel.org>
- Andy Shevchenko <andriy.shevchenko@linux.intel.com>
allOf:
- $ref: "dma-controller.yaml#"
properties:
compatible:
const: snps,dma-spear1340
"#dma-cells":
const: 3
description: |
First cell is a phandle pointing to the DMA controller. Second one is
the DMA request line number. Third cell is the memory master identifier
for transfers on dynamically allocated channel. Fourth cell is the
peripheral master identifier for transfers on an allocated channel.
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
clock-names:
description: AHB interface reference clock.
const: hclk
dma-channels:
description: |
Number of DMA channels supported by the controller. In case if
not specified the driver will try to auto-detect this and
the rest of the optional parameters.
minimum: 1
maximum: 8
dma-requests:
minimum: 1
maximum: 16
dma-masters:
$ref: /schemas/types.yaml#definitions/uint32
description: |
Number of DMA masters supported by the controller. In case if
not specified the driver will try to auto-detect this and
the rest of the optional parameters.
minimum: 1
maximum: 4
chan_allocation_order:
$ref: /schemas/types.yaml#definitions/uint32
description: |
DMA channels allocation order specifier. Zero means ascending order
(first free allocated), while one - descending (last free allocated).
default: 0
enum: [0, 1]
chan_priority:
$ref: /schemas/types.yaml#definitions/uint32
description: |
DMA channels priority order. Zero means ascending channels priority
so the very first channel has the highest priority. While 1 means
descending priority (the last channel has the highest priority).
default: 0
enum: [0, 1]
block_size:
$ref: /schemas/types.yaml#definitions/uint32
description: Maximum block size supported by the DMA controller.
enum: [3, 7, 15, 31, 63, 127, 255, 511, 1023, 2047, 4095]
data-width:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: Data bus width per each DMA master in bytes.
items:
maxItems: 4
items:
enum: [4, 8, 16, 32]
data_width:
$ref: /schemas/types.yaml#/definitions/uint32-array
deprecated: true
description: |
Data bus width per each DMA master in (2^n * 8) bits. This property is
deprecated. It' usage is discouraged in favor of data-width one. Moreover
the property incorrectly permits to define data-bus width of 8 and 16
bits, which is impossible in accordance with DW DMAC IP-core data book.
items:
maxItems: 4
items:
enum:
- 0 # 8 bits
- 1 # 16 bits
- 2 # 32 bits
- 3 # 64 bits
- 4 # 128 bits
- 5 # 256 bits
default: 0
multi-block:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
LLP-based multi-block transfer supported by hardware per
each DMA channel.
items:
maxItems: 8
items:
enum: [0, 1]
default: 1
snps,max-burst-len:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Maximum length of the burst transactions supported by the controller.
This property defines the upper limit of the run-time burst setting
(CTLx.SRC_MSIZE/CTLx.DST_MSIZE fields) so the allowed burst length
will be from 1 to max-burst-len words. It's an array property with one
cell per channel in the units determined by the value set in the
CTLx.SRC_TR_WIDTH/CTLx.DST_TR_WIDTH fields (data width).
items:
maxItems: 8
items:
enum: [4, 8, 16, 32, 64, 128, 256]
default: 256
snps,dma-protection-control:
$ref: /schemas/types.yaml#definitions/uint32
description: |
Bits one-to-one passed to the AHB HPROT[3:1] bus. Each bit setting
indicates the following features: bit 0 - privileged mode,
bit 1 - DMA is bufferable, bit 2 - DMA is cacheable.
default: 0
minimum: 0
maximum: 7
unevaluatedProperties: false
required:
- compatible
- "#dma-cells"
- reg
- interrupts
examples:
- |
dma-controller@fc000000 {
compatible = "snps,dma-spear1340";
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
dma-channels = <8>;
dma-requests = <16>;
dma-masters = <4>;
#dma-cells = <3>;
chan_allocation_order = <1>;
chan_priority = <1>;
block_size = <0xfff>;
data-width = <8 8>;
multi-block = <0 0 0 0 0 0 0 0>;
snps,max-burst-len = <16 16 4 4 4 4 4 4>;
};
...

69
Documentation/devicetree/bindings/dma/snps-dma.txt
View File

@@ -1,69 +0,0 @@
* Synopsys Designware DMA Controller
Required properties:
- compatible: "snps,dma-spear1340"
- reg: Address range of the DMAC registers
- interrupt: Should contain the DMAC interrupt number
- dma-channels: Number of channels supported by hardware
- dma-requests: Number of DMA request lines supported, up to 16
- dma-masters: Number of AHB masters supported by the controller
- #dma-cells: must be <3>
- chan_allocation_order: order of allocation of channel, 0 (default): ascending,
1: descending
- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
increase from chan n->0
- block_size: Maximum block size supported by the controller
- data-width: Maximum data width supported by hardware per AHB master
(in bytes, power of 2)
Deprecated properties:
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
Optional properties:
- multi-block: Multi block transfers supported by hardware. Array property with
one cell per channel. 0: not supported, 1 (default): supported.
- snps,dma-protection-control: AHB HPROT[3:1] protection setting.
The default value is 0 (for non-cacheable, non-buffered,
unprivileged data access).
Refer to include/dt-bindings/dma/dw-dmac.h for possible values.
Example:
dmahost: dma@fc000000 {
compatible = "snps,dma-spear1340";
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
dma-channels = <8>;
dma-requests = <16>;
dma-masters = <2>;
#dma-cells = <3>;
chan_allocation_order = <1>;
chan_priority = <1>;
block_size = <0xfff>;
data-width = <8 8>;
};
DMA clients connected to the Designware DMA controller must use the format
described in the dma.txt file, using a four-cell specifier for each channel.
The four cells in order are:
1. A phandle pointing to the DMA controller
2. The DMA request line number
3. Memory master for transfers on allocated channel
4. Peripheral master for transfers on allocated channel
Example:
serial@e0000000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xe0000000 0x1000>;
interrupts = <0 35 0x4>;
dmas = <&dmahost 12 0 1>,
<&dmahost 13 1 0>;
dma-names = "rx", "rx";
};

8
Documentation/devicetree/bindings/mailbox/mtk-gce.txt
View File

@@ -9,7 +9,8 @@ CMDQ driver uses mailbox framework for communication. Please refer to
mailbox.txt for generic information about mailbox device-tree bindings.
Required properties:
- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce"
- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce" or
"mediatek,mt6779-gce".
- reg: Address range of the GCE unit
- interrupts: The interrupt signal from the GCE block
- clock: Clocks according to the common clock binding
@@ -34,8 +35,9 @@ Optional properties for a client device:
start_offset: the start offset of register address that GCE can access.
size: the total size of register address that GCE can access.
Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'
or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids.
Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h',
'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as
sub-system ids, thread priority, event ids.
Example:

2
Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
View File

@@ -18,10 +18,12 @@ properties:
enum:
- qcom,ipq8074-apcs-apps-global
- qcom,msm8916-apcs-kpss-global
- qcom,msm8994-apcs-kpss-global
- qcom,msm8996-apcs-hmss-global
- qcom,msm8998-apcs-hmss-global
- qcom,qcs404-apcs-apps-global
- qcom,sc7180-apss-shared
- qcom,sdm660-apcs-hmss-global
- qcom,sdm845-apss-shared
- qcom,sm8150-apss-shared

67
Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml Normal file
View File

@@ -0,0 +1,67 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Chrontel HDMI-CEC Controller
maintainers:
- Jeff Chase <jnchase@google.com>
description:
The Chrontel CH7322 is a discrete HDMI-CEC controller. It is
programmable through I2C and drives a single CEC line.
properties:
compatible:
const: chrontel,ch7322
reg:
description: I2C device address
maxItems: 1
clocks:
maxItems: 1
interrupts:
maxItems: 1
reset-gpios:
description:
Reference to the GPIO connected to the RESET pin, if any. This
pin is active-low.
maxItems: 1
standby-gpios:
description:
Reference to the GPIO connected to the OE pin, if any. When low
the device will respond to power status requests with "standby"
if in auto mode.
maxItems: 1
# see ../cec.txt
hdmi-phandle:
description: phandle to the HDMI controller
required:
- compatible
- reg
- interrupts
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
ch7322@75 {
compatible = "chrontel,ch7322";
reg = <0x75>;
interrupts = <47 IRQ_TYPE_EDGE_RISING>;
standby-gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
reset-gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
hdmi-phandle = <&hdmi>;
};
};

100
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml Normal file
View File

@@ -0,0 +1,100 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright (c) 2020 MediaTek Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9768.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Dongwoon Anatech DW9768 Voice Coil Motor (VCM) Lens Device Tree Bindings
maintainers:
- Dongchun Zhu <dongchun.zhu@mediatek.com>
description: |-
The Dongwoon DW9768 is a single 10-bit digital-to-analog (DAC) converter
with 100 mA output current sink capability. VCM current is controlled with
a linear mode driver. The DAC is controlled via a 2-wire (I2C-compatible)
serial interface that operates at clock rates up to 1MHz. This chip
integrates Advanced Actuator Control (AAC) technology and is intended for
driving voice coil lenses in camera modules.
properties:
compatible:
enum:
- dongwoon,dw9768 # for DW9768 VCM
- giantec,gt9769 # for GT9769 VCM
reg:
maxItems: 1
vin-supply:
description:
Definition of the regulator used as Digital I/O voltage supply.
vdd-supply:
description:
Definition of the regulator used as Digital core voltage supply.
dongwoon,aac-mode:
description:
Indication of AAC mode select.
allOf:
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum:
- 1 # AAC2 mode(operation time# 0.48 x Tvib)
- 2 # AAC3 mode(operation time# 0.70 x Tvib)
- 3 # AAC4 mode(operation time# 0.75 x Tvib)
- 5 # AAC8 mode(operation time# 1.13 x Tvib)
default: 2
dongwoon,aac-timing:
description:
Number of AAC Timing count that controlled by one 6-bit period of
vibration register AACT[5:0], the unit of which is 100 us.
allOf:
- $ref: "/schemas/types.yaml#/definitions/uint32"
- default: 0x20
minimum: 0x00
maximum: 0x3f
dongwoon,clock-presc:
description:
Indication of VCM internal clock dividing rate select, as one multiple
factor to calculate VCM ring periodic time Tvib.
allOf:
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum:
- 0 # Dividing Rate - 2
- 1 # Dividing Rate - 1
- 2 # Dividing Rate - 1/2
- 3 # Dividing Rate - 1/4
- 4 # Dividing Rate - 8
- 5 # Dividing Rate - 4
default: 1
required:
- compatible
- reg
- vin-supply
- vdd-supply
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
dw9768: camera-lens@c {
compatible = "dongwoon,dw9768";
reg = <0x0c>;
vin-supply = <&mt6358_vcamio_reg>;
vdd-supply = <&mt6358_vcama2_reg>;
dongwoon,aac-timing = <0x39>;
};
};
...

159
Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml Normal file
View File

@@ -0,0 +1,159 @@
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
# Copyright (C) 2019 Renesas Electronics Corp.
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/imi,rdacm2x-gmsl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: IMI D&D RDACM20 and RDACM21 Automotive Camera Platforms
maintainers:
- Jacopo Mondi <jacopo+renesas@jmondi.org>
- Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
- Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
description: -|
The IMI D&D RDACM20 and RDACM21 are GMSL-compatible camera designed for
automotive applications.
The RDACM20 camera module encloses a Maxim Integrated MAX9271 GMSL serializer,
coupled with an OV10635 image sensor and an embedded MCU. Both the MCU and
the image sensor are connected to the serializer local I2C bus and are
accessible by the host SoC by direct addressing.
The RDACM21 camera module encloses the same serializer, coupled with an
OV10640 image sensor and an OV490 ISP. Only the OV490 ISP is interfaced to
the serializer local I2C bus while the image sensor is not accessible from
the host SoC.
They both connect to a remote GMSL endpoint through a coaxial cable.
IMI RDACM20
+---------------+ +--------------------------------+
| GMSL | <- Video Stream | <- Video--------\ |
| |< === GMSL Link ====== >|MAX9271<- I2C bus-> <-->OV10635 |
| de-serializer | <- I2C messages -> | \<-->MCU |
+---------------+ +--------------------------------+
IMI RDACM21
+---------------+ +--------------------------------+
| GMSL | <- Video Stream | <- Video--------\ |
| |< === GMSL Link ====== >|MAX9271<- I2C bus-> <-->OV490 |
| | <- I2C messages -> | | |
| de-serializer | | OV10640 <-------| |
+---------------+ +--------------------------------+
Both camera modules serialize video data generated by the embedded camera
sensor on the GMSL serial channel to a remote GMSL de-serializer. They also
receive and transmit I2C messages encapsulated and transmitted on the GMSL
bidirectional control channel.
All I2C traffic received on the GMSL link not directed to the serializer is
propagated on the local I2C bus to the remote device there connected. All the
I2C traffic generated on the local I2C bus not directed to the serializer is
propagated to the remote de-serializer encapsulated in the GMSL control
channel.
The RDACM20 and RDACM21 DT node should be a direct child of the GMSL
deserializer's I2C bus corresponding to the GMSL link that the camera is
attached to.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
compatible:
enum:
- imi,rdacm20
- imi,rdacm21
reg:
description: -|
I2C device addresses, the first to be assigned to the serializer, the
following ones to be assigned to the remote devices.
For RDACM20 the second entry of the property is assigned to the
OV10635 image sensor and the optional third one to the embedded MCU.
For RDACM21 the second entry is assigned to the OV490 ISP and the optional
third one ignored.
minItems: 2
maxItems: 3
port:
type: object
additionalProperties: false
description: -|
Connection to the remote GMSL endpoint are modelled using the OF graph
bindings in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
The device node contains a single "port" child node with a single
"endpoint" sub-device.
properties:
endpoint:
type: object
additionalProperties: false
properties:
remote-endpoint:
description: -|
phandle to the remote GMSL endpoint sub-node in the remote node
port.
maxItems: 1
required:
- remote-endpoint
required:
- endpoint
required:
- compatible
- reg
- port
examples:
- |
i2c@e66d8000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0 0xe66d8000>;
camera@31 {
compatible = "imi,rdacm20";
reg = <0x31>, <0x41>, <0x51>;
port {
rdacm20_out0: endpoint {
remote-endpoint = <&max9286_in0>;
};
};
};
};
- |
i2c@e66d8000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0 0xe66d8000>;
camera@31 {
compatible = "imi,rdacm21";
reg = <0x31>, <0x41>;
port {
rdacm21_out0: endpoint {
remote-endpoint = <&max9286_in0>;
};
};
};
};

366
Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml Normal file
View File

@@ -0,0 +1,366 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2019 Renesas Electronics Corp.
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/maxim,max9286.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim Integrated Quad GMSL Deserializer
maintainers:
- Jacopo Mondi <jacopo+renesas@jmondi.org>
- Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
- Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
description: |
The MAX9286 deserializer receives video data on up to 4 Gigabit Multimedia
Serial Links (GMSL) and outputs them on a CSI-2 D-PHY port using up to 4 data
lanes.
In addition to video data, the GMSL links carry a bidirectional control
channel that encapsulates I2C messages. The MAX9286 forwards all I2C traffic
not addressed to itself to the other side of the links, where a GMSL
serializer will output it on a local I2C bus. In the other direction all I2C
traffic received over GMSL by the MAX9286 is output on the local I2C bus.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
compatible:
const: maxim,max9286
reg:
description: I2C device address
maxItems: 1
poc-supply:
description: Regulator providing Power over Coax to the cameras
maxItems: 1
enable-gpios:
description: GPIO connected to the \#PWDN pin with inverted polarity
maxItems: 1
gpio-controller: true
'#gpio-cells':
const: 2
ports:
type: object
description: |
The connections to the MAX9286 GMSL and its endpoint nodes are modelled
using the OF graph bindings in accordance with the video interface
bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
The following table lists the port number corresponding to each device
port.
Port Description
----------------------------------------
Port 0 GMSL Input 0
Port 1 GMSL Input 1
Port 2 GMSL Input 2
Port 3 GMSL Input 3
Port 4 CSI-2 Output
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
port@[0-3]:
type: object
properties:
reg:
enum: [ 0, 1, 2, 3 ]
endpoint:
type: object
properties:
remote-endpoint:
description: |
phandle to the remote GMSL source endpoint subnode in the
remote node port.
required:
- remote-endpoint
required:
- reg
- endpoint
additionalProperties: false
port@4:
type: object
properties:
reg:
const: 4
endpoint:
type: object
properties:
remote-endpoint:
description: phandle to the remote CSI-2 sink endpoint.
data-lanes:
description: array of physical CSI-2 data lane indexes.
required:
- remote-endpoint
- data-lanes
required:
- reg
- endpoint
additionalProperties: false
required:
- port@4
i2c-mux:
type: object
description: |
Each GMSL link is modelled as a child bus of an i2c bus
multiplexer/switch, in accordance with bindings described in
Documentation/devicetree/bindings/i2c/i2c-mux.txt.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
"^i2c@[0-3]$":
type: object
description: |
Child node of the i2c bus multiplexer which represents a GMSL link.
Each serializer device on the GMSL link remote end is represented with
an i2c-mux child node. The MAX9286 chip supports up to 4 GMSL
channels.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
reg:
description: The index of the GMSL channel.
maxItems: 1
patternProperties:
"^camera@[a-f0-9]+$":
type: object
description: |
The remote camera device, composed by a GMSL serializer and a
connected video source.
properties:
compatible:
description: The remote device compatible string.
reg:
minItems: 2
maxItems: 3
description: |
The I2C addresses to be assigned to the remote devices through
address reprogramming. The number of entries depends on the
requirements of the currently connected remote device.
port:
type: object
properties:
endpoint:
type: object
properties:
remote-endpoint:
description: phandle to the MAX9286 sink endpoint.
required:
- remote-endpoint
additionalProperties: false
required:
- endpoint
additionalProperties: false
required:
- compatible
- reg
- port
additionalProperties: false
additionalProperties: false
additionalProperties: false
required:
- compatible
- reg
- ports
- i2c-mux
- gpio-controller
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c@e66d8000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0 0xe66d8000>;
gmsl-deserializer@2c {
compatible = "maxim,max9286";
reg = <0x2c>;
poc-supply = <&camera_poc_12v>;
enable-gpios = <&gpio 13 GPIO_ACTIVE_HIGH>;
gpio-controller;
#gpio-cells = <2>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
max9286_in0: endpoint {
remote-endpoint = <&rdacm20_out0>;
};
};
port@1 {
reg = <1>;
max9286_in1: endpoint {
remote-endpoint = <&rdacm20_out1>;
};
};
port@2 {
reg = <2>;
max9286_in2: endpoint {
remote-endpoint = <&rdacm20_out2>;
};
};
port@3 {
reg = <3>;
max9286_in3: endpoint {
remote-endpoint = <&rdacm20_out3>;
};
};
port@4 {
reg = <4>;
max9286_out: endpoint {
data-lanes = <1 2 3 4>;
remote-endpoint = <&csi40_in>;
};
};
};
i2c-mux {
#address-cells = <1>;
#size-cells = <0>;
i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
camera@51 {
compatible = "imi,rdacm20";
reg = <0x51>, <0x61>;
port {
rdacm20_out0: endpoint {
remote-endpoint = <&max9286_in0>;
};
};
};
};
i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
camera@52 {
compatible = "imi,rdacm20";
reg = <0x52>, <0x62>;
port {
rdacm20_out1: endpoint {
remote-endpoint = <&max9286_in1>;
};
};
};
};
i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
camera@53 {
compatible = "imi,rdacm20";
reg = <0x53>, <0x63>;
port {
rdacm20_out2: endpoint {
remote-endpoint = <&max9286_in2>;
};
};
};
};
i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
camera@54 {
compatible = "imi,rdacm20";
reg = <0x54>, <0x64>;
port {
rdacm20_out3: endpoint {
remote-endpoint = <&max9286_in3>;
};
};
};
};
};
};
};

34
Documentation/devicetree/bindings/media/renesas,fcp.txt
View File

@@ -1,34 +0,0 @@
Renesas R-Car Frame Compression Processor (FCP)
-----------------------------------------------
The FCP is a companion module of video processing modules in the Renesas R-Car
Gen3 and RZ/G2 SoCs. It provides data compression and decompression, data
caching, and conversion of AXI transactions in order to reduce the memory
bandwidth.
There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and FCP
for FDP (FCPF). Their configuration and behaviour depend on the module they
are paired with. These DT bindings currently support the FCPV and FCPF.
- compatible: Must be one or more of the following
- "renesas,fcpv" for generic compatible 'FCP for VSP'
- "renesas,fcpf" for generic compatible 'FCP for FDP'
- reg: the register base and size for the device registers
- clocks: Reference to the functional clock
Optional properties:
- power-domains : power-domain property defined with a power domain specifier
to respective power domain.
Device node example
-------------------
fcpvd1: fcp@fea2f000 {
compatible = "renesas,fcpv";
reg = <0 0xfea2f000 0 0x200>;
clocks = <&cpg CPG_MOD 602>;
power-domains = <&sysc R8A7795_PD_A3VP>;
};

66
Documentation/devicetree/bindings/media/renesas,fcp.yaml Normal file
View File

@@ -0,0 +1,66 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/renesas,fcp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car Frame Compression Processor (FCP)
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description: |
The FCP is a companion module of video processing modules in the Renesas
R-Car Gen3 and RZ/G2 SoCs. It provides data compression and decompression,
data caching, and conversion of AXI transactions in order to reduce the
memory bandwidth.
There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and
FCP for FDP (FCPF). Their configuration and behaviour depend on the module
they are paired with. These DT bindings currently support the FCPV and FCPF.
properties:
compatible:
enum:
- renesas,fcpv # FCP for VSP
- renesas,fcpf # FCP for FDP
reg:
maxItems: 1
clocks:
maxItems: 1
iommus:
maxItems: 1
power-domains:
maxItems: 1
resets:
maxItems: 1
required:
- compatible
- reg
- clocks
- power-domains
- resets
additionalProperties: false
examples:
# R8A7795 (R-Car H3) FCP for VSP-D1
- |
#include <dt-bindings/clock/renesas-cpg-mssr.h>
#include <dt-bindings/power/r8a7795-sysc.h>
fcp@fea2f000 {
compatible = "renesas,fcpv";
reg = <0xfea2f000 0x200>;
clocks = <&cpg CPG_MOD 602>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 602>;
iommus = <&ipmmu_vi0 9>;
};
...

37
Documentation/devicetree/bindings/media/renesas,fdp1.txt
View File

@@ -1,37 +0,0 @@
Renesas R-Car Fine Display Processor (FDP1)
-------------------------------------------
The FDP1 is a de-interlacing module which converts interlaced video to
progressive video. It is capable of performing pixel format conversion between
YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are supported as
an input to the module.
Required properties:
- compatible: must be "renesas,fdp1"
- reg: the register base and size for the device registers
- interrupts : interrupt specifier for the FDP1 instance
- clocks: reference to the functional clock
Optional properties:
- power-domains: reference to the power domain that the FDP1 belongs to, if
any.
- renesas,fcp: a phandle referencing the FCP that handles memory accesses
for the FDP1. Not needed on Gen2, mandatory on Gen3.
Please refer to the binding documentation for the clock and/or power domain
providers for more details.
Device node example
-------------------
fdp1@fe940000 {
compatible = "renesas,fdp1";
reg = <0 0xfe940000 0 0x2400>;
interrupts = <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 119>;
power-domains = <&sysc R8A7795_PD_A3VP>;
renesas,fcp = <&fcpf0>;
};

69
Documentation/devicetree/bindings/media/renesas,fdp1.yaml Normal file
View File

@@ -0,0 +1,69 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/renesas,fdp1.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car Fine Display Processor (FDP1)
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description:
The FDP1 is a de-interlacing module which converts interlaced video to
progressive video. It is capable of performing pixel format conversion
between YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are
supported as an input to the module.
properties:
compatible:
enum:
- renesas,fdp1
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
power-domains:
maxItems: 1
resets:
maxItems: 1
renesas,fcp:
$ref: /schemas/types.yaml#/definitions/phandle
description:
A phandle referencing the FCP that handles memory accesses for the FDP1.
Not allowed on R-Car Gen2, mandatory on R-Car Gen3.
required:
- compatible
- reg
- interrupts
- clocks
- power-domains
- resets
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/renesas-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7795-sysc.h>
fdp1@fe940000 {
compatible = "renesas,fdp1";
reg = <0xfe940000 0x2400>;
interrupts = <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 119>;
power-domains = <&sysc R8A7795_PD_A3VP>;
resets = <&cpg 119>;
renesas,fcp = <&fcpf0>;
};
...

30
Documentation/devicetree/bindings/media/renesas,vsp1.txt
View File

@@ -1,30 +0,0 @@
* Renesas VSP Video Processing Engine
The VSP is a video processing engine that supports up-/down-scaling, alpha
blending, color space conversion and various other image processing features.
It can be found in the Renesas R-Car Gen2, R-Car Gen3, RZ/G1, and RZ/G2 SoCs.
Required properties:
- compatible: Must contain one of the following values
- "renesas,vsp1" for the R-Car Gen2 and RZ/G1 VSP1
- "renesas,vsp2" for the R-Car Gen3 and RZ/G2 VSP2
- reg: Base address and length of the registers block for the VSP.
- interrupts: VSP interrupt specifier.
- clocks: A phandle + clock-specifier pair for the VSP functional clock.
Optional properties:
- renesas,fcp: A phandle referencing the FCP that handles memory accesses
for the VSP. Not needed on Gen2, mandatory on Gen3.
Example: R8A7790 (R-Car H2) VSP1-S node
vsp@fe928000 {
compatible = "renesas,vsp1";
reg = <0 0xfe928000 0 0x8000>;
interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp1_clks R8A7790_CLK_VSP1_S>;
};

97
Documentation/devicetree/bindings/media/renesas,vsp1.yaml Normal file
View File

@@ -0,0 +1,97 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/renesas,vsp1.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas VSP Video Processing Engine
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description:
The VSP is a video processing engine that supports up-/down-scaling, alpha
blending, color space conversion and various other image processing features.
It can be found in the Renesas R-Car Gen2, R-Car Gen3, RZ/G1, and RZ/G2 SoCs.
properties:
compatible:
enum:
- renesas,vsp1 # R-Car Gen2 and RZ/G1
- renesas,vsp2 # R-Car Gen3 and RZ/G2
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
power-domains:
maxItems: 1
resets:
maxItems: 1
renesas,fcp:
$ref: /schemas/types.yaml#/definitions/phandle
description:
A phandle referencing the FCP that handles memory accesses for the VSP.
required:
- compatible
- reg
- interrupts
- clocks
- power-domains
- resets
additionalProperties: false
if:
properties:
compatible:
items:
- const: renesas,vsp1
then:
properties:
renesas,fcp: false
else:
required:
- renesas,fcp
examples:
# R8A7790 (R-Car H2) VSP1-S
- |
#include <dt-bindings/clock/renesas-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7790-sysc.h>
vsp@fe928000 {
compatible = "renesas,vsp1";
reg = <0xfe928000 0x8000>;
interrupts = <GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 131>;
power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
resets = <&cpg 131>;
};
# R8A77951 (R-Car H3) VSP2-BC
- |
#include <dt-bindings/clock/renesas-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7795-sysc.h>
vsp@fe920000 {
compatible = "renesas,vsp2";
reg = <0xfe920000 0x8000>;
interrupts = <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 624>;
power-domains = <&sysc R8A7795_PD_A3VP>;
resets = <&cpg 624>;
renesas,fcp = <&fcpvb1>;
};
...

237
Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml Normal file
View File

@@ -0,0 +1,237 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/xilinx/xlnx,csi2rxss.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx MIPI CSI-2 Receiver Subsystem
maintainers:
- Vishal Sagar <vishal.sagar@xilinx.com>
description: |
The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture MIPI CSI-2
traffic from compliant camera sensors and send the output as AXI4 Stream
video data for image processing.
The subsystem consists of a MIPI D-PHY in slave mode which captures the
data packets. This is passed along the MIPI CSI-2 Rx IP which extracts the
packet data. The optional Video Format Bridge (VFB) converts this data to
AXI4 Stream video data.
For more details, please refer to PG232 Xilinx MIPI CSI-2 Receiver Subsystem.
Please note that this bindings includes only the MIPI CSI-2 Rx controller
and Video Format Bridge and not D-PHY.
properties:
compatible:
items:
- enum:
- xlnx,mipi-csi2-rx-subsystem-5.0
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
description: List of clock specifiers
items:
- description: AXI Lite clock
- description: Video clock
clock-names:
items:
- const: lite_aclk
- const: video_aclk
xlnx,csi-pxl-format:
description: |
This denotes the CSI Data type selected in hw design.
Packets other than this data type (except for RAW8 and
User defined data types) will be filtered out.
Possible values are as below -
0x1e - YUV4228B
0x1f - YUV42210B
0x20 - RGB444
0x21 - RGB555
0x22 - RGB565
0x23 - RGB666
0x24 - RGB888
0x28 - RAW6
0x29 - RAW7
0x2a - RAW8
0x2b - RAW10
0x2c - RAW12
0x2d - RAW14
0x2e - RAW16
0x2f - RAW20
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- anyOf:
- minimum: 0x1e
- maximum: 0x24
- minimum: 0x28
- maximum: 0x2f
xlnx,vfb:
type: boolean
description: Present when Video Format Bridge is enabled in IP configuration
xlnx,en-csi-v2-0:
type: boolean
description: Present if CSI v2 is enabled in IP configuration.
xlnx,en-vcx:
type: boolean
description: |
When present, there are maximum 16 virtual channels, else only 4.
xlnx,en-active-lanes:
type: boolean
description: |
Present if the number of active lanes can be re-configured at
runtime in the Protocol Configuration Register. Otherwise all lanes,
as set in IP configuration, are always active.
video-reset-gpios:
description: Optional specifier for a GPIO that asserts video_aresetn.
maxItems: 1
ports:
type: object
properties:
port@0:
type: object
description: |
Input / sink port node, single endpoint describing the
CSI-2 transmitter.
properties:
reg:
const: 0
endpoint:
type: object
properties:
data-lanes:
description: |
This is required only in the sink port 0 endpoint which
connects to MIPI CSI-2 source like sensor.
The possible values are -
1 - For 1 lane enabled in IP.
1 2 - For 2 lanes enabled in IP.
1 2 3 - For 3 lanes enabled in IP.
1 2 3 4 - For 4 lanes enabled in IP.
items:
- const: 1
- const: 2
- const: 3
- const: 4
remote-endpoint: true
required:
- data-lanes
- remote-endpoint
additionalProperties: false
additionalProperties: false
port@1:
type: object
description: |
Output / source port node, endpoint describing modules
connected the CSI-2 receiver.
properties:
reg:
const: 1
endpoint:
type: object
properties:
remote-endpoint: true
required:
- remote-endpoint
additionalProperties: false
additionalProperties: false
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- ports
allOf:
- if:
required:
- xlnx,vfb
then:
required:
- xlnx,csi-pxl-format
else:
properties:
xlnx,csi-pxl-format: false
- if:
not:
required:
- xlnx,en-csi-v2-0
then:
properties:
xlnx,en-vcx: false
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
xcsi2rxss_1: csi2rx@a0020000 {
compatible = "xlnx,mipi-csi2-rx-subsystem-5.0";
reg = <0xa0020000 0x10000>;
interrupt-parent = <&gic>;
interrupts = <0 95 4>;
xlnx,csi-pxl-format = <0x2a>;
xlnx,vfb;
xlnx,en-active-lanes;
xlnx,en-csi-v2-0;
xlnx,en-vcx;
clock-names = "lite_aclk", "video_aclk";
clocks = <&misc_clk_0>, <&misc_clk_1>;
video-reset-gpios = <&gpio 86 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
/* Sink port */
reg = <0>;
csiss_in: endpoint {
data-lanes = <1 2 3 4>;
/* MIPI CSI-2 Camera handle */
remote-endpoint = <&camera_out>;
};
};
port@1 {
/* Source port */
reg = <1>;
csiss_out: endpoint {
remote-endpoint = <&vproc_in>;
};
};
};
};
...

8
Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml
View File

@@ -18,13 +18,12 @@ properties:
const: cdns,cdns-pcie-host
reg:
maxItems: 3
maxItems: 2
reg-names:
items:
- const: reg
- const: cfg
- const: mem
msi-parent: true
@@ -49,9 +48,8 @@ examples:
device-id = <0x0200>;
reg = <0x0 0xfb000000 0x0 0x01000000>,
<0x0 0x41000000 0x0 0x00001000>,
<0x0 0x40000000 0x0 0x04000000>;
reg-names = "reg", "cfg", "mem";
<0x0 0x41000000 0x0 0x00001000>;
reg-names = "reg", "cfg";
ranges = <0x02000000 0x0 0x42000000 0x0 0x42000000 0x0 0x1000000>,
<0x01000000 0x0 0x43000000 0x0 0x43000000 0x0 0x0010000>;

12
Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
View File

@@ -112,28 +112,16 @@ Power supplies for Tegra124:
- Required:
- avddio-pex-supply: Power supply for analog PCIe logic. Must supply 1.05 V.
- dvddio-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
- avdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must
supply 1.05 V.
- hvdd-pex-supply: High-voltage supply for PCIe I/O and PCIe output clocks.
Must supply 3.3 V.
- hvdd-pex-pll-e-supply: High-voltage supply for PLLE (shared with USB3).
Must supply 3.3 V.
- vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must
supply 2.8-3.3 V.
- avdd-pll-erefe-supply: Power supply for PLLE (shared with USB3). Must
supply 1.05 V.
Power supplies for Tegra210:
- Required:
- avdd-pll-uerefe-supply: Power supply for PLLE (shared with USB3). Must
supply 1.05 V.
- hvddio-pex-supply: High-voltage supply for PCIe I/O and PCIe output
clocks. Must supply 1.8 V.
- dvddio-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
- dvdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must
supply 1.05 V.
- hvdd-pex-pll-e-supply: High-voltage supply for PLLE (shared with USB3).
Must supply 3.3 V.
- vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must
supply 1.8 V.

4
Documentation/devicetree/bindings/pci/pci.txt
View File

@@ -1,12 +1,12 @@
PCI bus bridges have standardized Device Tree bindings:
PCI Bus Binding to: IEEE Std 1275-1994
http://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf
https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf
And for the interrupt mapping part:
Open Firmware Recommended Practice: Interrupt Mapping
http://www.devicetree.org/open-firmware/practice/imap/imap0_9d.pdf
https://www.devicetree.org/open-firmware/practice/imap/imap0_9d.pdf
Additionally to the properties specified in the above standards a host bridge
driver implementation may support the following properties:

15
Documentation/devicetree/bindings/pci/qcom,pcie.txt
View File

@@ -5,6 +5,7 @@
Value type: <stringlist>
Definition: Value should contain
- "qcom,pcie-ipq8064" for ipq8064
- "qcom,pcie-ipq8064-v2" for ipq8064 rev 2 or ipq8065
- "qcom,pcie-apq8064" for apq8064
- "qcom,pcie-apq8084" for apq8084
- "qcom,pcie-msm8996" for msm8996 or apq8096
@@ -90,6 +91,8 @@
Definition: Should contain the following entries
- "core" Clocks the pcie hw block
- "phy" Clocks the pcie PHY block
- "aux" Clocks the pcie AUX block
- "ref" Clocks the pcie ref block
- clock-names:
Usage: required for apq8084/ipq4019
Value type: <stringlist>
@@ -177,6 +180,7 @@
- "pwr" PWR reset
- "ahb" AHB reset
- "phy_ahb" PHY AHB reset
- "ext" EXT reset
- reset-names:
Usage: required for ipq8074
@@ -277,14 +281,17 @@
<0 0 0 4 &intc 0 39 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
clocks = <&gcc PCIE_A_CLK>,
<&gcc PCIE_H_CLK>,
<&gcc PCIE_PHY_CLK>;
clock-names = "core", "iface", "phy";
<&gcc PCIE_PHY_CLK>,
<&gcc PCIE_AUX_CLK>,
<&gcc PCIE_ALT_REF_CLK>;
clock-names = "core", "iface", "phy", "aux", "ref";
resets = <&gcc PCIE_ACLK_RESET>,
<&gcc PCIE_HCLK_RESET>,
<&gcc PCIE_POR_RESET>,
<&gcc PCIE_PCI_RESET>,
<&gcc PCIE_PHY_RESET>;
reset-names = "axi", "ahb", "por", "pci", "phy";
<&gcc PCIE_PHY_RESET>,
<&gcc PCIE_EXT_RESET>;
reset-names = "axi", "ahb", "por", "pci", "phy", "ext";
pinctrl-0 = <&pcie_pins_default>;
pinctrl-names = "default";
};

94
Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml Normal file
View File

@@ -0,0 +1,94 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
%YAML 1.2
---
$id: "http://devicetree.org/schemas/pci/ti,j721e-pci-ep.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: TI J721E PCI EP (PCIe Wrapper)
maintainers:
- Kishon Vijay Abraham I <kishon@ti.com>
allOf:
- $ref: "cdns-pcie-ep.yaml#"
properties:
compatible:
enum:
- ti,j721e-pcie-ep
reg:
maxItems: 4
reg-names:
items:
- const: intd_cfg
- const: user_cfg
- const: reg
- const: mem
ti,syscon-pcie-ctrl:
description: Phandle to the SYSCON entry required for configuring PCIe mode
and link speed.
allOf:
- $ref: /schemas/types.yaml#/definitions/phandle
power-domains:
maxItems: 1
clocks:
maxItems: 1
description: clock-specifier to represent input to the PCIe
clock-names:
items:
- const: fck
dma-coherent:
description: Indicates that the PCIe IP block can ensure the coherency
required:
- compatible
- reg
- reg-names
- ti,syscon-pcie-ctrl
- max-link-speed
- num-lanes
- power-domains
- clocks
- clock-names
- cdns,max-outbound-regions
- dma-coherent
- max-functions
- phys
- phy-names
examples:
- |
#include <dt-bindings/soc/ti,sci_pm_domain.h>
bus {
#address-cells = <2>;
#size-cells = <2>;
pcie0_ep: pcie-ep@d000000 {
compatible = "ti,j721e-pcie-ep";
reg = <0x00 0x02900000 0x00 0x1000>,
<0x00 0x02907000 0x00 0x400>,
<0x00 0x0d000000 0x00 0x00800000>,
<0x00 0x10000000 0x00 0x08000000>;
reg-names = "intd_cfg", "user_cfg", "reg", "mem";
ti,syscon-pcie-ctrl = <&pcie0_ctrl>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
clocks = <&k3_clks 239 1>;
clock-names = "fck";
cdns,max-outbound-regions = <16>;
max-functions = /bits/ 8 <6>;
dma-coherent;
phys = <&serdes0_pcie_link>;
phy-names = "pcie-phy";
};
};

113
Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml Normal file
View File

@@ -0,0 +1,113 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
%YAML 1.2
---
$id: "http://devicetree.org/schemas/pci/ti,j721e-pci-host.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: TI J721E PCI Host (PCIe Wrapper)
maintainers:
- Kishon Vijay Abraham I <kishon@ti.com>
allOf:
- $ref: "cdns-pcie-host.yaml#"
properties:
compatible:
enum:
- ti,j721e-pcie-host
reg:
maxItems: 4
reg-names:
items:
- const: intd_cfg
- const: user_cfg
- const: reg
- const: cfg
ti,syscon-pcie-ctrl:
description: Phandle to the SYSCON entry required for configuring PCIe mode
and link speed.
allOf:
- $ref: /schemas/types.yaml#/definitions/phandle
power-domains:
maxItems: 1
clocks:
maxItems: 1
description: clock-specifier to represent input to the PCIe
clock-names:
items:
- const: fck
vendor-id:
const: 0x104c
device-id:
const: 0xb00d
msi-map: true
required:
- compatible
- reg
- reg-names
- ti,syscon-pcie-ctrl
- max-link-speed
- num-lanes
- power-domains
- clocks
- clock-names
- vendor-id
- device-id
- msi-map
- dma-coherent
- dma-ranges
- ranges
- reset-gpios
- phys
- phy-names
examples:
- |
#include <dt-bindings/soc/ti,sci_pm_domain.h>
#include <dt-bindings/gpio/gpio.h>
bus {
#address-cells = <2>;
#size-cells = <2>;
pcie0_rc: pcie@2900000 {
compatible = "ti,j721e-pcie-host";
reg = <0x00 0x02900000 0x00 0x1000>,
<0x00 0x02907000 0x00 0x400>,
<0x00 0x0d000000 0x00 0x00800000>,
<0x00 0x10000000 0x00 0x00001000>;
reg-names = "intd_cfg", "user_cfg", "reg", "cfg";
ti,syscon-pcie-ctrl = <&pcie0_ctrl>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
clocks = <&k3_clks 239 1>;
clock-names = "fck";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x0 0xf>;
vendor-id = <0x104c>;
device-id = <0xb00d>;
msi-map = <0x0 &gic_its 0x0 0x10000>;
dma-coherent;
reset-gpios = <&exp1 6 GPIO_ACTIVE_HIGH>;
phys = <&serdes0_pcie_link>;
phy-names = "pcie-phy";
ranges = <0x01000000 0x0 0x10001000 0x00 0x10001000 0x0 0x0010000>,
<0x02000000 0x0 0x10011000 0x00 0x10011000 0x0 0x7fef000>;
dma-ranges = <0x02000000 0x0 0x0 0x0 0x0 0x10000 0x0>;
};
};

99
Documentation/devicetree/bindings/pci/xilinx-versal-cpm.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/pci/xilinx-versal-cpm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: CPM Host Controller device tree for Xilinx Versal SoCs
maintainers:
- Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
properties:
compatible:
const: xlnx,versal-cpm-host-1.00
reg:
items:
- description: Configuration space region and bridge registers.
- description: CPM system level control and status registers.
reg-names:
items:
- const: cfg
- const: cpm_slcr
interrupts:
maxItems: 1
msi-map:
description:
Maps a Requester ID to an MSI controller and associated MSI sideband data.
ranges:
maxItems: 2
"#interrupt-cells":
const: 1
interrupt-controller:
description: Interrupt controller node for handling legacy PCI interrupts.
type: object
properties:
"#address-cells":
const: 0
"#interrupt-cells":
const: 1
"interrupt-controller": true
additionalProperties: false
required:
- reg
- reg-names
- "#interrupt-cells"
- interrupts
- interrupt-parent
- interrupt-map
- interrupt-map-mask
- bus-range
- msi-map
- interrupt-controller
unevaluatedProperties: false
examples:
- |
versal {
#address-cells = <2>;
#size-cells = <2>;
cpm_pcie: pcie@fca10000 {
compatible = "xlnx,versal-cpm-host-1.00";
device_type = "pci";
#address-cells = <3>;
#interrupt-cells = <1>;
#size-cells = <2>;
interrupts = <0 72 4>;
interrupt-parent = <&gic>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
<0 0 0 2 &pcie_intc_0 1>,
<0 0 0 3 &pcie_intc_0 2>,
<0 0 0 4 &pcie_intc_0 3>;
bus-range = <0x00 0xff>;
ranges = <0x02000000 0x0 0xe0000000 0x0 0xe0000000 0x0 0x10000000>,
<0x43000000 0x80 0x00000000 0x80 0x00000000 0x0 0x80000000>;
msi-map = <0x0 &its_gic 0x0 0x10000>;
reg = <0x6 0x00000000 0x0 0x10000000>,
<0x0 0xfca10000 0x0 0x1000>;
reg-names = "cfg", "cpm_slcr";
pcie_intc_0: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
interrupt-controller;
};
};
};

86
Documentation/devicetree/bindings/power/supply/battery.txt
View File

@@ -1,87 +1,3 @@
Battery Characteristics
The devicetree battery node provides static battery characteristics.
In smart batteries, these are typically stored in non-volatile memory
on a fuel gauge chip. The battery node should be used where there is
no appropriate non-volatile memory, or it is unprogrammed/incorrect.
Upstream dts files should not include battery nodes, unless the battery
represented cannot easily be replaced in the system by one of a
different type. This prevents unpredictable, potentially harmful,
behavior should a replacement that changes the battery type occur
without a corresponding update to the dtb.
The contents of this file has been moved to battery.yaml
Please note that not all charger drivers respect all of the properties.
Required Properties:
- compatible: Must be "simple-battery"
Optional Properties:
- over-voltage-threshold-microvolt: battery over-voltage limit
- re-charge-voltage-microvolt: limit to automatically start charging again
- voltage-min-design-microvolt: drained battery voltage
- voltage-max-design-microvolt: fully charged battery voltage
- energy-full-design-microwatt-hours: battery design energy
- charge-full-design-microamp-hours: battery design capacity
- trickle-charge-current-microamp: current for trickle-charge phase
- precharge-current-microamp: current for pre-charge phase
- precharge-upper-limit-microvolt: limit when to change to constant charging
- charge-term-current-microamp: current for charge termination phase
- constant-charge-current-max-microamp: maximum constant input current
- constant-charge-voltage-max-microvolt: maximum constant input voltage
- factory-internal-resistance-micro-ohms: battery factory internal resistance
- ocv-capacity-table-0: An array providing the open circuit voltage (OCV)
of the battery and corresponding battery capacity percent, which is used
to look up battery capacity according to current OCV value. And the open
circuit voltage unit is microvolt.
- ocv-capacity-table-1: Same as ocv-capacity-table-0
......
- ocv-capacity-table-n: Same as ocv-capacity-table-0
- ocv-capacity-celsius: An array containing the temperature in degree Celsius,
for each of the battery capacity lookup table. The first temperature value
specifies the OCV table 0, and the second temperature value specifies the
OCV table 1, and so on.
- resistance-temp-table: An array providing the temperature in degree Celsius
and corresponding battery internal resistance percent, which is used to look
up the resistance percent according to current temperature to get a accurate
batterty internal resistance in different temperatures.
Battery properties are named, where possible, for the corresponding
elements in enum power_supply_property, defined in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/power_supply.h
Batteries must be referenced by chargers and/or fuel-gauges
using a phandle. The phandle's property should be named
"monitored-battery".
Example:
bat: battery {
compatible = "simple-battery";
voltage-min-design-microvolt = <3200000>;
voltage-max-design-microvolt = <4200000>;
energy-full-design-microwatt-hours = <5290000>;
charge-full-design-microamp-hours = <1430000>;
precharge-current-microamp = <256000>;
charge-term-current-microamp = <128000>;
constant-charge-current-max-microamp = <900000>;
constant-charge-voltage-max-microvolt = <4200000>;
factory-internal-resistance-micro-ohms = <250000>;
ocv-capacity-celsius = <(-10) 0 10>;
ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>, ...;
ocv-capacity-table-1 = <4200000 100>, <4185000 95>, <4113000 90>, ...;
ocv-capacity-table-2 = <4250000 100>, <4200000 95>, <4185000 90>, ...;
resistance-temp-table = <20 100>, <10 90>, <0 80>, <(-10) 60>;
};
charger: charger@11 {
....
monitored-battery = <&bat>;
...
};
fuel_gauge: fuel-gauge@22 {
....
monitored-battery = <&bat>;
...
};

144
Documentation/devicetree/bindings/power/supply/battery.yaml Normal file
View File

@@ -0,0 +1,144 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/battery.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Battery Characteristics
maintainers:
- Sebastian Reichel <sre@kernel.org>
description: |
The devicetree battery node provides static battery characteristics.
In smart batteries, these are typically stored in non-volatile memory
on a fuel gauge chip. The battery node should be used where there is
no appropriate non-volatile memory, or it is unprogrammed/incorrect.
Upstream dts files should not include battery nodes, unless the battery
represented cannot easily be replaced in the system by one of a
different type. This prevents unpredictable, potentially harmful,
behavior should a replacement that changes the battery type occur
without a corresponding update to the dtb.
Battery properties are named, where possible, for the corresponding elements
in enum power_supply_property, defined in include/linux/power_supply.h
Batteries must be referenced by chargers and/or fuel-gauges using a phandle.
The phandle's property should be named "monitored-battery".
properties:
compatible:
const: simple-battery
over-voltage-threshold-microvolt:
description: battery over-voltage limit
re-charge-voltage-microvolt:
description: limit to automatically start charging again
voltage-min-design-microvolt:
description: drained battery voltage
voltage-max-design-microvolt:
description: fully charged battery voltage
energy-full-design-microwatt-hours:
description: battery design energy
charge-full-design-microamp-hours:
description: battery design capacity
trickle-charge-current-microamp:
description: current for trickle-charge phase
precharge-current-microamp:
description: current for pre-charge phase
precharge-upper-limit-microvolt:
description: limit when to change to constant charging
charge-term-current-microamp:
description: current for charge termination phase
constant-charge-current-max-microamp:
description: maximum constant input current
constant-charge-voltage-max-microvolt:
description: maximum constant input voltage
factory-internal-resistance-micro-ohms:
description: battery factory internal resistance
resistance-temp-table:
description: |
An array providing the temperature in degree Celsius
and corresponding battery internal resistance percent, which is used to
look up the resistance percent according to current temperature to get an
accurate batterty internal resistance in different temperatures.
ocv-capacity-celsius:
description: |
An array containing the temperature in degree Celsius,
for each of the battery capacity lookup table.
required:
- compatible
patternProperties:
'^ocv-capacity-table-[0-9]+$':
$ref: /schemas/types.yaml#/definitions/uint32-matrix
description: |
An array providing the open circuit voltage (OCV)
of the battery and corresponding battery capacity percent, which is used
to look up battery capacity according to current OCV value. And the open
circuit voltage unit is microvolt.
maxItems: 100
items:
items:
- description: open circuit voltage (OCV) in microvolts
- description: battery capacity percent
maximum: 100
additionalProperties: false
examples:
- |
power {
#address-cells = <1>;
#size-cells = <0>;
battery: battery {
compatible = "simple-battery";
over-voltage-threshold-microvolt = <4500000>;
re-charge-voltage-microvolt = <250000>;
voltage-min-design-microvolt = <3200000>;
voltage-max-design-microvolt = <4200000>;
energy-full-design-microwatt-hours = <5290000>;
charge-full-design-microamp-hours = <1430000>;
precharge-current-microamp = <256000>;
precharge-upper-limit-microvolt = <2500000>;
charge-term-current-microamp = <128000>;
constant-charge-current-max-microamp = <900000>;
constant-charge-voltage-max-microvolt = <4200000>;
factory-internal-resistance-micro-ohms = <250000>;
ocv-capacity-celsius = <(-10) 0 10>;
/* table for -10 degree Celsius */
ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>;
/* table for 0 degree Celsius */
ocv-capacity-table-1 = <4200000 100>, <4185000 95>, <4113000 90>;
/* table for 10 degree Celsius */
ocv-capacity-table-2 = <4250000 100>, <4200000 95>, <4185000 90>;
resistance-temp-table = <20 100>, <10 90>, <0 80>, <(-10) 60>;
};
charger@11 {
reg = <0x11>;
monitored-battery = <&battery>;
};
fuel-gauge@22 {
reg = <0x22>;
monitored-battery = <&battery>;
};
};

93
Documentation/devicetree/bindings/power/supply/bq2515x.yaml Normal file
View File

@@ -0,0 +1,93 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright (C) 2020 Texas Instruments Incorporated
%YAML 1.2
---
$id: "http://devicetree.org/schemas/power/supply/bq2515x.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: TI bq2515x 500-mA Linear charger family
maintainers:
- Dan Murphy <dmurphy@ti.com>
- Ricardo Rivera-Matos <r-rivera-matos@ti.com>
description: |
The BQ2515x family is a highly integrated battery charge management IC that
integrates the most common functions for wearable devices, namely a charger,
an output voltage rail, ADC for battery and system monitoring, and
push-button controller.
Specifications about the charger can be found at:
http://www.ti.com/lit/ds/symlink/bq25150.pdf
http://www.ti.com/lit/ds/symlink/bq25155.pdf
properties:
compatible:
enum:
- ti,bq25150
- ti,bq25155
reg:
maxItems: 1
description: I2C address of the charger.
ac-detect-gpios:
description: |
GPIO used for connecting the bq2515x device PG (AC Detect)
pin.
maxItems: 1
reset-gpios:
description: GPIO used for hardware reset.
maxItems: 1
powerdown-gpios:
description: GPIO used for low power mode of IC.
maxItems: 1
charge-enable-gpios:
description: GPIO used to turn on and off charging.
maxItems: 1
input-current-limit-microamp:
$ref: /schemas/types.yaml#/definitions/uint32
description: Maximum input current in micro Amps.
minimum: 50000
maximum: 500000
monitored-battery:
$ref: /schemas/types.yaml#/definitions/phandle
description: phandle to the battery node being monitored
required:
- compatible
- reg
- monitored-battery
additionalProperties: false
examples:
- |
bat: battery {
compatible = "simple-battery";
constant-charge-current-max-microamp = <50000>;
precharge-current-microamp = <2500>;
constant-charge-voltage-max-microvolt = <4000000>;
};
#include <dt-bindings/gpio/gpio.h>
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
bq25150: charger@6b {
compatible = "ti,bq25150";
reg = <0x6b>;
monitored-battery = <&bat>;
input-current-limit-microamp = <100000>;
ac-detect-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
powerdown-gpios = <&gpio0 15 GPIO_ACTIVE_HIGH>;
charge-enable-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
};
};

26
Documentation/devicetree/bindings/power/supply/bq25890.txt
View File

@@ -10,6 +10,7 @@ Required properties:
* "ti,bq25895"
* "ti,bq25896"
- reg: integer, i2c address of the device.
- interrupts: interrupt line;
- ti,battery-regulation-voltage: integer, maximum charging voltage (in uV);
- ti,charge-current: integer, maximum charging current (in uA);
- ti,termination-current: integer, charge will be terminated when current in
@@ -36,17 +37,20 @@ Optional properties:
Example:
bq25890 {
compatible = "ti,bq25890";
reg = <0x6a>;
compatible = "ti,bq25890";
reg = <0x6a>;
ti,battery-regulation-voltage = <4200000>;
ti,charge-current = <1000000>;
ti,termination-current = <50000>;
ti,precharge-current = <128000>;
ti,minimum-sys-voltage = <3600000>;
ti,boost-voltage = <5000000>;
ti,boost-max-current = <1000000>;
interrupt-parent = <&gpio1>;
interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
ti,use-ilim-pin;
ti,thermal-regulation-threshold = <120>;
ti,battery-regulation-voltage = <4200000>;
ti,charge-current = <1000000>;
ti,termination-current = <50000>;
ti,precharge-current = <128000>;
ti,minimum-sys-voltage = <3600000>;
ti,boost-voltage = <5000000>;
ti,boost-max-current = <1000000>;
ti,use-ilim-pin;
ti,thermal-regulation-threshold = <120>;
};

2
Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
View File

@@ -49,6 +49,8 @@ properties:
- ti,bq27426
- ti,bq27441
- ti,bq27621
- ti,bq27z561
- ti,bq28z610
reg:
maxItems: 1

31
Documentation/devicetree/bindings/power/supply/gpio-charger.txt
View File

@@ -1,31 +0,0 @@
gpio-charger
Required properties :
- compatible : "gpio-charger"
- gpios : GPIO indicating the charger presence.
See GPIO binding in bindings/gpio/gpio.txt .
- charger-type : power supply type, one of
unknown
battery
ups
mains
usb-sdp (USB standard downstream port)
usb-dcp (USB dedicated charging port)
usb-cdp (USB charging downstream port)
usb-aca (USB accessory charger adapter)
Optional properties:
- charge-status-gpios: GPIO indicating whether a battery is charging.
Example:
usb_charger: charger {
compatible = "gpio-charger";
charger-type = "usb-sdp";
gpios = <&gpd 28 GPIO_ACTIVE_LOW>;
charge-status-gpios = <&gpc 27 GPIO_ACTIVE_LOW>;
};
battery {
power-supplies = <&usb_charger>;
};

63
Documentation/devicetree/bindings/power/supply/gpio-charger.yaml Normal file
View File

@@ -0,0 +1,63 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/gpio-charger.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: simple battery chargers only communicating through GPIOs
maintainers:
- Sebastian Reichel <sre@kernel.org>
description:
This binding is for all chargers, which are working more or less
autonomously, only providing some status GPIOs and possibly some
GPIOs for limited control over the charging process.
properties:
compatible:
const: gpio-charger
charger-type:
enum:
- unknown
- battery
- ups
- mains
- usb-sdp # USB standard downstream port
- usb-dcp # USB dedicated charging port
- usb-cdp # USB charging downstream port
- usb-aca # USB accessory charger adapter
description:
Type of the charger, e.g. "mains" for a wall charger.
gpios:
maxItems: 1
description: GPIO indicating the charger presence
charge-status-gpios:
maxItems: 1
description: GPIO indicating the charging status
required:
- compatible
anyOf:
- required:
- gpios
- required:
- charge-status-gpios
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
charger {
compatible = "gpio-charger";
charger-type = "usb-sdp";
gpios = <&gpd 28 GPIO_ACTIVE_LOW>;
charge-status-gpios = <&gpc 27 GPIO_ACTIVE_LOW>;
};

2
Documentation/devicetree/bindings/vendor-prefixes.yaml
View File

@@ -473,6 +473,8 @@ patternProperties:
description: ILI Technology Corporation (ILITEK)
"^img,.*":
description: Imagination Technologies Ltd.
"^imi,.*":
description: Integrated Micro-Electronics Inc.
"^incircuit,.*":
description: In-Circuit GmbH
"^inet-tek,.*":

21
Documentation/driver-api/dmaengine/provider.rst
View File

@@ -239,6 +239,22 @@ Currently, the types available are:
want to transfer a portion of uncompressed data directly to the
display to print it
- DMA_COMPLETION_NO_ORDER
- The device does not support in order completion.
- The driver should return DMA_OUT_OF_ORDER for device_tx_status if
the device is setting this capability.
- All cookie tracking and checking API should be treated as invalid if
the device exports this capability.
- At this point, this is incompatible with polling option for dmatest.
- If this cap is set, the user is recommended to provide an unique
identifier for each descriptor sent to the DMA device in order to
properly track the completion.
- DMA_REPEAT
- The device supports repeated transfers. A repeated transfer, indicated by
@@ -420,6 +436,9 @@ supported.
- In the case of a cyclic transfer, it should only take into
account the current period.
- Should return DMA_OUT_OF_ORDER if the device does not support in order
completion and is completing the operation out of order.
- This function can be called in an interrupt context.
- device_config
@@ -509,7 +528,7 @@ dma_cookie_t
DMA_CTRL_ACK
- If clear, the descriptor cannot be reused by provider until the
client acknowledges receipt, i.e. has has a chance to establish any
client acknowledges receipt, i.e. has a chance to establish any
dependency chains
- This can be acked by invoking async_tx_ack()

2
Documentation/driver-api/media/drivers/pvrusb2.rst
View File

@@ -20,7 +20,7 @@ last known snapshot and evolved the driver to the state it is in
here.
More information on this driver can be found at:
http://www.isely.net/pvrusb2.html
https://www.isely.net/pvrusb2.html
This driver has a strong separation of layers. They are very

2
Documentation/driver-api/media/drivers/tuners.rst
View File

@@ -18,7 +18,7 @@ These differ mainly by the bandswitch byte.
Tuner Manufacturers
-------------------
- SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
- Samsung Tuner identification: (e.g. TCPM9091PD27)
.. code-block:: none

2
Documentation/features/core/jump-labels/arch-support.txt
View File

@@ -23,7 +23,7 @@
| openrisc: | TODO |
| parisc: | ok |
| powerpc: | ok |
| riscv: | TODO |
| riscv: | ok |
| s390: | ok |
| sh: | TODO |
| sparc: | ok |

2
Documentation/features/debug/debug-vm-pgtable/arch-support.txt
View File

@@ -23,7 +23,7 @@
| openrisc: | TODO |
| parisc: | TODO |
| powerpc: | ok |
| riscv: | TODO |
| riscv: | ok |
| s390: | ok |
| sh: | TODO |
| sparc: | TODO |

4
Documentation/features/sched/membarrier-sync-core/arch-support.txt
View File

@@ -5,7 +5,7 @@
#
# Architecture requirements
#
# * arm/arm64
# * arm/arm64/powerpc
#
# Rely on implicit context synchronization as a result of exception return
# when returning from IPI handler, and when returning to user-space.
@@ -45,7 +45,7 @@
| nios2: | TODO |
| openrisc: | TODO |
| parisc: | TODO |
| powerpc: | TODO |
| powerpc: | ok |
| riscv: | TODO |
| s390: | TODO |
| sh: | TODO |

2
Documentation/filesystems/dlmfs.rst
View File

@@ -12,7 +12,7 @@ dlmfs is built with OCFS2 as it requires most of its infrastructure.
:Project web page: http://ocfs2.wiki.kernel.org
:Tools web page: https://github.com/markfasheh/ocfs2-tools
:OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/
:OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
All code copyright 2005 Oracle except when otherwise noted.

2
Documentation/filesystems/ocfs2.rst
View File

@@ -14,7 +14,7 @@ get "mount.ocfs2" and "ocfs2_hb_ctl".
Project web page: http://ocfs2.wiki.kernel.org
Tools git tree: https://github.com/markfasheh/ocfs2-tools
OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/
OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
All code copyright 2005 Oracle except when otherwise noted.

18
Documentation/filesystems/tmpfs.rst
View File

@@ -150,6 +150,22 @@ These options do not have any effect on remount. You can change these
parameters with chmod(1), chown(1) and chgrp(1) on a mounted filesystem.
tmpfs has a mount option to select whether it will wrap at 32- or 64-bit inode
numbers:
======= ========================
inode64 Use 64-bit inode numbers
inode32 Use 32-bit inode numbers
======= ========================
On a 32-bit kernel, inode32 is implicit, and inode64 is refused at mount time.
On a 64-bit kernel, CONFIG_TMPFS_INODE64 sets the default. inode64 avoids the
possibility of multiple files with the same inode number on a single device;
but risks glibc failing with EOVERFLOW once 33-bit inode numbers are reached -
if a long-lived tmpfs is accessed by 32-bit applications so ancient that
opening a file larger than 2GiB fails with EINVAL.
So 'mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs'
will give you tmpfs instance on /mytmpfs which can allocate 10GB
RAM/SWAP in 10240 inodes and it is only accessible by root.
@@ -161,3 +177,5 @@ RAM/SWAP in 10240 inodes and it is only accessible by root.
Hugh Dickins, 4 June 2007
:Updated:
KOSAKI Motohiro, 16 Mar 2010
:Updated:
Chris Down, 13 July 2020

14
Documentation/memory-barriers.txt
View File

@@ -1935,6 +1935,20 @@ There are some more advanced barrier functions:
relaxed I/O accessors and the Documentation/DMA-API.txt file for more
information on consistent memory.
(*) pmem_wmb();
This is for use with persistent memory to ensure that stores for which
modifications are written to persistent storage reached a platform
durability domain.
For example, after a non-temporal write to pmem region, we use pmem_wmb()
to ensure that stores have reached a platform durability domain. This ensures
that stores have updated persistent storage before any data access or
data transfer caused by subsequent instructions is initiated. This is
in addition to the ordering done by wmb().
For load from persistent memory, existing read memory barriers are sufficient
to ensure read ordering.
===============================
IMPLICIT KERNEL MEMORY BARRIERS

10
Documentation/powerpc/cpu_families.rst
View File

@@ -9,7 +9,9 @@ and are supported by arch/powerpc.
Book3S (aka sPAPR)
------------------
- Hash MMU
- Hash MMU (except 603 and e300)
- Software loaded TLB (603 and e300)
- Selectable Software loaded TLB in addition to hash MMU (755, 7450, e600)
- Mix of 32 & 64 bit::
+--------------+ +----------------+
@@ -24,9 +26,9 @@ Book3S (aka sPAPR)
| |
| |
v v
+--------------+ +----------------+ +-------+
| 604 | | 750 (G3) | ---> | 750CX |
+--------------+ +----------------+ +-------+
+--------------+ +-----+ +----------------+ +-------+
| 604 | | 755 | <--- | 750 (G3) | ---> | 750CX |
+--------------+ +-----+ +----------------+ +-------+
| | |
| | |
v v v

2
Documentation/powerpc/mpc52xx.rst
View File

@@ -2,7 +2,7 @@
Linux 2.6.x on MPC52xx family
=============================
For the latest info, go to http://www.246tNt.com/mpc52xx/
For the latest info, go to https://www.246tNt.com/mpc52xx/
To compile/use :

42
Documentation/powerpc/syscall64-abi.rst
View File

@@ -5,6 +5,15 @@ Power Architecture 64-bit Linux system call ABI
syscall
=======
Invocation
----------
The syscall is made with the sc instruction, and returns with execution
continuing at the instruction following the sc instruction.
If PPC_FEATURE2_SCV appears in the AT_HWCAP2 ELF auxiliary vector, the
scv 0 instruction is an alternative that may provide better performance,
with some differences to calling sequence.
syscall calling sequence\ [1]_ matches the Power Architecture 64-bit ELF ABI
specification C function calling sequence, including register preservation
rules, with the following differences.
@@ -12,16 +21,23 @@ rules, with the following differences.
.. [1] Some syscalls (typically low-level management functions) may have
different calling sequences (e.g., rt_sigreturn).
Parameters and return value
---------------------------
Parameters
----------
The system call number is specified in r0.
There is a maximum of 6 integer parameters to a syscall, passed in r3-r8.
Both a return value and a return error code are returned. cr0.SO is the return
error code, and r3 is the return value or error code. When cr0.SO is clear,
the syscall succeeded and r3 is the return value. When cr0.SO is set, the
syscall failed and r3 is the error code that generally corresponds to errno.
Return value
------------
- For the sc instruction, both a value and an error condition are returned.
cr0.SO is the error condition, and r3 is the return value. When cr0.SO is
clear, the syscall succeeded and r3 is the return value. When cr0.SO is set,
the syscall failed and r3 is the error value (that normally corresponds to
errno).
- For the scv 0 instruction, the return value indicates failure if it is
-4095..-1 (i.e., it is >= -MAX_ERRNO (-4095) as an unsigned comparison),
in which case the error value is the negated return value.
Stack
-----
@@ -34,22 +50,23 @@ Register preservation rules match the ELF ABI calling sequence with the
following differences:
=========== ============= ========================================
--- For the sc instruction, differences with the ELF ABI ---
r0 Volatile (System call number.)
r3 Volatile (Parameter 1, and return value.)
r4-r8 Volatile (Parameters 2-6.)
cr0 Volatile (cr0.SO is the return error condition)
cr0 Volatile (cr0.SO is the return error condition.)
cr1, cr5-7 Nonvolatile
lr Nonvolatile
--- For the scv 0 instruction, differences with the ELF ABI ---
r0 Volatile (System call number.)
r3 Volatile (Parameter 1, and return value.)
r4-r8 Volatile (Parameters 2-6.)
=========== ============= ========================================
All floating point and vector data registers as well as control and status
registers are nonvolatile.
Invocation
----------
The syscall is performed with the sc instruction, and returns with execution
continuing at the instruction following the sc instruction.
Transactional Memory
--------------------
Syscall behavior can change if the processor is in transactional or suspended
@@ -75,6 +92,7 @@ auxiliary vector.
returning to the caller. This case is not well defined or supported, so this
behavior should not be relied upon.
scv 0 syscalls will always behave as PPC_FEATURE2_HTM_NOSC.
vsyscall
========

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

@@ -57,6 +57,9 @@ returns the information to the application. The ioctl never fails.
- ``name[32]``
- The name of this CEC adapter. The combination ``driver`` and
``name`` must be unique.
* - __u32
- ``available_log_addrs``
- The maximum number of logical addresses that can be configured.
* - __u32
- ``capabilities``
- The capabilities of the CEC adapter, see

3
Documentation/userspace-api/media/dvb/fe-get-info.rst
View File

@@ -34,8 +34,7 @@ Arguments
File descriptor returned by :ref:`open() <frontend_f_open>`.
``argp``
pointer to struct struct
:c:type:`dvb_frontend_info`
pointer to struct :c:type:`dvb_frontend_info`
Description

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

@@ -23,8 +23,8 @@ argument to the :ref:`VIDIOC_QUERYBUF`,
:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and
:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. In the multi-planar API,
some plane-specific members of struct :c:type:`v4l2_buffer`,
such as pointers and sizes for each plane, are stored in struct
struct :c:type:`v4l2_plane` instead. In that case, struct
such as pointers and sizes for each plane, are stored in
struct :c:type:`v4l2_plane` instead. In that case,
struct :c:type:`v4l2_buffer` contains an array of plane structures.
Dequeued video buffers come with timestamps. The driver decides at which
@@ -577,7 +577,10 @@ Buffer Flags
applications shall use this flag if the data captured in the
buffer is not going to be touched by the CPU, instead the buffer
will, probably, be passed on to a DMA-capable hardware unit for
further processing or output.
further processing or output. This flag is ignored unless the
queue is used for :ref:`memory mapping <mmap>` streaming I/O and
reports :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
<V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability.
* .. _`V4L2-BUF-FLAG-NO-CACHE-CLEAN`:
- ``V4L2_BUF_FLAG_NO_CACHE_CLEAN``
@@ -585,7 +588,10 @@ Buffer Flags
- Caches do not have to be cleaned for this buffer. Typically
applications shall use this flag for output buffers if the data in
this buffer has not been created by the CPU but by some
DMA-capable unit, in which case caches have not been used.
DMA-capable unit, in which case caches have not been used. This flag
is ignored unless the queue is used for :ref:`memory mapping <mmap>`
streaming I/O and reports :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
<V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability.
* .. _`V4L2-BUF-FLAG-M2M-HOLD-CAPTURE-BUF`:
- ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF``
@@ -681,6 +687,36 @@ Buffer Flags
\normalsize
.. _memory-flags:
Memory Consistency Flags
========================
.. tabularcolumns:: |p{7.0cm}|p{2.2cm}|p{8.3cm}|
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 3 1 4
* .. _`V4L2-FLAG-MEMORY-NON-CONSISTENT`:
- ``V4L2_FLAG_MEMORY_NON_CONSISTENT``
- 0x00000001
- A buffer is allocated either in consistent (it will be automatically
coherent between the CPU and the bus) or non-consistent memory. The
latter can provide performance gains, for instance the CPU cache
sync/flush operations can be avoided if the buffer is accessed by the
corresponding device only and the CPU does not read/write to/from that
buffer. However, this requires extra care from the driver -- it must
guarantee memory consistency by issuing a cache flush/sync when
consistency is needed. If this flag is set V4L2 will attempt to
allocate the buffer in non-consistent memory. The flag takes effect
only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the
queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
<V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability.
.. c:type:: v4l2_memory

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

@@ -767,8 +767,8 @@ scaled to [-128…128] and then clipped to [-128…127].
information. So if something other than sRGB is used, then the driver
will have to set that information explicitly. Effectively
``V4L2_COLORSPACE_JPEG`` can be considered to be an abbreviation for
``V4L2_COLORSPACE_SRGB``, ``V4L2_YCBCR_ENC_601`` and
``V4L2_QUANTIZATION_FULL_RANGE``.
``V4L2_COLORSPACE_SRGB``, ``V4L2_XFER_FUNC_SRGB``, ``V4L2_YCBCR_ENC_601``
and ``V4L2_QUANTIZATION_FULL_RANGE``.
***************************************
Detailed Transfer Function Descriptions

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

@@ -247,7 +247,7 @@ Querying Capabilities
Initialization
==============
1. Set the coded format on ``OUTPUT`` via :c:func:`VIDIOC_S_FMT`
1. Set the coded format on ``OUTPUT`` via :c:func:`VIDIOC_S_FMT`.
* **Required fields:**
@@ -803,7 +803,7 @@ it may be affected as per normal decoder operation.
* The decoder will drop all the pending ``OUTPUT`` buffers and they must be
treated as returned to the client (following standard semantics).
2. Restart the ``OUTPUT`` queue via :c:func:`VIDIOC_STREAMON`
2. Restart the ``OUTPUT`` queue via :c:func:`VIDIOC_STREAMON`.
* **Required fields:**
@@ -906,7 +906,9 @@ reflected by corresponding queries):
* visible resolution (selection rectangles),
* the minimum number of buffers needed for decoding.
* the minimum number of buffers needed for decoding,
* bit-depth of the bitstream has been changed.
Whenever that happens, the decoder must proceed as follows:
@@ -1059,7 +1061,7 @@ sequence was started.
``V4L2_DEC_CMD_STOP`` again while the drain sequence is in progress and they
will fail with -EBUSY error code if attempted.
Although mandatory, the availability of decoder commands may be queried
Although not mandatory, the availability of decoder commands may be queried
using :c:func:`VIDIOC_TRY_DECODER_CMD`.
End of Stream

753
Documentation/userspace-api/media/v4l/dev-encoder.rst Normal file
View File

@@ -0,0 +1,753 @@
.. This file is dual-licensed: you can use it either under the terms
.. of the GPL 2.0 or the GFDL 1.1+ license, at your option. Note that this
.. dual licensing only applies to this file, and not this project as a
.. whole.
..
.. a) This file is free software; you can redistribute it and/or
.. modify it under the terms of the GNU General Public License as
.. published by the Free Software Foundation version 2 of
.. the License.
..
.. This file is distributed in the hope that it will be useful,
.. but WITHOUT ANY WARRANTY; without even the implied warranty of
.. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
.. GNU General Public License for more details.
..
.. Or, alternatively,
..
.. b) Permission is granted to copy, distribute and/or modify this
.. document under the terms of the GNU Free Documentation License,
.. Version 1.1 or any later version published by the Free Software
.. Foundation, with no Invariant Sections, no Front-Cover Texts
.. and no Back-Cover Texts. A copy of the license is included at
.. Documentation/userspace-api/media/fdl-appendix.rst.
..
.. TODO: replace it to GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections
.. _encoder:
*************************************************
Memory-to-Memory Stateful Video Encoder Interface
*************************************************
A stateful video encoder takes raw video frames in display order and encodes
them into a bytestream. It generates complete chunks of the bytestream, including
all metadata, headers, etc. The resulting bytestream does not require any
further post-processing by the client.
Performing software stream processing, header generation etc. in the driver
in order to support this interface is strongly discouraged. In case such
operations are needed, use of the Stateless Video Encoder Interface (in
development) is strongly advised.
Conventions and Notations Used in This Document
===============================================
1. The general V4L2 API rules apply if not specified in this document
otherwise.
2. The meaning of words "must", "may", "should", etc. is as per `RFC
2119 <https://tools.ietf.org/html/rfc2119>`_.
3. All steps not marked "optional" are required.
4. :c:func:`VIDIOC_G_EXT_CTRLS` and :c:func:`VIDIOC_S_EXT_CTRLS` may be used
interchangeably with :c:func:`VIDIOC_G_CTRL` and :c:func:`VIDIOC_S_CTRL`,
unless specified otherwise.
5. Single-planar API (see :ref:`planar-apis`) and applicable structures may be
used interchangeably with multi-planar API, unless specified otherwise,
depending on encoder capabilities and following the general V4L2 guidelines.
6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i =
[0..2]: i = 0, 1, 2.
7. Given an ``OUTPUT`` buffer A, then A' represents a buffer on the ``CAPTURE``
queue containing data that resulted from processing buffer A.
Glossary
========
Refer to :ref:`decoder-glossary`.
State Machine
=============
.. kernel-render:: DOT
:alt: DOT digraph of encoder state machine
:caption: Encoder State Machine
digraph encoder_state_machine {
node [shape = doublecircle, label="Encoding"] Encoding;
node [shape = circle, label="Initialization"] Initialization;
node [shape = circle, label="Stopped"] Stopped;
node [shape = circle, label="Drain"] Drain;
node [shape = circle, label="Reset"] Reset;
node [shape = point]; qi
qi -> Initialization [ label = "open()" ];
Initialization -> Encoding [ label = "Both queues streaming" ];
Encoding -> Drain [ label = "V4L2_ENC_CMD_STOP" ];
Encoding -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ];
Encoding -> Stopped [ label = "VIDIOC_STREAMOFF(OUTPUT)" ];
Encoding -> Encoding;
Drain -> Stopped [ label = "All CAPTURE\nbuffers dequeued\nor\nVIDIOC_STREAMOFF(OUTPUT)" ];
Drain -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ];
Reset -> Encoding [ label = "VIDIOC_STREAMON(CAPTURE)" ];
Reset -> Initialization [ label = "VIDIOC_REQBUFS(OUTPUT, 0)" ];
Stopped -> Encoding [ label = "V4L2_ENC_CMD_START\nor\nVIDIOC_STREAMON(OUTPUT)" ];
Stopped -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ];
}
Querying Capabilities
=====================
1. To enumerate the set of coded formats supported by the encoder, the
client may call :c:func:`VIDIOC_ENUM_FMT` on ``CAPTURE``.
* The full set of supported formats will be returned, regardless of the
format set on ``OUTPUT``.
2. To enumerate the set of supported raw formats, the client may call
:c:func:`VIDIOC_ENUM_FMT` on ``OUTPUT``.
* Only the formats supported for the format currently active on ``CAPTURE``
will be returned.
* In order to enumerate raw formats supported by a given coded format,
the client must first set that coded format on ``CAPTURE`` and then
enumerate the formats on ``OUTPUT``.
3. The client may use :c:func:`VIDIOC_ENUM_FRAMESIZES` to detect supported
resolutions for a given format, passing the desired pixel format in
:c:type:`v4l2_frmsizeenum` ``pixel_format``.
* Values returned by :c:func:`VIDIOC_ENUM_FRAMESIZES` for a coded pixel
format will include all possible coded resolutions supported by the
encoder for the given coded pixel format.
* Values returned by :c:func:`VIDIOC_ENUM_FRAMESIZES` for a raw pixel format
will include all possible frame buffer resolutions supported by the
encoder for the given raw pixel format and coded format currently set on
``CAPTURE``.
4. The client may use :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` to detect supported
frame intervals for a given format and resolution, passing the desired pixel
format in :c:type:`v4l2_frmsizeenum` ``pixel_format`` and the resolution
in :c:type:`v4l2_frmsizeenum` ``width`` and :c:type:`v4l2_frmsizeenum`
``height``.
* Values returned by :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` for a coded pixel
format and coded resolution will include all possible frame intervals
supported by the encoder for the given coded pixel format and resolution.
* Values returned by :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` for a raw pixel
format and resolution will include all possible frame intervals supported
by the encoder for the given raw pixel format and resolution and for the
coded format, coded resolution and coded frame interval currently set on
``CAPTURE``.
* Support for :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` is optional. If it is
not implemented, then there are no special restrictions other than the
limits of the codec itself.
5. Supported profiles and levels for the coded format currently set on
``CAPTURE``, if applicable, may be queried using their respective controls
via :c:func:`VIDIOC_QUERYCTRL`.
6. Any additional encoder capabilities may be discovered by querying
their respective controls.
Initialization
==============
1. Set the coded format on the ``CAPTURE`` queue via :c:func:`VIDIOC_S_FMT`.
* **Required fields:**
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``.
``pixelformat``
the coded format to be produced.
``sizeimage``
desired size of ``CAPTURE`` buffers; the encoder may adjust it to
match hardware requirements.
``width``, ``height``
ignored (read-only).
other fields
follow standard semantics.
* **Return fields:**
``sizeimage``
adjusted size of ``CAPTURE`` buffers.
``width``, ``height``
the coded size selected by the encoder based on current state, e.g.
``OUTPUT`` format, selection rectangles, etc. (read-only).
.. important::
Changing the ``CAPTURE`` format may change the currently set ``OUTPUT``
format. How the new ``OUTPUT`` format is determined is up to the encoder
and the client must ensure it matches its needs afterwards.
2. **Optional.** Enumerate supported ``OUTPUT`` formats (raw formats for
source) for the selected coded format via :c:func:`VIDIOC_ENUM_FMT`.
* **Required fields:**
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
other fields
follow standard semantics.
* **Return fields:**
``pixelformat``
raw format supported for the coded format currently selected on
the ``CAPTURE`` queue.
other fields
follow standard semantics.
3. Set the raw source format on the ``OUTPUT`` queue via
:c:func:`VIDIOC_S_FMT`.
* **Required fields:**
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
``pixelformat``
raw format of the source.
``width``, ``height``
source resolution.
other fields
follow standard semantics.
* **Return fields:**
``width``, ``height``
may be adjusted to match encoder minimums, maximums and alignment
requirements, as required by the currently selected formats, as
reported by :c:func:`VIDIOC_ENUM_FRAMESIZES`.
other fields
follow standard semantics.
* Setting the ``OUTPUT`` format will reset the selection rectangles to their
default values, based on the new resolution, as described in the next
step.
4. Set the raw frame interval on the ``OUTPUT`` queue via
:c:func:`VIDIOC_S_PARM`. This also sets the coded frame interval on the
``CAPTURE`` queue to the same value.
* ** Required fields:**
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
``parm.output``
set all fields except ``parm.output.timeperframe`` to 0.
``parm.output.timeperframe``
the desired frame interval; the encoder may adjust it to
match hardware requirements.
* **Return fields:**
``parm.output.timeperframe``
the adjusted frame interval.
.. important::
Changing the ``OUTPUT`` frame interval *also* sets the framerate that
the encoder uses to encode the video. So setting the frame interval
to 1/24 (or 24 frames per second) will produce a coded video stream
that can be played back at that speed. The frame interval for the
``OUTPUT`` queue is just a hint, the application may provide raw
frames at a different rate. It can be used by the driver to help
schedule multiple encoders running in parallel.
In the next step the ``CAPTURE`` frame interval can optionally be
changed to a different value. This is useful for off-line encoding
were the coded frame interval can be different from the rate at
which raw frames are supplied.
.. important::
``timeperframe`` deals with *frames*, not fields. So for interlaced
formats this is the time per two fields, since a frame consists of
a top and a bottom field.
.. note::
It is due to historical reasons that changing the ``OUTPUT`` frame
interval also changes the coded frame interval on the ``CAPTURE``
queue. Ideally these would be independent settings, but that would
break the existing API.
5. **Optional** Set the coded frame interval on the ``CAPTURE`` queue via
:c:func:`VIDIOC_S_PARM`. This is only necessary if the coded frame
interval is different from the raw frame interval, which is typically
the case for off-line encoding. Support for this feature is signalled
by the :ref:`V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL <fmtdesc-flags>` format flag.
* ** Required fields:**
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``.
``parm.capture``
set all fields except ``parm.capture.timeperframe`` to 0.
``parm.capture.timeperframe``
the desired coded frame interval; the encoder may adjust it to
match hardware requirements.
* **Return fields:**
``parm.capture.timeperframe``
the adjusted frame interval.
.. important::
Changing the ``CAPTURE`` frame interval sets the framerate for the
coded video. It does *not* set the rate at which buffers arrive on the
``CAPTURE`` queue, that depends on how fast the encoder is and how
fast raw frames are queued on the ``OUTPUT`` queue.
.. important::
``timeperframe`` deals with *frames*, not fields. So for interlaced
formats this is the time per two fields, since a frame consists of
a top and a bottom field.
.. note::
Not all drivers support this functionality, in that case just set
the desired coded frame interval for the ``OUTPUT`` queue.
However, drivers that can schedule multiple encoders based on the
``OUTPUT`` frame interval must support this optional feature.
6. **Optional.** Set the visible resolution for the stream metadata via
:c:func:`VIDIOC_S_SELECTION` on the ``OUTPUT`` queue if it is desired
to be different than the full OUTPUT resolution.
* **Required fields:**
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
``target``
set to ``V4L2_SEL_TGT_CROP``.
``r.left``, ``r.top``, ``r.width``, ``r.height``
visible rectangle; this must fit within the `V4L2_SEL_TGT_CROP_BOUNDS`
rectangle and may be subject to adjustment to match codec and
hardware constraints.
* **Return fields:**
``r.left``, ``r.top``, ``r.width``, ``r.height``
visible rectangle adjusted by the encoder.
* The following selection targets are supported on ``OUTPUT``:
``V4L2_SEL_TGT_CROP_BOUNDS``
equal to the full source frame, matching the active ``OUTPUT``
format.
``V4L2_SEL_TGT_CROP_DEFAULT``
equal to ``V4L2_SEL_TGT_CROP_BOUNDS``.
``V4L2_SEL_TGT_CROP``
rectangle within the source buffer to be encoded into the
``CAPTURE`` stream; defaults to ``V4L2_SEL_TGT_CROP_DEFAULT``.
.. note::
A common use case for this selection target is encoding a source
video with a resolution that is not a multiple of a macroblock,
e.g. the common 1920x1080 resolution may require the source
buffers to be aligned to 1920x1088 for codecs with 16x16 macroblock
size. To avoid encoding the padding, the client needs to explicitly
configure this selection target to 1920x1080.
.. warning::
The encoder may adjust the crop/compose rectangles to the nearest
supported ones to meet codec and hardware requirements. The client needs
to check the adjusted rectangle returned by :c:func:`VIDIOC_S_SELECTION`.
7. Allocate buffers for both ``OUTPUT`` and ``CAPTURE`` via
:c:func:`VIDIOC_REQBUFS`. This may be performed in any order.
* **Required fields:**
``count``
requested number of buffers to allocate; greater than zero.
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT`` or
``CAPTURE``.
other fields
follow standard semantics.
* **Return fields:**
``count``
actual number of buffers allocated.
.. warning::
The actual number of allocated buffers may differ from the ``count``
given. The client must check the updated value of ``count`` after the
call returns.
.. note::
To allocate more than the minimum number of OUTPUT buffers (for pipeline
depth), the client may query the ``V4L2_CID_MIN_BUFFERS_FOR_OUTPUT``
control to get the minimum number of buffers required, and pass the
obtained value plus the number of additional buffers needed in the
``count`` field to :c:func:`VIDIOC_REQBUFS`.
Alternatively, :c:func:`VIDIOC_CREATE_BUFS` can be used to have more
control over buffer allocation.
* **Required fields:**
``count``
requested number of buffers to allocate; greater than zero.
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
other fields
follow standard semantics.
* **Return fields:**
``count``
adjusted to the number of allocated buffers.
8. Begin streaming on both ``OUTPUT`` and ``CAPTURE`` queues via
:c:func:`VIDIOC_STREAMON`. This may be performed in any order. The actual
encoding process starts when both queues start streaming.
.. note::
If the client stops the ``CAPTURE`` queue during the encode process and then
restarts it again, the encoder will begin generating a stream independent
from the stream generated before the stop. The exact constraints depend
on the coded format, but may include the following implications:
* encoded frames produced after the restart must not reference any
frames produced before the stop, e.g. no long term references for
H.264/HEVC,
* any headers that must be included in a standalone stream must be
produced again, e.g. SPS and PPS for H.264/HEVC.
Encoding
========
This state is reached after the `Initialization` sequence finishes
successfully. In this state, the client queues and dequeues buffers to both
queues via :c:func:`VIDIOC_QBUF` and :c:func:`VIDIOC_DQBUF`, following the
standard semantics.
The content of encoded ``CAPTURE`` buffers depends on the active coded pixel
format and may be affected by codec-specific extended controls, as stated
in the documentation of each format.
Both queues operate independently, following standard behavior of V4L2 buffer
queues and memory-to-memory devices. In addition, the order of encoded frames
dequeued from the ``CAPTURE`` queue may differ from the order of queuing raw
frames to the ``OUTPUT`` queue, due to properties of the selected coded format,
e.g. frame reordering.
The client must not assume any direct relationship between ``CAPTURE`` and
``OUTPUT`` buffers and any specific timing of buffers becoming
available to dequeue. Specifically:
* a buffer queued to ``OUTPUT`` may result in more than one buffer produced on
``CAPTURE`` (for example, if returning an encoded frame allowed the encoder
to return a frame that preceded it in display, but succeeded it in the decode
order; however, there may be other reasons for this as well),
* a buffer queued to ``OUTPUT`` may result in a buffer being produced on
``CAPTURE`` later into encode process, and/or after processing further
``OUTPUT`` buffers, or be returned out of order, e.g. if display
reordering is used,
* buffers may become available on the ``CAPTURE`` queue without additional
buffers queued to ``OUTPUT`` (e.g. during drain or ``EOS``), because of the
``OUTPUT`` buffers queued in the past whose encoding results are only
available at later time, due to specifics of the encoding process,
* buffers queued to ``OUTPUT`` may not become available to dequeue instantly
after being encoded into a corresponding ``CAPTURE`` buffer, e.g. if the
encoder needs to use the frame as a reference for encoding further frames.
.. note::
To allow matching encoded ``CAPTURE`` buffers with ``OUTPUT`` buffers they
originated from, the client can set the ``timestamp`` field of the
:c:type:`v4l2_buffer` struct when queuing an ``OUTPUT`` buffer. The
``CAPTURE`` buffer(s), which resulted from encoding that ``OUTPUT`` buffer
will have their ``timestamp`` field set to the same value when dequeued.
In addition to the straightforward case of one ``OUTPUT`` buffer producing
one ``CAPTURE`` buffer, the following cases are defined:
* one ``OUTPUT`` buffer generates multiple ``CAPTURE`` buffers: the same
``OUTPUT`` timestamp will be copied to multiple ``CAPTURE`` buffers,
* the encoding order differs from the presentation order (i.e. the
``CAPTURE`` buffers are out-of-order compared to the ``OUTPUT`` buffers):
``CAPTURE`` timestamps will not retain the order of ``OUTPUT`` timestamps.
.. note::
To let the client distinguish between frame types (keyframes, intermediate
frames; the exact list of types depends on the coded format), the
``CAPTURE`` buffers will have corresponding flag bits set in their
:c:type:`v4l2_buffer` struct when dequeued. See the documentation of
:c:type:`v4l2_buffer` and each coded pixel format for exact list of flags
and their meanings.
Should an encoding error occur, it will be reported to the client with the level
of details depending on the encoder capabilities. Specifically:
* the ``CAPTURE`` buffer (if any) that contains the results of the failed encode
operation will be returned with the ``V4L2_BUF_FLAG_ERROR`` flag set,
* if the encoder is able to precisely report the ``OUTPUT`` buffer(s) that triggered
the error, such buffer(s) will be returned with the ``V4L2_BUF_FLAG_ERROR`` flag
set.
.. note::
If a ``CAPTURE`` buffer is too small then it is just returned with the
``V4L2_BUF_FLAG_ERROR`` flag set. More work is needed to detect that this
error occurred because the buffer was too small, and to provide support to
free existing buffers that were too small.
In case of a fatal failure that does not allow the encoding to continue, any
further operations on corresponding encoder file handle will return the -EIO
error code. The client may close the file handle and open a new one, or
alternatively reinitialize the instance by stopping streaming on both queues,
releasing all buffers and performing the Initialization sequence again.
Encoding Parameter Changes
==========================
The client is allowed to use :c:func:`VIDIOC_S_CTRL` to change encoder
parameters at any time. The availability of parameters is encoder-specific
and the client must query the encoder to find the set of available controls.
The ability to change each parameter during encoding is encoder-specific, as
per the standard semantics of the V4L2 control interface. The client may
attempt to set a control during encoding and if the operation fails with the
-EBUSY error code, the ``CAPTURE`` queue needs to be stopped for the
configuration change to be allowed. To do this, it may follow the `Drain`
sequence to avoid losing the already queued/encoded frames.
The timing of parameter updates is encoder-specific, as per the standard
semantics of the V4L2 control interface. If the client needs to apply the
parameters exactly at specific frame, using the Request API
(:ref:`media-request-api`) should be considered, if supported by the encoder.
Drain
=====
To ensure that all the queued ``OUTPUT`` buffers have been processed and the
related ``CAPTURE`` buffers are given to the client, the client must follow the
drain sequence described below. After the drain sequence ends, the client has
received all encoded frames for all ``OUTPUT`` buffers queued before the
sequence was started.
1. Begin the drain sequence by issuing :c:func:`VIDIOC_ENCODER_CMD`.
* **Required fields:**
``cmd``
set to ``V4L2_ENC_CMD_STOP``.
``flags``
set to 0.
``pts``
set to 0.
.. warning::
The sequence can be only initiated if both ``OUTPUT`` and ``CAPTURE``
queues are streaming. For compatibility reasons, the call to
:c:func:`VIDIOC_ENCODER_CMD` will not fail even if any of the queues is
not streaming, but at the same time it will not initiate the `Drain`
sequence and so the steps described below would not be applicable.
2. Any ``OUTPUT`` buffers queued by the client before the
:c:func:`VIDIOC_ENCODER_CMD` was issued will be processed and encoded as
normal. The client must continue to handle both queues independently,
similarly to normal encode operation. This includes:
* queuing and dequeuing ``CAPTURE`` buffers, until a buffer marked with the
``V4L2_BUF_FLAG_LAST`` flag is dequeued,
.. warning::
The last buffer may be empty (with :c:type:`v4l2_buffer`
``bytesused`` = 0) and in that case it must be ignored by the client,
as it does not contain an encoded frame.
.. note::
Any attempt to dequeue more ``CAPTURE`` buffers beyond the buffer
marked with ``V4L2_BUF_FLAG_LAST`` will result in a -EPIPE error from
:c:func:`VIDIOC_DQBUF`.
* dequeuing processed ``OUTPUT`` buffers, until all the buffers queued
before the ``V4L2_ENC_CMD_STOP`` command are dequeued,
* dequeuing the ``V4L2_EVENT_EOS`` event, if the client subscribes to it.
.. note::
For backwards compatibility, the encoder will signal a ``V4L2_EVENT_EOS``
event when the last frame has been encoded and all frames are ready to be
dequeued. It is deprecated behavior and the client must not rely on it.
The ``V4L2_BUF_FLAG_LAST`` buffer flag should be used instead.
3. Once all ``OUTPUT`` buffers queued before the ``V4L2_ENC_CMD_STOP`` call are
dequeued and the last ``CAPTURE`` buffer is dequeued, the encoder is stopped
and it will accept, but not process any newly queued ``OUTPUT`` buffers
until the client issues any of the following operations:
* ``V4L2_ENC_CMD_START`` - the encoder will not be reset and will resume
operation normally, with all the state from before the drain,
* a pair of :c:func:`VIDIOC_STREAMOFF` and :c:func:`VIDIOC_STREAMON` on the
``CAPTURE`` queue - the encoder will be reset (see the `Reset` sequence)
and then resume encoding,
* a pair of :c:func:`VIDIOC_STREAMOFF` and :c:func:`VIDIOC_STREAMON` on the
``OUTPUT`` queue - the encoder will resume operation normally, however any
source frames queued to the ``OUTPUT`` queue between ``V4L2_ENC_CMD_STOP``
and :c:func:`VIDIOC_STREAMOFF` will be discarded.
.. note::
Once the drain sequence is initiated, the client needs to drive it to
completion, as described by the steps above, unless it aborts the process by
issuing :c:func:`VIDIOC_STREAMOFF` on any of the ``OUTPUT`` or ``CAPTURE``
queues. The client is not allowed to issue ``V4L2_ENC_CMD_START`` or
``V4L2_ENC_CMD_STOP`` again while the drain sequence is in progress and they
will fail with -EBUSY error code if attempted.
For reference, handling of various corner cases is described below:
* In case of no buffer in the ``OUTPUT`` queue at the time the
``V4L2_ENC_CMD_STOP`` command was issued, the drain sequence completes
immediately and the encoder returns an empty ``CAPTURE`` buffer with the
``V4L2_BUF_FLAG_LAST`` flag set.
* In case of no buffer in the ``CAPTURE`` queue at the time the drain
sequence completes, the next time the client queues a ``CAPTURE`` buffer
it is returned at once as an empty buffer with the ``V4L2_BUF_FLAG_LAST``
flag set.
* If :c:func:`VIDIOC_STREAMOFF` is called on the ``CAPTURE`` queue in the
middle of the drain sequence, the drain sequence is canceled and all
``CAPTURE`` buffers are implicitly returned to the client.
* If :c:func:`VIDIOC_STREAMOFF` is called on the ``OUTPUT`` queue in the
middle of the drain sequence, the drain sequence completes immediately and
next ``CAPTURE`` buffer will be returned empty with the
``V4L2_BUF_FLAG_LAST`` flag set.
Although not mandatory, the availability of encoder commands may be queried
using :c:func:`VIDIOC_TRY_ENCODER_CMD`.
Reset
=====
The client may want to request the encoder to reinitialize the encoding, so
that the following stream data becomes independent from the stream data
generated before. Depending on the coded format, that may imply that:
* encoded frames produced after the restart must not reference any frames
produced before the stop, e.g. no long term references for H.264/HEVC,
* any headers that must be included in a standalone stream must be produced
again, e.g. SPS and PPS for H.264/HEVC.
This can be achieved by performing the reset sequence.
1. Perform the `Drain` sequence to ensure all the in-flight encoding finishes
and respective buffers are dequeued.
2. Stop streaming on the ``CAPTURE`` queue via :c:func:`VIDIOC_STREAMOFF`. This
will return all currently queued ``CAPTURE`` buffers to the client, without
valid frame data.
3. Start streaming on the ``CAPTURE`` queue via :c:func:`VIDIOC_STREAMON` and
continue with regular encoding sequence. The encoded frames produced into
``CAPTURE`` buffers from now on will contain a standalone stream that can be
decoded without the need for frames encoded before the reset sequence,
starting at the first ``OUTPUT`` buffer queued after issuing the
`V4L2_ENC_CMD_STOP` of the `Drain` sequence.
This sequence may be also used to change encoding parameters for encoders
without the ability to change the parameters on the fly.
Commit Points
=============
Setting formats and allocating buffers triggers changes in the behavior of the
encoder.
1. Setting the format on the ``CAPTURE`` queue may change the set of formats
supported/advertised on the ``OUTPUT`` queue. In particular, it also means
that the ``OUTPUT`` format may be reset and the client must not rely on the
previously set format being preserved.
2. Enumerating formats on the ``OUTPUT`` queue always returns only formats
supported for the current ``CAPTURE`` format.
3. Setting the format on the ``OUTPUT`` queue does not change the list of
formats available on the ``CAPTURE`` queue. An attempt to set the ``OUTPUT``
format that is not supported for the currently selected ``CAPTURE`` format
will result in the encoder adjusting the requested ``OUTPUT`` format to a
supported one.
4. Enumerating formats on the ``CAPTURE`` queue always returns the full set of
supported coded formats, irrespective of the current ``OUTPUT`` format.
5. While buffers are allocated on any of the ``OUTPUT`` or ``CAPTURE`` queues,
the client must not change the format on the ``CAPTURE`` queue. Drivers will
return the -EBUSY error code for any such format change attempt.
To summarize, setting formats and allocation must always start with the
``CAPTURE`` queue and the ``CAPTURE`` queue is the master that governs the
set of supported formats for the ``OUTPUT`` queue.

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

@@ -46,4 +46,5 @@ devices are given in the following sections.
:maxdepth: 1
dev-decoder
dev-encoder
dev-stateless-decoder

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

@@ -51,7 +51,7 @@ other information, the physical address of the framebuffer in the
``base`` field of struct :c:type:`v4l2_framebuffer`.
The framebuffer device ioctl ``FBIOGET_FSCREENINFO`` returns the same
address in the ``smem_start`` field of struct
struct :c:type:`fb_fix_screeninfo`. The ``FBIOGET_FSCREENINFO``
:c:type:`fb_fix_screeninfo`. The ``FBIOGET_FSCREENINFO``
ioctl and struct :c:type:`fb_fix_screeninfo` are defined in
the ``linux/fb.h`` header file.

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

@@ -78,7 +78,7 @@ field of a struct :c:type:`v4l2_format` to
``V4L2_BUF_TYPE_SDR_CAPTURE`` or ``V4L2_BUF_TYPE_SDR_OUTPUT`` and use
the struct :c:type:`v4l2_sdr_format` ``sdr`` member
of the ``fmt`` union as needed per the desired operation. Currently
there is two fields, ``pixelformat`` and ``buffersize``, of struct
there are two fields, ``pixelformat`` and ``buffersize``, of
struct :c:type:`v4l2_sdr_format` which are used.
Content of the ``pixelformat`` is V4L2 FourCC code of the data format.
The ``buffersize`` field is maximum buffer size in bytes required for

4
Documentation/userspace-api/media/v4l/hist-v4l2.rst
View File

@@ -43,7 +43,7 @@ transmission arguments.
1998-09-28: Revamped video standard. Made video controls individually
enumerable.
1998-10-02: The ``id`` field was removed from struct
1998-10-02: The ``id`` field was removed from
struct ``video_standard`` and the color subcarrier fields were
renamed. The :ref:`VIDIOC_QUERYSTD` ioctl was
renamed to :ref:`VIDIOC_ENUMSTD`,
@@ -260,7 +260,7 @@ multiple tuners into account.)
2000-09-18: ``V4L2_BUF_TYPE_VBI`` was added. This may *break
compatibility* as the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctls may fail now if the struct
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctls may fail now if the
struct ``v4l2_fmt`` ``type`` field does not contain
``V4L2_BUF_TYPE_VBI``. In the documentation of the struct
:c:type:`v4l2_vbi_format` ``offset`` field the

28
Documentation/userspace-api/media/v4l/pixfmt-srggb14p.rst
View File

@@ -69,37 +69,37 @@ Each cell is one byte.
B\ :sub:`00low bits 5--0`\ (bits 5--0)
- R\ :sub:`02low bits 3--0`\ (bits 7--4)
- B\ :sub:`02low bits 3--0`\ (bits 7--4)
G\ :sub:`01low bits 5--2`\ (bits 3--0)
- G\ :sub:`03low bits 5--0`\ (bits 7--2)
R\ :sub:`02low bits 5--4`\ (bits 1--0)
B\ :sub:`02low bits 5--4`\ (bits 1--0)
- .. row 2
- start + 7
- G\ :sub:`00high`
- G\ :sub:`10high`
- R\ :sub:`01high`
- R\ :sub:`11high`
- G\ :sub:`02high`
- G\ :sub:`12high`
- R\ :sub:`03high`
- R\ :sub:`13high`
- R\ :sub:`01low bits 1--0`\ (bits 7--6)
- R\ :sub:`11low bits 1--0`\ (bits 7--6)
G\ :sub:`00low bits 5--0`\ (bits 5--0)
G\ :sub:`10low bits 5--0`\ (bits 5--0)
- G\ :sub:`02low bits 3--0`\ (bits 7--4)
- G\ :sub:`12low bits 3--0`\ (bits 7--4)
R\ :sub:`01low bits 5--2`\ (bits 3--0)
R\ :sub:`11low bits 5--2`\ (bits 3--0)
- R\ :sub:`03low bits 5--0`\ (bits 7--2)
- R\ :sub:`13low bits 5--0`\ (bits 7--2)
G\ :sub:`02low bits 5--4`\ (bits 1--0)
G\ :sub:`12low bits 5--4`\ (bits 1--0)
- .. row 3
@@ -117,13 +117,13 @@ Each cell is one byte.
B\ :sub:`20low bits 5--0`\ (bits 5--0)
- R\ :sub:`22low bits 3--0`\ (bits 7--4)
- B\ :sub:`22low bits 3--0`\ (bits 7--4)
G\ :sub:`21low bits 5--2`\ (bits 3--0)
- G\ :sub:`23low bits 5--0`\ (bits 7--2)
R\ :sub:`22low bits 5--4`\ (bits 1--0)
B\ :sub:`22low bits 5--4`\ (bits 1--0)
- .. row 4

5
Documentation/userspace-api/media/v4l/pixfmt-v4l2.rst
View File

@@ -44,6 +44,11 @@ Single-planar format structure
inside the stream, when fed to a stateful mem2mem decoder, the fields
may be zero to rely on the decoder to detect the right values. For more
details see :ref:`decoder` and format descriptions.
For compressed formats on the CAPTURE side of a stateful mem2mem
encoder, the fields must be zero, since the coded size is expected to
be calculated internally by the encoder itself, based on the OUTPUT
side. For more details see :ref:`encoder` and format descriptions.
* - __u32
- ``pixelformat``
- The pixel format or type of compression, set by the application.

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

@@ -63,6 +63,7 @@ Authors, in alphabetical order:
- Figa, Tomasz <tfiga@chromium.org>
- Documented the memory-to-memory decoder interface.
- Documented the memory-to-memory encoder interface.
- H Schimek, Michael <mschimek@gmx.at>
@@ -75,6 +76,7 @@ Authors, in alphabetical order:
- Osciak, Pawel <posciak@chromium.org>
- Documented the memory-to-memory decoder interface.
- Documented the memory-to-memory encoder interface.
- Osciak, Pawel <pawel@osciak.com>

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