Re: [PATCH 17/17] drm/tegra: fb: Do not destroy framebuffer

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1804 bytes --]

On Mon, Nov 03, 2014 at 10:53:42AM +0100, Daniel Vetter wrote:
> On Mon, Nov 03, 2014 at 10:27:48AM +0100, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > Drop a reference instead of directly calling the framebuffer .destroy()
> > callback at fbdev free time. This is necessary to make sure the object
> > isn't destroyed if anyone else still has a reference.
> > 
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> >  drivers/gpu/drm/tegra/fb.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
> > index c5fa3c4b2ed5..17a29971a7ee 100644
> > --- a/drivers/gpu/drm/tegra/fb.c
> > +++ b/drivers/gpu/drm/tegra/fb.c
> > @@ -355,7 +355,7 @@ static void tegra_fbdev_free(struct tegra_fbdev *fbdev)
> >  
> >  	if (fbdev->fb) {
> >  		drm_framebuffer_unregister_private(&fbdev->fb->base);
> > -		tegra_fb_destroy(&fbdev->fb->base);
> > +		drm_framebuffer_unreference(&fbdev->fb->base);
> 
> Yeah this is better since you have a free-standing fb pointer. I think
> most kms drivers copied this stuff from i915, which just embedded the
> framebuffer. And then calling unref obviously is a bad idea since the
> kfree will blow up.
> 
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I just noticed that drm_framebuffer_remove() is actually more
appropriate here. Just unreferencing will trigger the WARN_ON in
drm_mode_config_cleanup(). Removing the framebuffer also has the
advantage that any users are forcibly disabled, which gets rid of
some annoying IOMMU faults.

Does the Reviewed-by still apply if I do this on top:

-		drm_framebuffer_unreference(&fbdev->fb->base);
+		drm_framebuffer_remove(&fbdev->fb->base);

?

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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