Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/e1cde621/attachment-0001.sig>