Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/display/mipi-dsi-bus.txt- Extension
.txt- Size
- 5818 bytes
- Lines
- 236
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- 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.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
MIPI DSI (Display Serial Interface) busses
==========================================
The MIPI Display Serial Interface specifies a serial bus and a protocol for
communication between a host and up to four peripherals. This document will
define the syntax used to represent a DSI bus in a device tree.
This document describes DSI bus-specific properties only or defines existing
standard properties in the context of the DSI bus.
Each DSI host provides a DSI bus. The DSI host controller's node contains a
set of properties that characterize the bus. Child nodes describe individual
peripherals on that bus.
The following assumes that only a single peripheral is connected to a DSI
host. Experience shows that this is true for the large majority of setups.
DSI host
========
In addition to the standard properties and those defined by the parent bus of
a DSI host, the following properties apply to a node representing a DSI host.
Required properties:
- #address-cells: The number of cells required to represent an address on the
bus. DSI peripherals are addressed using a 2-bit virtual channel number, so
a maximum of 4 devices can be addressed on a single bus. Hence the value of
this property should be 1.
- #size-cells: Should be 0. There are cases where it makes sense to use a
different value here. See below.
Optional properties:
- clock-master: boolean. Should be enabled if the host is being used in
conjunction with another DSI host to drive the same peripheral. Hardware
supporting such a configuration generally requires the data on both the busses
to be driven by the same clock. Only the DSI host instance controlling this
clock should contain this property.
DSI peripheral
==============
Peripherals with DSI as control bus, or no control bus
------------------------------------------------------
Peripherals with the DSI bus as the primary control bus, or peripherals with
no control bus but use the DSI bus to transmit pixel data are represented
as child nodes of the DSI host's node. Properties described here apply to all
DSI peripherals, but individual bindings may want to define additional,
device-specific properties.
Required properties:
- reg: The virtual channel number of a DSI peripheral. Must be in the range
from 0 to 3.
Some DSI peripherals respond to more than a single virtual channel. In that
case two alternative representations can be chosen:
- The reg property can take multiple entries, one for each virtual channel
that the peripheral responds to.
- If the virtual channels that a peripheral responds to are consecutive, the
#size-cells can be set to 1. The first cell of each entry in the reg
property is the number of the first virtual channel and the second cell is
the number of consecutive virtual channels.
Peripherals with a different control bus
----------------------------------------
There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
primary control bus, but are also connected to a DSI bus (mostly for the data
path). Connections between such peripherals and a DSI host can be represented
using the graph bindings [1], [2].
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.