DSI reads on the Raspberry Pi 4 (vc4, DSI1) can fail in two ways that the caller cannot handle:
- A peripheral that detected an error answers a read with an Acknowledge and Error Report. vc4 copies its two bytes into the caller's buffer and returns success, so the error bits look like register contents (patch 1). - After a read whose bus turnaround times out, every following DSI transfer times out as well, until the display is switched off and on (patch 2). Patch 3 serializes host transfers, so that the recovery cannot reset the block under a concurrent transfer. These patches do not prevent the timeouts. With video running, vc4 does not keep commands within vertical blanking, so a read can still collide with active video and time out. That is a separate issue; this series makes such failures visible to the caller and recoverable without a modeset. Tested on a Raspberry Pi 4 with a 2-lane video mode panel at 120 Hz, using a backport of this series to the Raspberry Pi 6.18 kernel and a panel driver that retries failed reads up to 8 times: 499 of 500 reads with video running and 1000 of 1000 with video stopped returned the expected data, with no lock-up. Without the series, the first timeout left DSI unusable. Compile-tested on drm-misc-next (arm64 defconfig, DRM_VC4=m, W=1), each patch on its own. Changes in v2: - Patch 2: restore the registers in the same order as pre_enable, and call synchronize_irq() before the reset (Sashiko review) - Patch 3: new, serialize host transfers (Sashiko review) - Link to v1: https://lore.kernel.org/r/[email protected] Henry Zhang (3): drm/vc4: dsi: Don't return error reports as read data drm/vc4: dsi: Recover from a timed-out transfer drm/vc4: dsi: Serialize host transfers drivers/gpu/drm/vc4/vc4_dsi.c | 145 ++++++++++++++++++++++++++++++++-- 1 file changed, 138 insertions(+), 7 deletions(-) base-commit: e6bb593b800813788dc16179d1305747ff974d00 -- 2.47.3
