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 10:03:05 +0300 Message-ID: <534793A9.6060807@ti.com> References: <534684E8.9000203@ti.com> <53478C42.5080502@ti.com> <53478E65.6090305@ti.com> <53479270.6070501@ti.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1244651006==" Return-path: Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by gabe.freedesktop.org (Postfix) with ESMTP id 348706ECEF for ; Fri, 11 Apr 2014 00:03:08 -0700 (PDT) In-Reply-To: <53479270.6070501@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 --===============1244651006== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2vHHvQWroRFxhjoWWKqlQVG1FeI289iep" --2vHHvQWroRFxhjoWWKqlQVG1FeI289iep Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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). >=20 > 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. An= d >> also that I didn't see this issue with 3.14. >=20 > That's strange. I guess there must be an extra unref happening somewher= e > 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 --2vHHvQWroRFxhjoWWKqlQVG1FeI289iep 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) iQIcBAEBAgAGBQJTR5OpAAoJEPo9qoy8lh71JZgQAKTbPk8DbDex32KHZxqli5B2 bzAPzR2nCgsOxMYZLWYupovgtm72l+R810rIqWKC7dBd+/8C/6n3bTZcvC4a6I7D lswsiNRNUYqjo5z4AQeyIBAXcMUjliHCneUOIMZrWS0p/5ytN7Cn3wYkMsP3Bl59 yE1WtwbfXbySobAddaQXtTwg/Zx2IS3f4/vyGG4uZqDsxhDn9tgdpVorkhTPc+Rn a/7lnOrro1LMmk1LSD1dX6LyTYA2OpnhXEvjeEztZmM7OfsDV+ZgEA17o/QEK1C/ Y5u80htD2uyeI00vBz0qd2nGBdZIJZTVN/q06dlI3p5bBdvjSPVQlgZjdTd1Y/Ev TAi+n8MjVR1iAcgxlewwnVOVniXPkuw+rgBwAGcHWwIPt31A8a/RWd9evGwzCN0V kCm6R4KLYYKoewHO1P/8OStfzMMQhGWKmSQ14eaGnXSkoRFINggDQo5JJlUGF7N0 8894G4VE/gDw6xPxfRda/7DoNPks7zXgabuD0/cApPyKUghmqe02MoYVFB7M103K +6BfePtWQraXZc6ojK9VSMorGjMdgAVSmejmKpkUQsBKfqDBnZ8+K/3zHrqDKMwt n1iE3mrfIRN5H7dZcrUyRqO1L0VqjJSFS/+sF3TtvlZ58zwrcVR4uw16d2oBIB/6 +L/pU8IPtwfbeRKI2vGn =IasP -----END PGP SIGNATURE----- --2vHHvQWroRFxhjoWWKqlQVG1FeI289iep-- --===============1244651006== 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 --===============1244651006==--