MIPI DSI Video Mode vs Command Mode: Choose by Host and Panel Constraints

The MIPI DSI video mode vs command mode choice starts with the framebuffer. Two panels can share a size, resolution and connector and still require different DSI architectures. One expects a continuous pixel stream and has only a line buffer; the other holds the frame in its own GRAM and waits for the host to update regions. Choosing between video mode and command mode is therefore not a preference about latency or power. It is a compatibility decision from framebuffer location to a frozen interface specification. This comparison builds that decision from the host and panel constraints, including burst timing, tearing-effect requirements and the restrictions that rule a mode out.

Which MIPI DSI video mode vs command mode constraints are non-negotiable?

Panel GRAM and host support decide the mode.

Video mode needs a continuous pixel stream; command mode needs panel GRAM and TE handling, so the host and the panel both constrain the choice.

Video mode assumes that the host can produce a continuous stream with valid video timing for as long as the display is on. The panel may buffer a line, but it does not hold a full frame. If the stream stops, the image stops. Command mode assumes the panel has enough GRAM to hold the frame and can refresh it autonomously, while the host sends commands and pixel writes and may sleep between updates.

The non-negotiable constraints follow from those assumptions. The panel must have the GRAM and the command set for command mode, and it must expose a tearing-effect signal or another way to synchronize updates. The host must have a DSI controller that supports the selected mode, enough lanes and rate for the pixel stream, and the ability to generate the required timing. A host that supports only video timing cannot use command mode even if the panel is ideal for it.

Command mode can idle the host and link between updates; video mode keeps the link active. That difference is a consequence of the architecture, not a reason to choose a mode the hardware cannot support.

Where is the framebuffer in each architecture?

The framebuffer sits in the host or in the panel.

In video mode the host holds the image and streams every frame; in command mode panel GRAM holds it and the host updates only changed regions.

In a video-mode design, the host’s display controller reads the framebuffer and sends pixels with blanking and sync timing. The panel reconstructs the image from the stream. The host owns the frame rate, the timing and the content; the panel owns the optical response. If the host stops, the image stops, and if the host sends a different timing, the panel must be able to accept it.

In a command-mode design, the panel’s GRAM is the framebuffer of record. The host writes pixels into a region and the panel continues to scan that region until it is written again. The host can update a small area, leave the rest untouched and sleep. This is why command mode is attractive for static user interfaces, watches and low-power instruments, and why it demands careful address-window and TE handling.

The location of the framebuffer determines the debug path. A video-mode image fault is usually a host timing or stream problem. A command-mode image fault may be a write that landed in the wrong window, a missed TE, a partial update that never completed, or a panel that never received the command. The Linux DRM panel and bridge helpers describe the prepare, enable and disable responsibilities that sit around both architectures.

How do burst and non-burst timing change the link budget?

Burst timing raises peak rate; non-burst spreads the load.

Burst sends a line at high speed then idles, raising peak lane rate; non-burst spreads pixels across the line and keeps the link busier longer.

In burst mode, the host sends the pixels of a line as a compact packet and then returns to low power or idles until the next line. The average bandwidth is the same, but the instantaneous rate is higher because the same pixels are delivered in less time. That higher peak rate affects the lane rate, the PHY margin and the emissions profile. It can also make the link easier to share with command traffic in the blanking interval, because the active period is shorter.

In non-burst mode, the pixels are spread across the line with blanking inserted between packets. The peak rate is lower and the link is active for longer. This can be easier on the PHY and the power delivery, but it leaves less room for other traffic and may be less efficient at the protocol level because more packets carry the same payload.

The link budget must state which mode is assumed. Using the average pixel rate without the burst peak can under-size the lane rate; a generic overhead factor can over-size it. The right input is the actual packetization.

When does the tearing-effect signal become necessary?

TE is necessary when the host writes to panel GRAM.

A command-mode partial update must land in the panel’s blanking window; without TE a write can overtake the scan and produce a visible seam.

A command-mode panel scans its GRAM continuously. If the host writes to a region while the panel is scanning that region, the top of the region may show the new data and the bottom the old data, producing a visible tear. The tearing-effect signal tells the host when the scan is at a safe point, usually the start of the frame or the start of the vertical blanking interval, so the write can be placed ahead of the scan.

TE is not needed for every update. A small status icon in a corner may be written quickly enough that the risk is negligible, and a static screen may not be updated at all. The need grows with the size of the update, the link time required to send it and the speed of the scan. A full-screen update on a slow link almost always needs synchronization; a small region on a fast link may not.

The TE mode matters as well. A pulse at frame start gives one window per frame; a pulse at frame start and line start gives more granularity but more interrupt load. The panel datasheet defines which modes exist, and the host driver must be configured for the same one.

How do low-power transitions affect update latency?

LP transitions save power but add wake latency.

