MIPI DSI Tearing Effect Signal: Coordinate Partial Updates Without Assuming VSync

A partial update that looks clean in one orientation can tear in another, and the driver may still be waiting for a vertical-sync event that the panel never promised. A MIPI DSI tearing effect signal is not a generic VSync. It is a panel-defined output with a mode, a polarity and a relationship to the scan. This guide treats TE as a timing contract: what it synchronizes, how scan and update direction interact, how to measure the host’s latency, and what belongs in the driver acceptance checklist.

What must the MIPI DSI tearing effect signal synchronize?

TE synchronizes the host write to the panel’s scan.

TE marks a point in the panel’s frame, and the host uses it to place a GRAM write where the scan will not read the region while it is updated.

A command-mode panel scans its GRAM continuously, independent of the host. If the host writes to a region while the panel is scanning that region, the display can show part of the old frame and part of the new one. The tearing effect signal gives the host a reference point: the start of a frame, or the start of a frame and a line, so the host can start the write at a time when the scan is at the top of the region or has passed it.

The signal does not make the write instantaneous. It defines a window. The host must still deliver the pixels before the scan reaches the updated region, which means the link rate, the packet overhead, the update area and the host latency all matter. TE only tells the host when the window opens; the rest of the design determines whether the write fits.

The MIPI DSI specification defines the protocol and command set; the panel’s TE behaviour is defined in its own command table. The signal also does not guarantee that the panel and host agree on the frame. If the TE mode is wrong, or the polarity is inverted, the host may start the write at the end of the window rather than the beginning. That is why the mode and polarity belong in the interface specification.

How do panel scan direction and update direction interact?

Scan direction and update direction must agree.

A panel scanned top to bottom and a host writing bottom to top can both be correct yet produce a seam, so check rotation and mirror together.

A panel can scan from top to bottom or from bottom to top, depending on its gate driver and configuration. The host writes pixels in a coordinate system that may be rotated or mirrored by the application, the graphics library or the driver. Each of those transformations is individually correct; together they can produce a mismatch between the region being written and the region being scanned.

The symptom is characteristic. A seam appears at the boundary of the updated region, and the old and new content are swapped in a way that follows the scan direction. Rotating the display in software can move the seam or make it disappear, which is a clue that the direction is wrong rather than the timing. A full-screen update may hide the problem because the whole frame changes at once; a partial update exposes it.

Record the panel scan direction, the host’s rotation setting and the address-window coordinates in the same document. Test a partial rectangle near the top and near the bottom of the panel in each supported orientation. If the seam moves with the rectangle, the direction is consistent; if it moves with the orientation, the transform is the suspect.

Which TE modes does the actual controller support?

Confirm TE mode and polarity in the panel datasheet.

Some controllers pulse at frame start, some at frame start and line start, and some allow polarity selection; a driver for one mode mis-times the other.

A panel may offer a tearing-effect output that pulses once per frame, or once per frame plus once per line, and it may allow the polarity to be inverted. The modes are not interchangeable. A driver that expects a frame-start pulse but receives a line pulse will trigger on every line, which can flood the interrupt and start writes at the wrong point. A driver that expects an active-high pulse and receives active-low will trigger on the wrong edge.

Read the panel’s command set and the host’s TE input configuration together. Confirm which mode is enabled, what the pulse means and whether the polarity is configurable. Record the setting in the driver and in the interface specification, because a panel revision or a firmware update can change the default.

The host side matters as well, and the ST AN4860 host note documents DSI configuration for specific STM32 families. Some controllers have a dedicated TE input with edge detection; others route it through a GPIO with a configurable interrupt. The latency and the debounce behaviour differ. The mode is only useful if the host can observe it with the required timing.

How should host interrupt latency be measured?

Measure from TE edge to the first write, not to the ISR.

The relevant latency runs from the TE edge to the first pixel packet reaching the panel, so measure GPIO, ISR entry, write start and first packet together.

An interrupt timestamp is not the visible update time. The chain includes the GPIO edge, the interrupt controller, the ISR entry, the driver’s decision, the start of the DSI write and the panel’s receipt of the first pixel. Each stage adds delay, and the total determines whether the write lands inside the window.

Measure the chain with a GPIO toggle at ISR entry and at write start, or with a bus trace that shows the first packet. Put the TE edge, the GPIO toggle and the first packet on the same time base. The difference between the TE edge and the first packet is the latency that matters; the difference between the TE edge and the ISR is only one part of it.

Repeat the measurement under load. A busy system may delay the interrupt or the write, and the margin that exists at idle may disappear when the application is rendering or the CPU is handling another peripheral.

When can an update overrun the available window?

An update overruns when the write exceeds the window.

