On Mon, Sep 09, 2019 at 04:06:32PM +0200, Thomas Zimmermann wrote:
> Before updating the display from the console's shadow buffer, the dirty
> worker now waits for vblank. This allows several screen updates to pile
> up and acts as a rate limiter.
> 
> Signed-off-by: Thomas Zimmermann <tzimmerm...@suse.de>
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index a7ba5b4902d6..017e2f6bd1b9 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -402,8 +402,20 @@ static void drm_fb_helper_dirty_work(struct work_struct 
> *work)
>                                                   dirty_work);
>       struct drm_clip_rect *clip = &helper->dirty_clip;
>       struct drm_clip_rect clip_copy;
> +     struct drm_crtc *crtc;
>       unsigned long flags;
>       void *vaddr;
> +     int ret;
> +
> +     /* rate-limit update frequency */
> +     mutex_lock(&helper->lock);
> +     crtc = helper->client.modesets[0].crtc;
> +     ret = drm_crtc_vblank_get(crtc);
> +     if (!ret) {
> +             drm_crtc_wait_one_vblank(crtc);
> +             drm_crtc_vblank_put(crtc);
> +     }
> +     mutex_unlock(&helper->lock);

Hmm, not sure it is the best plan to sleep for a while in the worker,
especially while holding the lock.

What does the lock protect against here?  Accessing
helper->client.modesets?  If so then you can unlock before going to
sleep in drm_crtc_wait_one_vblank() I think.

cheers,
  Gerd

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to