Leaving high-speed mode between updates saves link power, but each wake must re-enter HS, settle the clock and deliver the first packet, adding latency.

A command-mode link can return to low-power state between updates, which is one of its main power advantages. The transition is not free. The host must drive the required LP sequence, wait for the PHY to settle, enter high speed and deliver the first packet. The panel may also need a wake time before it accepts commands or updates its GRAM. The sum of those delays limits how frequently the host can update and how quickly the interface can respond to an input event.

For a user interface, the relevant latency is from the event to the visible change, not from the command to the bus. That includes the host’s decision, the wake, the write and the panel’s scan. A design that measures only the bus transaction will underestimate the perceived delay. A design that keeps the link in high speed avoids the wake but pays continuous power. The rail that feeds the panel may also need a controlled rise, as with a load switch such as the TPS22918, and that rise is separate from the DSI wake time.

The trade-off should be measured, not assumed. Record the wake time, the first-packet time and the visible update time for the actual panel and host. Then decide whether the link should stay in high speed during interaction and drop to low power only after an idle period.

Which host-controller restrictions rule out a mode?

A host that lacks command mode or GRAM rules out the option.

Some controllers support only video timing, cap packet size or cannot generate TE interrupts; one missing capability removes the mode regardless of the panel.

Host controllers differ in ways that are not always visible in a feature list. One may support video mode only; another may support command mode but not the packet size needed for a full-line write; another may support both but lack a TE input or an interrupt path. Some controllers limit the number of lanes, the maximum lane rate or the pixel formats they can generate. A bridge adds another set of limits, including its own buffer size and configuration interface; a device such as the SN65DSI83 converts DSI to LVDS and carries its own packet and timing limits, so it adds a row to the capability check rather than removing one.

The check should be explicit. List the mode, the maximum lane rate, the supported pixel formats, the packet size, the TE input, the command path and the low-power behaviour. Then mark which of them the host, the bridge and the panel each support. A mode is available only when every item in the chain supports it.

The ST AN4860 DSI host application note is an example of a host document that defines modes, packet configuration and timing for specific MCU families. Its limits cannot be transferred to another controller without checking that controller’s documentation.

What should a mode-comparison validation table contain?

The table must compare both sides, not just the panel.

A validation table lists host and panel capability, mode, lane rate, timing, TE configuration, measured power and latency, and the resulting decision.

The table is the record that prevents a later argument about why a mode was chosen. Each row should be a capability or a measurement, and the columns should show the host, the panel, the bridge where present, the result and the source of the requirement. A row that cannot be filled is an open question, not a pass.

Include the measured power and latency, not only the datasheet claims. A command-mode link that wakes slowly may consume more average power than a video-mode link that stays active, depending on the update rate. The only way to know is to measure both in the intended workload. Include the test conditions: resolution, refresh, update rate, brightness and temperature.

Mode validation record by signal and state

Signal or rail	Power state	Trigger or capture point	Observed behavior	Source of acceptance limit
DSI clock lane	HS and LP	Clock lane at panel connector	Continuous or gated clock behavior	Panel drawing, host datasheet
DSI data lanes	HS and LP	Lane pairs at connector	Burst packet structure and idle periods	Host packet configuration
TE output	Active	Panel TE pin	Frame-start or frame-plus-line pulse	Panel command set
Panel GRAM	Active	Command interface	Address window and retained image	Panel GRAM size and command set
Host framebuffer	Active	Display controller	Continuous scan-out or regional update	Host controller documentation
Backlight enable	Off to on	Driver enable pin	Delay after first valid frame	Panel drawing, driver datasheet

How should the selected mode be frozen in the interface specification?

Freeze mode, timing, TE and initialization in one document.

The interface specification should state mode, lane count and rate, pixel format, timing, TE behaviour, initialization revision and power sequence in one document.

A mode decision that lives only in a driver commit is not a specification. It can be changed by the next developer who finds a simpler path, and the change may invalidate the validation record. The interface specification should state the selected mode and the constraints that made it necessary, so a future change is assessed rather than discovered.

Include the lane count and rate, the pixel format and packing, the video timing or command-window behaviour, the TE mode and polarity, the initialization sequence revision and the power sequence. Add the measured latency and power from the validation table, and the conditions under which they were measured. If a bridge is used, include its configuration and firmware revision.

The DRM KMS documentation describes the mode and pipeline responsibilities that the driver must keep consistent with the frozen specification. The specification should also say what is not supported. If command mode is not available on this host, state it. If the panel has GRAM but the host cannot generate TE, state that the partial-update path is not qualified. Explicit exclusions are as valuable as inclusions, because they stop a future project from assuming a capability that was never validated. The LVDS versus MIPI DSI comparison covers the neighbouring interface choice; this page owns the video versus command mode freeze.