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 4). Patch 2 rate-limits the error interrupt messages, which patch 4 would otherwise turn into an interrupt storm. Patch 3 serializes host transfers against each other and against the bridge callbacks, so that the recovery cannot reset the block under a transfer or while it is being configured. These patches do not prevent the timeouts. With video running, vc4 does not keep commands within vertical blanking, so a command 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 (DSI1, 2-lane video mode panel) with the same changes backported to the Raspberry Pi 6.18 kernel: - 5 minutes of generic long writes from 4 extra threads with video running: 40394 writes, 583 timed out; each timeout was followed by a reset and restore, and the following writes went through. The DSI interrupt rate stayed at 131/s, with one error message logged. - 50 display off/on cycles with 2 writer threads running (the case that locked up v2): no lock-up, no warning. - 250 display off/on cycles without extra traffic: 248 panel inits succeeded; 2 failed because the data lanes did not reach LP-11 after power-up, which this series does not address. Reads were tested with these patches plus a change, not part of this series, that stops video while a command is sent: 2000 of 2000 reads returned the expected data. Compile-tested on drm-misc-next (arm64 defconfig, DRM_VC4=m, W=1), each patch on its own. Changes in v3: - v2 is not safe; please don't apply it. Its recovery keeps the block usable after a timeout, and a peripheral that leaves the data lanes in a bad state then raises the "data lane 0 sequence" error interrupt tens of thousands of times per second. Printing each one starved a Raspberry Pi 4 until it had to be reset. - Patch 2: new, rate-limit the error interrupt messages. - Patch 3 (was 3/3): moved before the recovery, and also taken in the bridge pre_enable, enable, disable and post_disable callbacks. - Patch 4 (was 2/3): only recover while the block is enabled, and mask the interrupts while the block and its AFE are in reset. - Link to v2: https://lore.kernel.org/r/[email protected] 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 (4): drm/vc4: dsi: Don't return error reports as read data drm/vc4: dsi: Rate-limit error interrupt messages drm/vc4: dsi: Serialize host transfers drm/vc4: dsi: Recover from a timed-out transfer drivers/gpu/drm/vc4/vc4_dsi.c | 172 ++++++++++++++++++++++++++++++++-- 1 file changed, 163 insertions(+), 9 deletions(-) base-commit: 650385a0fd0ea6475a17d39a20ec90470c7a4c67 -- 2.47.3
