From: Gerd Hoffmann <kraxel@redhat.com>
To: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] qxl: fix framebuffer unpinning
Date: Tue, 19 Sep 2017 17:29:02 +0200 [thread overview]
Message-ID: <1505834942.12708.12.camel@redhat.com> (raw)
In-Reply-To: <87poam7o4f.fsf@dilma.collabora.co.uk>
On Tue, 2017-09-19 at 11:35 -0300, Gabriel Krisman Bertazi wrote:
> Gerd Hoffmann <kraxel@redhat.com> writes:
>
> > qxl_plane_cleanup_fb() unpins the just activated framebuffer
> > instead of the old one. Oops. Fix it.
> >
> > Cc: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
> > Fixes: 1277eed5fecb8830c8cc414ad70c1ef640464bc0
> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > ---
> > drivers/gpu/drm/qxl/qxl_display.c | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> > b/drivers/gpu/drm/qxl/qxl_display.c
> > index e1dd05423e..afbf50d0c0 100644
> > --- a/drivers/gpu/drm/qxl/qxl_display.c
> > +++ b/drivers/gpu/drm/qxl/qxl_display.c
> > @@ -702,14 +702,15 @@ static void qxl_plane_cleanup_fb(struct
> > drm_plane *plane,
> > struct drm_gem_object *obj;
> > struct qxl_bo *user_bo;
> >
> > - if (!plane->state->fb) {
> > - /* we never executed prepare_fb, so there's
> > nothing to
> > + if (!old_state->fb) {
> > + /*
> > + * we never executed prepare_fb, so there's
> > nothing to
> > * unpin.
> > */
> > return;
> > }
> >
> > - obj = to_qxl_framebuffer(plane->state->fb)->obj;
> > + obj = to_qxl_framebuffer(old_state->fb)->obj;
>
> I am not sure about this patch. My idea was to pin/unpin the current
> buffer on prepare/cleanup, and only keep it pinned during the atomic
> commit. This was the goal of 37235451c6990683a8, for instance.
I'm pretty sure the buffer must remain pinned while it is displayed.
> Anyway, if that goal is wrong, I think that, with your change, we
> forget to
> unpin the final plane before removing the device.
"removing the device"? qxl can't be hotplugged ...
Or do you mean "rmmod qxl"?
cheers,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-09-19 15:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-18 7:41 [PATCH] qxl: fix framebuffer unpinning Gerd Hoffmann
2017-09-19 14:35 ` Gabriel Krisman Bertazi
2017-09-19 15:29 ` Gerd Hoffmann [this message]
2017-09-20 3:48 ` Gabriel Krisman Bertazi
2017-09-20 12:17 ` Gerd Hoffmann
2017-09-22 5:03 ` Gabriel Krisman Bertazi
2017-09-22 6:25 ` Gerd Hoffmann
2017-09-22 17:37 ` Gabriel Krisman Bertazi
2017-09-25 7:14 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1505834942.12708.12.camel@redhat.com \
--to=kraxel@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=krisman@collabora.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.