On Thu, Sep 03, 2026 at 10:39:22PM +0800, Jun Nie wrote: > Jun Nie <[email protected]> 于2026年9月3日周四 22:30写道： > > > > There is a spurious timeout error message under the following reproduction > > steps: > > 1. Run "modetest -M msm -r" and press CTRL+Z to pause it. > > 2. Run "while true; do rtcwake -m mem -s 3 -v; sleep 2; done" > > > > Resulting error message: > > [ 124.018206] [drm:dpu_encoder_virt_atomic_disable:1425] [dpu error]enc35 > > timeout pending > > > > dpu_crtc_commit_kickoff() calls dpu_encoder_kickoff() to set frame busy > > bits, and then arms the frame done timer. If the frame done IRQ fires > > between these two steps, the IRQ handler clears the busy bits before the > > timer is armed. As a result, the timer runs with busy bits already cleared > > and is never cancelled by subsequent IRQ handlers, leading to a false > > timeout warning. > > > > Delete the pending timer when all busy bits are cleared in the frame done > > callback to prevent false timeouts. > > > > Another option is to wrap the enc_spinlock lock/unlock pair in dpu_encoder.c > and expose it to dpu_crtc.c to make the sequence of dpu_encoder_kickoff() > and dpu_encoder_start_frame_done_timer() atomic against the IRQ handler. > However, this breaks encoder self-containment to some extent. Furthermore, > initial testing revealed a deadlock involving additional locks beyond > dpu_enc->enc_spinlock.
The patch you posted has an issue of the atomic value being updated in a non-atomic way. However I think it's not a correct solution. I'd just delete the if from dpu_encoder_virt_atomic_disable() and always delete the timer. This also would allow us to delete frame_done_timeout_ms, simplifying the code. > > - Jun -- With best wishes Dmitry
