From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: Possible fb ref count issue with drm_plane_force_disable() Date: Fri, 11 Apr 2014 09:40:37 +0300 Message-ID: <53478E65.6090305@ti.com> References: <534684E8.9000203@ti.com> <53478C42.5080502@ti.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0166190153==" Return-path: Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by gabe.freedesktop.org (Postfix) with ESMTP id DFE7D6ECF0 for ; Thu, 10 Apr 2014 23:40:43 -0700 (PDT) In-Reply-To: <53478C42.5080502@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Archit Taneja Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org --===============0166190153== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OucxumEk89iR3i0oAGBPocf331pwoI1O6" --OucxumEk89iR3i0oAGBPocf331pwoI1O6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/04/14 09:31, Archit Taneja wrote: > Hi, >=20 > On Thursday 10 April 2014 05:17 PM, Tomi Valkeinen wrote: >> Hi, >> >> I've been debugging omapdrm issues on top of the latest drm mainline >> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborti= ng >> a drm application, or unloading the modules. >> >> The setup is very basic, just a single crtc with the crtc's primary >> plane. >> >> What seems to happen is: >> >> - App is started >> >> - fb is created, and taken into use by omapdrm. omapdrm takes a ref to= >> the fb. >> >> - the app is starts to shut down >> >> - drm_framebuffer_remove is called >=20 > Does drm_framebuffer_remove get called when we abort the application, o= r > unload omapdrm, or both? Both. When we abort an app, drm_framebuffer_remove gets called for the fb that the app created. When we unload omapdrm, it gets called for the main fb, used for fb console. >> - fb->refcount.refcount > 1, so it goes to disable stuff >> >> - drm_plane_force_disable is called for the primary plane >=20 > Maybe we need to make sure that this func is called only when our drive= r > has unreferenced it. In that case, we would probably need to flush our > queue and disable interrupts(so that we don't queue more work). Hmm, sorry, call which func, unreferenced what? =3D) Do you mean we should call drm_framebuffer_remove() only if fb->refcount.refcount =3D=3D 1. That should be possible, and would probab= ly remove the issue, but it would just be going around the actual problem. >> - drm_plane_force_disable does plane->disable_plane, which on omapdrm >> puts stuff on a workqueue as plane cannot be disabled immediately >> >> - drm_plane_force_disable calls __drm_framebuffer_unreference() >> >> - at the end of drm_framebuffer_remove(), there's >> drm_framebuffer_unreference, which causes ref count to go to zero, and= >> the fb to be destroyed >> >> - a bit later, the queued work is ran, which does >> drm_framebuffer_unreference(), and ref count goes to -1. Here omapdrm = is >> removing the ref that had been taken in the beginning. >> >> >> So the explicit unref done by drm_plane_force_disable() seems a bit ou= t >> of place. I can't figure out which drm_framebuffer_reference() would b= e >> the matching one for the unref done by drm_plane_force_disable(). >> >> Any ideas what ref is that? Or is the __drm_framebuffer_unreference() >> extra in drm_plane_force_disable()? >=20 >=20 > I can't get the corresponding reference for it either. But I can count = 3 > of them when you run fbcon with drm's fb helper. >=20 > - One ref is taken in the drm_framebuffer_init called from > omap_fbdev_create. >=20 > - fbcon will call fb_set_par, which calls drm_fb_helper_set_par, that > seems to take a refernce to the fb in the end. This one is not called for a normal app, as there's no fbdev framebuffer for it. Note that the funcs I mention deal with drm framebuffer, which is not the fbdev framebuffer (confusing =3D). fbdev fb is only used for the "root" framebuffer. And, of course, fbdev fb uses the drm fb functionality. > - drm_crtc_helper_set_config() calls the omadrm specific mode_set > drm_crtc_funcs, which eventually calls a drm_framebuffer_reference in > update_pin(). Yep. 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. Tomi --OucxumEk89iR3i0oAGBPocf331pwoI1O6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJTR45pAAoJEPo9qoy8lh71Oi8P/ij667/WIuV3pSnqL6Cxp2oN 488V3ZSCka7KvK7alSbaBOIPCaErccWDtgCIUuo/ijLQNKIvD7krcB2qodI1k1xb RqBXS11YCCBMxTw3Z8WY+uSJpnflMSt+Yyo+I4KsnoL7+6K6Q7AIkUPA4bNtl9iG Pek/eqmxkoAsrNWtorX5fZULtANqAHkBSoD2PlNhtH6l2JMcFGwV1E6V9VQ0mGSW cIDYj3A2/pupBEcuk/NH71K2UWJWn/ht+4hvUWY02tF4C43OMyGWdZK9BQF+DH0O oNvCEGvL/inkXLWZNYoxS3bJTPF5GwMJ4DVbMCFM5W03DsswCSC6FXVEckCj3t+b KUopc6WifTtFDN8M4IbRwYfWMi05DjvBEzAtyYVCgXzHxcX8Z9p6X8uoAfeuRpaE IDdV8VEr+/jS8JkfYJ6IFPZnjLLcM4/XmEb+19K/+tfqaVB/ElrQGsa8btRuSs8I 9B8EJPicOh644kRnY+ZVkSkshuCdi6Q7+xbagBpjgpqYCdKUUBHVypPazpnPbUPw Ra5okDTg3Iur/lRaYX9kiTWXWucrZqE5XgwYfGM5oF/7w5Gg9r7EAlKInXcQuOLD BK3/tZGQ1lPIPO4q206vvvJup80muI4liKrpTQZ56CXy4Tz3hd1VDs+wSa6Jo9XN cz++aTJCnPaU8IjFkMl9 =pidN -----END PGP SIGNATURE----- --OucxumEk89iR3i0oAGBPocf331pwoI1O6-- --===============0166190153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0166190153==--