Re: Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

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

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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 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