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 2). An HSTX timeout can be reported as a success as well (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 5). Patch 3 rate-limits the error interrupt messages, which patch 5 would otherwise turn into an interrupt storm. Patch 4 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: 45000 writes, 582 timed out; each timeout was followed by a reset and restore, and the following writes went through. The DSI interrupt rate stayed at 147/s. - 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: 245 panel inits succeeded; 5 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 v4: - Patch 1: new, set the transfer result before completing the transfer on an HSTX timeout (found while reviewing v3). - Patch 2: add Dave's Reviewed-by (unchanged from v2 1/3). - Patch 5: keep the interrupt handler out with disable_irq() around the reset instead of synchronize_irq() before it: an error interrupt could still run during the reset (Sashiko review). - Link to v3: https://lore.kernel.org/r/[email protected] 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 3 (new in v3): rate-limit the error interrupt messages. - Patch 4 (was v2 3/3): moved before the recovery, and also taken in the bridge pre_enable, enable, disable and post_disable callbacks. - Patch 5 (was v2 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 (5): drm/vc4: dsi: Set the transfer result before completing the transfer 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 | 180 ++++++++++++++++++++++++++++++++-- 1 file changed, 170 insertions(+), 10 deletions(-) base-commit: 650385a0fd0ea6475a17d39a20ec90470c7a4c67 -- 2.47.3
