[PATCH] drm/i915: Don't unregister fbdev twice

[PATCH] drm/i915: Don't unregister fbdev twice

[Lukas Wunner]

Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
superfluous because the framebuffer will subsequently be unregistered by
drm_framebuffer_free() when unreferenced in drm_framebuffer_remove().
The call is a leftover, when it was introduced by commit 362063619cf6
("drm: revamp framebuffer cleanup interfaces"), struct intel_framebuffer
was still embedded in struct intel_fbdev rather than being a pointer as
it is today, and drm_framebuffer_remove() wasn't used yet.

As a bonus, the ID of the framebuffer is no longer 0 in the debug log:

Before:
    [   39.680874] [drm:drm_mode_object_unreference] OBJ ID: 0 (3)
    [   39.680878] [drm:drm_mode_object_unreference] OBJ ID: 0 (2)
    [   39.680884] [drm:drm_mode_object_unreference] OBJ ID: 0 (1)

After:
    [  102.504649] [drm:drm_mode_object_unreference] OBJ ID: 45 (3)
    [  102.504651] [drm:drm_mode_object_unreference] OBJ ID: 45 (2)
    [  102.504654] [drm:drm_mode_object_unreference] OBJ ID: 45 (1)

Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 drivers/gpu/drm/i915/intel_fbdev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index ef8e676..4c7ea46 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -552,8 +552,6 @@ static void intel_fbdev_destroy(struct drm_device *dev,
 	drm_fb_helper_fini(&ifbdev->helper);
 
 	if (ifbdev->fb) {
-		drm_framebuffer_unregister_private(&ifbdev->fb->base);
-
 		mutex_lock(&dev->struct_mutex);
 		intel_unpin_fb_obj(&ifbdev->fb->base, BIT(DRM_ROTATE_0));
 		mutex_unlock(&dev->struct_mutex);
-- 
2.8.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Ro.CI.BAT: success for drm/i915: Don't unregister fbdev twice

[Patchwork]

== Series Details ==

Series: drm/i915: Don't unregister fbdev twice
URL   : https://patchwork.freedesktop.org/series/8443/
State : success

== Summary ==

Series 8443v1 drm/i915: Don't unregister fbdev twice
http://patchwork.freedesktop.org/api/1.0/series/8443/revisions/1/mbox

Test gem_exec_flush:
        Subgroup basic-batch-kernel-default-cmd:
                fail       -> PASS       (ro-byt-n2820)

fi-bdw-i7-5557u  total:102  pass:93   dwarn:0   dfail:0   fail:0   skip:8  
fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:10 
ro-bdw-i7-5600u  total:183  pass:154  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050     total:208  pass:167  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820     total:208  pass:169  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:208  pass:185  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:183  pass:161  dwarn:0   dfail:0   fail:0   skip:21 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:183  pass:154  dwarn:0   dfail:0   fail:0   skip:28 
ro-snb-i7-2620M  total:183  pass:151  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot
ro-ivb2-i7-3770 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1138/

131a54b drm-intel-nightly: 2016y-06m-07d-19h-46m-33s UTC integration manifest
1be3f6d drm/i915: Don't unregister fbdev twice

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Don't unregister fbdev twice

[Daniel Vetter]

On Wed, Jun 08, 2016 at 01:15:22PM +0200, Lukas Wunner wrote:
> Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
> superfluous because the framebuffer will subsequently be unregistered by
> drm_framebuffer_free() when unreferenced in drm_framebuffer_remove().
> The call is a leftover, when it was introduced by commit 362063619cf6
> ("drm: revamp framebuffer cleanup interfaces"), struct intel_framebuffer
> was still embedded in struct intel_fbdev rather than being a pointer as
> it is today, and drm_framebuffer_remove() wasn't used yet.
> 
> As a bonus, the ID of the framebuffer is no longer 0 in the debug log:
> 
> Before:
>     [   39.680874] [drm:drm_mode_object_unreference] OBJ ID: 0 (3)
>     [   39.680878] [drm:drm_mode_object_unreference] OBJ ID: 0 (2)
>     [   39.680884] [drm:drm_mode_object_unreference] OBJ ID: 0 (1)
> 
> After:
>     [  102.504649] [drm:drm_mode_object_unreference] OBJ ID: 45 (3)
>     [  102.504651] [drm:drm_mode_object_unreference] OBJ ID: 45 (2)
>     [  102.504654] [drm:drm_mode_object_unreference] OBJ ID: 45 (1)
> 
> Signed-off-by: Lukas Wunner <lukas@wunner.de>

Hm yeah. But there's a pile of that particaluar cargo-culting copied all
over the place, would be really good to audit all callers of
unregister_private and fix them all up. A few older drivers still embed
the fbdev fb, but most don't but still use the unregister_private +
cleanup combo.

Nitpick in your subject: s/fbdev/fbdev's fb/

Cheers, Daniel

> ---
>  drivers/gpu/drm/i915/intel_fbdev.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
> index ef8e676..4c7ea46 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -552,8 +552,6 @@ static void intel_fbdev_destroy(struct drm_device *dev,
>  	drm_fb_helper_fini(&ifbdev->helper);
>  
>  	if (ifbdev->fb) {
> -		drm_framebuffer_unregister_private(&ifbdev->fb->base);
> -
>  		mutex_lock(&dev->struct_mutex);
>  		intel_unpin_fb_obj(&ifbdev->fb->base, BIT(DRM_ROTATE_0));
>  		mutex_unlock(&dev->struct_mutex);
> -- 
> 2.8.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Don't unregister fbdev twice

[Lukas Wunner]

On Wed, Jun 08, 2016 at 02:09:40PM +0200, Daniel Vetter wrote:
> On Wed, Jun 08, 2016 at 01:15:22PM +0200, Lukas Wunner wrote:
> > Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
> > superfluous because the framebuffer will subsequently be unregistered by
> > drm_framebuffer_free() when unreferenced in drm_framebuffer_remove().
> > The call is a leftover, when it was introduced by commit 362063619cf6
> > ("drm: revamp framebuffer cleanup interfaces"), struct intel_framebuffer
> > was still embedded in struct intel_fbdev rather than being a pointer as
> > it is today, and drm_framebuffer_remove() wasn't used yet.
> > 
> > As a bonus, the ID of the framebuffer is no longer 0 in the debug log:
> > 
> > Before:
> >     [   39.680874] [drm:drm_mode_object_unreference] OBJ ID: 0 (3)
> >     [   39.680878] [drm:drm_mode_object_unreference] OBJ ID: 0 (2)
> >     [   39.680884] [drm:drm_mode_object_unreference] OBJ ID: 0 (1)
> > 
> > After:
> >     [  102.504649] [drm:drm_mode_object_unreference] OBJ ID: 45 (3)
> >     [  102.504651] [drm:drm_mode_object_unreference] OBJ ID: 45 (2)
> >     [  102.504654] [drm:drm_mode_object_unreference] OBJ ID: 45 (1)
> > 
> > Signed-off-by: Lukas Wunner <lukas@wunner.de>
> 
> Hm yeah. But there's a pile of that particaluar cargo-culting copied all
> over the place, would be really good to audit all callers of
> unregister_private and fix them all up. A few older drivers still embed
> the fbdev fb, but most don't but still use the unregister_private +
> cleanup combo.

Yes, I noticed that but i915 was the only one that I could actually test,
the others I can only compile test. So fixing those up requires very
careful examination and takes more time, but I'll keep it on my todo list.


> Nitpick in your subject: s/fbdev/fbdev's fb/

Right, should I post a v2 or are you going to fix it up if/when merging?

Thanks,

Lukas

> 
> > ---
> >  drivers/gpu/drm/i915/intel_fbdev.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
> > index ef8e676..4c7ea46 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -552,8 +552,6 @@ static void intel_fbdev_destroy(struct drm_device *dev,
> >  	drm_fb_helper_fini(&ifbdev->helper);
> >  
> >  	if (ifbdev->fb) {
> > -		drm_framebuffer_unregister_private(&ifbdev->fb->base);
> > -
> >  		mutex_lock(&dev->struct_mutex);
> >  		intel_unpin_fb_obj(&ifbdev->fb->base, BIT(DRM_ROTATE_0));
> >  		mutex_unlock(&dev->struct_mutex);
> > -- 
> > 2.8.1
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Don't unregister fbdev twice

[Daniel Vetter]

On Wed, Jun 08, 2016 at 07:03:02PM +0200, Lukas Wunner wrote:
> On Wed, Jun 08, 2016 at 02:09:40PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 08, 2016 at 01:15:22PM +0200, Lukas Wunner wrote:
> > > Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
> > > superfluous because the framebuffer will subsequently be unregistered by
> > > drm_framebuffer_free() when unreferenced in drm_framebuffer_remove().
> > > The call is a leftover, when it was introduced by commit 362063619cf6
> > > ("drm: revamp framebuffer cleanup interfaces"), struct intel_framebuffer
> > > was still embedded in struct intel_fbdev rather than being a pointer as
> > > it is today, and drm_framebuffer_remove() wasn't used yet.
> > > 
> > > As a bonus, the ID of the framebuffer is no longer 0 in the debug log:
> > > 
> > > Before:
> > >     [   39.680874] [drm:drm_mode_object_unreference] OBJ ID: 0 (3)
> > >     [   39.680878] [drm:drm_mode_object_unreference] OBJ ID: 0 (2)
> > >     [   39.680884] [drm:drm_mode_object_unreference] OBJ ID: 0 (1)
> > > 
> > > After:
> > >     [  102.504649] [drm:drm_mode_object_unreference] OBJ ID: 45 (3)
> > >     [  102.504651] [drm:drm_mode_object_unreference] OBJ ID: 45 (2)
> > >     [  102.504654] [drm:drm_mode_object_unreference] OBJ ID: 45 (1)
> > > 
> > > Signed-off-by: Lukas Wunner <lukas@wunner.de>
> > 
> > Hm yeah. But there's a pile of that particaluar cargo-culting copied all
> > over the place, would be really good to audit all callers of
> > unregister_private and fix them all up. A few older drivers still embed
> > the fbdev fb, but most don't but still use the unregister_private +
> > cleanup combo.
> 
> Yes, I noticed that but i915 was the only one that I could actually test,
> the others I can only compile test. So fixing those up requires very
> careful examination and takes more time, but I'll keep it on my todo list.
> 
> 
> > Nitpick in your subject: s/fbdev/fbdev's fb/
> 
> Right, should I post a v2 or are you going to fix it up if/when merging?

Fixed up while applying - I just waited for CI to get around (and then
w/e). Going through the other drivers to nuke the cargo-culting would
still be awesome.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx