On Tue, Oct 13, 2026, [email protected] wrote: > > + dpu_crtc_count_pending_frame(crtc); > > + > > /* > > * Kickoff real time encoder last as it's the encoder that > > * will do the flush > > */ > > dpu_encoder_kickoff(wb_encoder); > > dpu_encoder_kickoff(rt_encoder); > > Does this code introduce an unbalanced decrement of frame_pending? > > In dpu_crtc_kickoff_clone_mode(), dpu_crtc_count_pending_frame() increments > frame_pending once per CRTC commit. However, the function subsequently kicks > off both wb_encoder and rt_encoder independently. [...] > If multiple clone-mode commits are interleaved, could the second event from an > earlier commit arrive after the next commit sets frame_pending to 1?
Yes, the accounting is unbalanced in clone mode, but it is not introduced by this patch. Without it, dpu_crtc_commit_kickoff() also counts one frame per commit, and both the writeback and the real-time encoder report FRAME_EVENT_DONE (and, on a frame-done timeout, FRAME_EVENT_ERROR) to the CRTC. The patch changes where the frame is counted, not how many times, so clone mode needs a separate fix. The encoder already identifies the writeback encoder of a clone-mode CRTC: dpu_encoder_kickoff() skips its flush when drm_enc->encoder_type == DRM_MODE_ENCODER_VIRTUAL && dpu_enc->cwb_mask. Applying the same test in dpu_encoder_frame_done_callback() and dpu_encoder_frame_done_timeout(), so that only the real-time encoder reports to the CRTC, would keep one event per counted frame. The writeback job is still completed through drm_writeback_signal_completion(). Jessica, does that fit the CWB design? I cannot test this here. dpu_encoder_get_clones() pairs writeback only with DSI encoders, so on X1E80100, where the panel is eDP, no encoder can share a CRTC with writeback and the DRM core rejects such a commit. That also corrects my test notes: this machine does expose a Writeback connector (WB_2); what it cannot do is clone mode. Michael
