Re: Possible fb ref count issue with drm_plane_force_disable()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux