Re: Possible fb ref count issue with drm_plane_force_disable()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 15/04/14 13:10, Rob Clark wrote:

> so, what triggers this is that previously drm_framebuffer_remove() did
> not process private planes.  But now the fb shows up attached to a
> plane as well, the crtc's primary plane.
> 
> I suspect there is some way in omap_crtc that I must have assumed the
> ref the crtc held to the fb was sufficient for the plane to hold the
> same ref.  Which is no longer the case.  So somewhere between
> omap_crtc and it's primary plane, there now needs to be an extra level
> of ref/unref.  So ref should have gone up to 5.

I still quite lost here... Looking at the non-primary plane's fb ref
counting, some drivers add and remove refs to fb in
plane->plane_update(). But not all.

For omapdrm, update_plane takes a ref, but I'm not quite sure who frees
that ref. Nothing in omap_plane.c seems to do that.

Maybe the ref taken in omapdrm's update_plane is the "same" one that
should be taken for the primary plane also. But I'm not sure where that
should be taken, and if I do take the ref, then I guess it's freed
somewhere else than in omapdrm.

Taking and releasing refs in totally different places is really bad
practice =).

 Tomi


Attachment: signature.asc
Description: OpenPGP digital signature

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

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux