Re: [PATCH] drm/msm/dpu: clear pending flush state before physical cleanup

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] dpu_hw_ctl_clear_pending_flush() fails to clear pending_periph_flush_mask, leaving stale peripheral flush state across encoder teardowns.
- [High] Sleeping function usleep_range() is called from display driver atomic contexts during encoder cleanup.
--

commit 8f92b7c700308d037e1db8696d21fde498d38560
Author: Saim Shujah <saimzst@gmail.com>

drm/msm/dpu: clear pending flush state before physical cleanup

Hardware can consume an active-frame CTL flush while the cached software
pending-flush mask retains the submitted bits. The patch clears the cached
pending-flush bookkeeping before constructing the teardown state.

> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 1f20695f81e35..45189b6076bc4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2263,6 +2263,7 @@ void dpu_encoder_helper_phys_cleanup(struct dpu_encoder_phys *phys_enc)
>  
>  	dpu_enc = to_dpu_encoder_virt(phys_enc->parent);
>  
> +	ctl->ops.clear_pending_flush(ctl);

[Severity: High]
This isn't a bug introduced by this patch, but does dpu_hw_ctl_clear_pending_flush()
leave stale peripheral flush state across encoder teardowns?

In drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c:dpu_hw_ctl_clear_pending_flush():

	ctx->pending_flush_mask = 0x0;
	ctx->pending_intf_flush_mask = 0;
	ctx->pending_wb_flush_mask = 0;
	ctx->pending_cwb_flush_mask = 0;
	ctx->pending_merge_3d_flush_mask = 0;
	ctx->pending_dsc_flush_mask = 0;
	ctx->pending_cdm_flush_mask = 0;

	memset(ctx->pending_dspp_flush_mask, 0,
		sizeof(ctx->pending_dspp_flush_mask));

The function clears most software state caches, but ctx->pending_periph_flush_mask
is missed.

Because pending_periph_flush_mask is omitted from the clear operation, any
peripheral flush bits set from the previous active frame remain in the software
cache. When the encoder is later re-enabled or flushed, this stale mask could
be inadvertently flushed to the CTL_PERIPH_FLUSH hardware register, potentially
causing unexpected hardware states or hangs.

>  	ctl->ops.reset(ctl);

[Severity: High]
This is a pre-existing issue, but does this hardware cleanup execute a sleeping
polling path while in an atomic context?

dpu_encoder_helper_phys_cleanup() is called from the encoder atomic disable
callback. ctl->ops.reset(ctl) resolves to dpu_hw_ctl_reset_control(), which
polls the hardware and calls usleep_range():

drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c:dpu_hw_ctl_poll_reset_status():

		if (status)
			usleep_range(20, 50);

Calling sleeping functions like usleep_range() from atomic context paths in
display drivers can cause kernel warnings, system instability, and potential
deadlocks.

>  
>  	dpu_encoder_helper_reset_mixers(phys_enc);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826182459.1506522-1-saimzst@gmail.com?part=1