Documentation/devicetree/bindings/media/video-interfaces.yaml

Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/media/video-interfaces.yaml

File Facts

System
Linux kernel
Corpus path
Documentation/devicetree/bindings/media/video-interfaces.yaml
Extension
.yaml
Size
9102 bytes
Lines
242
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: configuration, schema, or hardware description
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/video-interfaces.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Common Properties for Video Receiver and Transmitter Interface Endpoints

maintainers:
  - Sakari Ailus <sakari.ailus@linux.intel.com>
  - Laurent Pinchart <laurent.pinchart@ideasonboard.com>

description: |
  Video data pipelines usually consist of external devices, e.g. camera sensors,
  controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
  video DMA engines and video data processors.

  SoC internal blocks are described by DT nodes, placed similarly to other SoC
  blocks.  External devices are represented as child nodes of their respective
  bus controller nodes, e.g. I2C.

  Data interfaces on all video devices are described by their child 'port' nodes.
  Configuration of a port depends on other devices participating in the data
  transfer and is described by 'endpoint' subnodes.

  device {
      ...
      ports {
          #address-cells = <1>;
          #size-cells = <0>;

          port@0 {
              ...
              endpoint@0 { ... };
              endpoint@1 { ... };
          };
          port@1 { ... };
      };
  };

  If a port can be configured to work with more than one remote device on the same
  bus, an 'endpoint' child node must be provided for each of them.  If more than
  one port is present in a device node or there is more than one endpoint at a
  port, or port node needs to be associated with a selected hardware interface,
  a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
  used.

  All 'port' nodes can be grouped under optional 'ports' node, which allows to
  specify #address-cells, #size-cells properties independently for the 'port'
  and 'endpoint' nodes and any child device nodes a device might have.

  Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
  phandles.  An endpoint subnode of a device contains all properties needed for
  configuration of this device for data exchange with other device.  In most
  cases properties at the peer 'endpoint' nodes will be identical, however they
  might need to be different when there is any signal modifications on the bus
  between two devices, e.g. there are logic signal inverters on the lines.

  It is allowed for multiple endpoints at a port to be active simultaneously,
  where supported by a device.  For example, in case where a data interface of
  a device is partitioned into multiple data busses, e.g. 16-bit input port
  divided into two separate ITU-R BT.656 8-bit busses.  In such case bus-width
  and data-shift properties can be used to assign physical data lines to each
  endpoint node (logical bus).

  Documenting bindings for devices
  --------------------------------

  All required and optional bindings the device supports shall be explicitly
  documented in device DT binding documentation. This also includes port and

Annotation

Implementation Notes