[PATCH] drm/msm: Avoid dirtyfb stalls on video mode displays

[Dmitry Baryshkov]

On 19/02/2022 22:39, Rob Clark wrote:
> From: Rob Clark <robdclark at chromium.org>
> 
> Someone on IRC once asked an innocent enough sounding question:  Why
> with xf86-video-modesetting is es2gears limited at 120fps.
> 
> So I broke out the perfetto tracing mesa MR and took a look.  It turns
> out the problem was drm_atomic_helper_dirtyfb(), which would end up
> waiting for vblank.. es2gears would rapidly push two frames to Xorg,
> which would blit them to screen and in idle hook (I assume) call the
> DIRTYFB ioctl.  Which in turn would do an atomic update to flush the
> dirty rects, which would stall until the next vblank.  And then the
> whole process would repeat.
> 
> But this is a bit silly, we only need dirtyfb for command mode DSI
> panels.  So lets just skip it otherwise.
> 
> Signed-off-by: Rob Clark <robdclark at chromium.org>
> ---
>   drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 13 +++++
>   drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h  |  9 ++++
>   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  1 +
>   drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |  9 ++++
>   drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c  |  1 +
>   drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.h  |  1 +
>   drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  8 +++
>   drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |  1 +
>   drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h  |  1 +
>   drivers/gpu/drm/msm/msm_fb.c              | 64 ++++++++++++++++++++++-
>   drivers/gpu/drm/msm/msm_kms.h             |  2 +
>   11 files changed, 109 insertions(+), 1 deletion(-)
> 

I have checked your previous dirtyfb patch (and corresponding discussion).

I'm not fond of the idea of acquiring locks, computing the value, then 
releasing the locks and reacquiring the locks again. I understand the 
original needs_dirtyfb approach was frowned upon. Do we have a chance of 
introducing drm_atomic_helper_dirtyfb_unlocked()? Which would perform 
all the steps of the orignal helper, but without locks acquirement (and 
state allocation/freeing)?

[skipped]

> diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
> index 4d34df5354e0..1b0648baeae2 100644
> --- a/drivers/gpu/drm/msm/msm_fb.c
> +++ b/drivers/gpu/drm/msm/msm_fb.c
> @@ -24,10 +24,72 @@ struct msm_framebuffer {
>   static struct drm_framebuffer *msm_framebuffer_init(struct drm_device *dev,
>   		const struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
>   
> +static int msm_framebuffer_dirtyfb(struct drm_framebuffer *fb,
> +				   struct drm_file *file_priv, unsigned int flags,
> +				   unsigned int color, struct drm_clip_rect *clips,
> +				   unsigned int num_clips)
> +{
> +	struct msm_drm_private *priv = fb->dev->dev_private;
> +	struct drm_modeset_acquire_ctx ctx;
> +	struct drm_plane *plane;
> +	bool needs_flush = false;
> +	int ret = 0;
> +
> +	/*
> +	 * When called from ioctl, we are interruptible, but not when called
> +	 * internally (ie. defio worker)
> +	 */
> +	drm_modeset_acquire_init(&ctx,
> +		file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0);
> +
> +retry:
> +	drm_for_each_plane(plane, fb->dev) {
> +		struct drm_plane_state *plane_state;
> +		struct drm_crtc *crtc;
> +
> +		ret = drm_modeset_lock(&plane->mutex, &ctx);
> +		if (ret)
> +			goto out;
> +
> +		if (plane->state->fb != fb) {
> +			drm_modeset_unlock(&plane->mutex);
> +			continue;
> +		}
> +
> +		crtc = plane->state->crtc;
> +
> +		ret = drm_modeset_lock(&crtc->mutex, &ctx);
> +		if (ret)
> +			goto out;
> +
> +		if (priv->kms->funcs->needs_dirtyfb(crtc)) {
> +			needs_flush = true;
> +			break;
> +		}
> +	}
> +
> +out:
> +	if (ret == -EDEADLK) {
> +		ret = drm_modeset_backoff(&ctx);
> +		if (!ret)
> +			goto retry;
> +	}
> +
> +	drm_modeset_drop_locks(&ctx);
> +	drm_modeset_acquire_fini(&ctx);
> +
> +	if (needs_flush) {

This bit triggers my paranoia. The driver computes the value with the 
locks being held and then performs some action depending on the computed 
value after releasing the locks.

I'd prefer to acquire modesetting locks for all the planes (and allocate 
atomic state), check if the dirtyfb processing is needed, then call 
drm_atomic_helper_dirtyfb_unlocked() withith the same locks section.

> +		ret = drm_atomic_helper_dirtyfb(fb, file_priv, flags,
> +						color, clips, num_clips);
> +	}
> +
> +	return ret;
> +}
> +
>   static const struct drm_framebuffer_funcs msm_framebuffer_funcs = {
>   	.create_handle = drm_gem_fb_create_handle,
>   	.destroy = drm_gem_fb_destroy,
> -	.dirty = drm_atomic_helper_dirtyfb,
> +	.dirty = msm_framebuffer_dirtyfb,
>   };
>   
>   #ifdef CONFIG_DEBUG_FS
> diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
> index 2a4f0526cb98..eb870d499d1e 100644
> --- a/drivers/gpu/drm/msm/msm_kms.h
> +++ b/drivers/gpu/drm/msm/msm_kms.h
> @@ -117,6 +117,8 @@ struct msm_kms_funcs {
>   			struct drm_encoder *encoder,
>   			struct drm_encoder *slave_encoder,
>   			bool is_cmd_mode);
> +	bool (*needs_dirtyfb)(struct drm_crtc *crtc);
> +
>   	/* cleanup: */
>   	void (*destroy)(struct msm_kms *kms);
>   


-- 
With best wishes
Dmitry