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