From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH 02/33] HACK: drm/omap: always use blocking DMM fill Date: Tue, 23 Feb 2016 15:09:58 +0200 Message-ID: <56CC5A26.3090200@ti.com> References: <1455875288-4370-1-git-send-email-tomi.valkeinen@ti.com> <1455875288-4370-3-git-send-email-tomi.valkeinen@ti.com> <1818041.Py0QKdZPaW@avalon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2011681481==" Return-path: Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5B6756E565 for ; Tue, 23 Feb 2016 13:10:05 +0000 (UTC) In-Reply-To: <1818041.Py0QKdZPaW@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============2011681481== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dio88agIc6x94Ds04KH2gPPUtF6rPd9vj" --dio88agIc6x94Ds04KH2gPPUtF6rPd9vj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/02/16 12:27, Laurent Pinchart wrote: > Hi Tomi, >=20 > Thank you for the patch. >=20 > On Friday 19 February 2016 11:47:37 Tomi Valkeinen wrote: >> The current driver uses non-blocking DMM fill when releasing memory. >> This gives us a small performance increase as we don't have to wait fo= r >> the fill operation to finish. >> >> However, the driver does not have any error handling for non-blocking >> fill. In case of an error, the fill operation may silently fail, leadi= ng >> to leaking DMM engines, which may eventually lead to deadlock if we ru= n >> out of DMM engines. >> >> This patch makes the DMM driver always use blocking fills, so that we >> can catch the errors. A more complex option would be to allow >> non-blocking fills, and implement proper error handling, but that is >> left for the future. >> >> This patch is a HACK, as the proper fix is to either decide to always >> use sync fills and remove all the async related code, or fix the async= >> code. >=20 > Could you capture this in the comment in the source code below ? I'd al= so=20 > replace XXXX with either FIXME or TODO. Yes, the comment was a bit lacking. Here's an updated comment: /* * FIXME * * Asynchronous fill does not work reliably, as the driver does not * handle errors in the async code paths. The fill operation may * silently fail, leading to leaking DMM engines, which may eventually * lead to deadlock if we run out of DMM engines. * * For now, always set 'wait' so that we only use sync fills. Async * fills should be fixed, or alternatively we could decide to only * support sync fills and so the whole async code path could be removed. */ Tomi --dio88agIc6x94Ds04KH2gPPUtF6rPd9vj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAEBCAAGBQJWzFonAAoJEPo9qoy8lh713qYP9jglMuqTezV6NFe547phylFk 5SbaG+9ZoQxpbOh2VdD3npWg3Hu5OEwup16iFuji+TKXw1avfNvkJjocMlC6HuUP HyYGZWarYusaFQCRg7BHOqOqjz1jxNhCjG5SYwtr/UWbrjYvrJ+w9N+otAxcLVEK FVKiEivObwJ2AGiTQygUmaYIovWu5lsknk2/LCatAW5hkF8BAOqd3cCAEpx0qtRA yWB+90kTMwKq7WmdM+lrIEJLO/pIY+0HZXOzFQst7adgkxSHf+8D+GNuao4BVcaM T5F9NXhmAHt796XqerFvQ/7Ch+zvK20bW2rbpn6+b+YTDkUAeqX0/edqL93qrKT7 BCVy3RJ8dGIYz7lQaFXzJ6JIt3VlFdlV7iTgokMQELS3JYQhGFweYQ2m2iCGOA0y Cu3jFaRbM5pa2fuWvmwx2+mV8sknJIWjGY/UxUIxvy+278ZhaH3E03/bHWFZzeCt lc1Rho/eI3uGnGtcgbDEjwWZu/ELmyyyCj5UlzJyxQcztkpq3kljdNns1atvscSp jE0+l3kzmCbsXkp0evquvwQUP9JwrQCaCVbAyfUEDdN1LGFoSXTU+Vf/FL8BcbV5 eiVrPbar+EpqzcOp2RgbYsU2r0UZI2oqAS5hiHMBTh5MoXh0vfxP2lsW0eqcrSMU kQS0mThdNB8w7skWhnU= =kSga -----END PGP SIGNATURE----- --dio88agIc6x94Ds04KH2gPPUtF6rPd9vj-- --===============2011681481== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============2011681481==--