The window is set by blanking and effective link throughput; if pixels, overhead or host latency exceed it, the write runs into the active scan and tears.

The available window is the time the panel spends outside the region being updated, plus the blanking that follows the TE pulse. For a full-screen update, the window is essentially the vertical blanking interval. For a smaller region, the window is larger, because the scan takes time to reach that region. The write must finish before the scan arrives.

Estimate the write time from the number of pixels, the pixel format, the lane rate and the packet overhead. Then add the host latency measured above. If the total exceeds the window, the update will overrun. Remedies include reducing the update area, increasing the lane rate, splitting the update into smaller regions or changing the TE mode to get a finer window.

The estimate is only a starting point. Measure the actual first-packet and last-packet times on the bus and compare them with the panel’s scan. A write that appears to fit in theory may overrun because of a long interrupt or a fragmented packet sequence.

Which traces distinguish tearing from link corruption?

A clean seam means timing; random errors mean the link.

Tearing gives a straight boundary at the update edge; link corruption gives scattered pixel errors, CRC or ECC reports, or a frame that ignores the boundary.

Tearing is a spatial pattern. The old and new content meet at a straight boundary that follows the update region or the scan line. The boundary moves when the update timing changes and disappears when the update is synchronized. The pixels on each side are correct; the problem is the moment at which they were written.

Link corruption is different. It produces scattered pixel errors, colour shifts, missing blocks or a corrupted frame that does not respect the update boundary. The host may report CRC or ECC errors, or the panel may show a pattern that changes with cable movement. A link that trains but has marginal margin can produce errors that look like tearing at first glance, especially when the update is large.

Capture both the TE signal and the DSI data lanes. If the error boundary aligns with the TE edge and the data is clean, the cause is timing. If the data shows packet errors or the boundary does not align, the cause is the link. The distinction determines whether to change the update policy or the physical layer.

How should partial-update stress patterns be constructed?

Use moving edges and partial rectangles at both ends.

A vertical bar crossing the seam, rectangles at the top and bottom, and a full-screen colour change at different rates expose overrun and direction errors.

A good stress pattern makes the failure visible without requiring instrumentation. A vertical bar that moves across the screen crosses the update boundary and shows a tear as a horizontal offset. A rectangle at the top of the panel and another at the bottom test the scan-direction assumption. A full-screen colour change exercises the largest write and the shortest window. Alternating frames with a one-pixel horizontal line test the smallest update and the interrupt overhead.

Run the patterns at the product’s refresh rate and at the extremes of its update rate. A slow update may fit easily; a fast update may overrun. Run them in every supported orientation, because a rotation can change the direction relationship. Run them with the system under load, because the latency measured at idle may not hold.

Record the pattern, the update area, the refresh rate, the orientation and the observed result. The DRM panel and bridge helpers describe the enable and disable path around these tests; the stress pattern belongs to the panel driver’s validation, not to the application.

What TE assumptions belong in the driver acceptance checklist?

The checklist pins TE mode, polarity, direction and window.

Acceptance should record TE source, mode and polarity, scan and update direction, measured latency, maximum update area and behaviour without TE.

The checklist should state which TE mode the panel is configured for, which edge the driver triggers on, and how the polarity is set. It should record the panel scan direction and the host’s rotation and mirror settings, because those determine whether the update region matches the scan. It should include the measured latency from TE edge to first packet and the maximum update area that fits the window at the product’s refresh rate.

It should also state what happens when TE is absent or late. A driver that waits forever for an interrupt can leave the display frozen; a driver that falls back to a timer can tear. The fallback policy is part of the acceptance, not an implementation detail. Record the timeout, the fallback and the diagnostic that is logged.

The table below is the minimum record for a TE validation. It is a template, not a set of limits; the limits come from the panel command set and the host controller documentation.

TE synchronization evidence record

Signal or rail	Power state	Trigger or capture point	Observed behavior	Source of acceptance limit
TE output	Active	Panel TE pin	Pulse mode, polarity and period	Panel command set
Host TE input	Active	GPIO or dedicated input	Edge detection and interrupt latency	Host controller datasheet
DSI data lanes	HS	Panel connector	First and last packet relative to TE	Host packet configuration
Panel scan	Active	Optical observation or TE line mode	Scan direction and update boundary	Panel drawing
Backlight enable	On	Driver enable pin	Visibility of the updated region	Panel drawing
Reset	Asserted to released	Panel reset pin	TE behaviour after reinitialization	Panel drawing

The SN65DSI83 datasheet is an example of a bridge with its own timing and enable behaviour; a bridge in the path can delay or reshape the TE relationship, so it belongs in the measurement. The DRM KMS documentation covers the pipeline and mode responsibilities that the driver must keep consistent.