Hi,
On Mon, Nov 16, 2020 at 09:52:16PM +0100, Daniel Vetter wrote:
> On Mon, Nov 16, 2020 at 09:04:35PM +0100, Thomas Zimmermann wrote:
> > If the damage handling fails, restore the damage area. The next invocation
> > of the damage worker will then perform the update.
> >
> > Signed-off-by: Thomas Zimmermann <tzimmerm...@suse.de>
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 23 ++++++++++++++++++++---
> > 1 file changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 2e1a335bafd2..13b65dad2ca8 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -431,11 +431,28 @@ static void drm_fb_helper_damage_work(struct
> > work_struct *work)
> > if (helper->buffer) {
> > ret = drm_fb_helper_damage_blit(helper, &clip_copy);
> > if (ret)
> > - return;
> > + goto err;
> > }
> >
> > - if (helper->fb->funcs->dirty)
> > - helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
> > + if (helper->fb->funcs->dirty) {
> > + ret = helper->fb->funcs->dirty(helper->fb, NULL, 0, 0,
> > &clip_copy, 1);
> > + if (ret)
> > + goto err;
>
> I think this is unexpected enough that we should put some drm error
> printing here I think.Note, that the dirty framebuffer routines are used by the framebuffer console. Printing warnings means another line in the framebuffer console and thus another call to the dirty routines. Assuming the problem does not get solved magically the system will be busy printing warnings forever. I have been through that fun while working on the OMAP DSI command mode patches and I suggest to only do ratelimited logging in the code related to damage tracking. -- Sebastian
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
