Re: Possible fb ref count issue with drm_plane_force_disable()

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

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

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 #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