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

[Thierry Reding]

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 at 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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141104/8a9bfc0b/attachment.sig>