On 11/04/14 09:57, Archit Taneja wrote: > Yes, I meant our driver should call drm_framebuffer_remove() only when > we are know that the fb reference omapdrm had taken(the one in > update_pin), has a corresponding fb unref called(in unpin_worker). > > Isn't that something omapdrm should take care of? Yes, we could do it, and it's probably something we should do. I haven't looked at it, so I don't know how easy or difficult it is to make sure the fb won't be used after we think it has been disabled. But even so, the drm_framebuffer_remove() seems to be designed to handle the case where the fb is still in use, but it's failing. >> I forgot to mention that if I comment out the unref in >> drm_plane_force_disable(), the ref counts match and all looks fine. And >> also that I didn't see this issue with 3.14. > > That's strange. I guess there must be an extra unref happening somewhere > in the newer commits. Did you try a diff of drm code between the 2 > kernels? :) Not yet. I'm guessing that it's about the plane changes. There was already one issue with omapdrm, where the crtc calls plane->destroy on the crtc's primary plane. With the latest changes, the all the planes, including the primary planes, are destroyed automatically, so the crtc's destroy call is not needed (and causes a crash). Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
