From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH 20/22] drm/tilcdc: Nuke preclose hook Date: Wed, 13 Jan 2016 13:25:17 +0200 Message-ID: <5696341D.4050508@ti.com> References: <1452548477-15905-1-git-send-email-daniel.vetter@ffwll.ch> <1452548477-15905-21-git-send-email-daniel.vetter@ffwll.ch> <56950B7B.1030006@ti.com> <20160112151255.GA19130@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0774298323==" Return-path: In-Reply-To: <20160112151255.GA19130@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: Daniel Vetter , Intel Graphics Development , "Sarha, Jyri" , DRI Development , Daniel Vetter List-Id: dri-devel@lists.freedesktop.org --===============0774298323== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7uNU5NE82wV9W1IjRnxe3hPoesnJ699GL" --7uNU5NE82wV9W1IjRnxe3hPoesnJ699GL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/01/16 17:12, Daniel Vetter wrote: > Different approaches to the same problem: >=20 > - omap just unlinks the event from fpriv and still process it normally.= > But then before sending it out it checks whether the fpriv is still > there or not and either sends it, or deletes the event directly. This= > way the vblank_put is always called from the worker/irq handler as pa= rt > of the event processing. >=20 > This is the same approach I implemented in core with this series. >=20 > - tilcdc (and most other drivers) entirely destroy the event in the > preclose hook, which means they must also release any other resources= > acquired as part of that event. Therefore they have the vblank_put he= re. > But the vblank_put is obviously also in the normal event processing > paths, so with the new approach of only unlinking it we can handle th= is > without any special cases in the driver. >=20 > I hope this explains what's going on. Since you're about driver maintai= ner > no. 3 with the same question: Can you pls review the kerneldoc and make= > sure it explains this well? I tried to improve it already a bit after > Laurent's/Thomas' questions. Ok, makes sense. I think the kernel doc is fine. I wasn't able to test tilcdc, as it seems to crash on drm-next at the moment... Need to debug that first. Tomi --7uNU5NE82wV9W1IjRnxe3hPoesnJ699GL 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 iQIcBAEBCAAGBQJWljQdAAoJEPo9qoy8lh71YHcQAK5rzaRvLB/qPH4Mfl2zr/ju IIIqyS+Q59Bc9ZIoVj8RwiZZlHvnpwNJ1zW2VsiBXPknWQtOzbClPVSKxtUmyFNw puTzBHvwoXcMBEZKEgCazO/xVUj6csLIm7sVUD4cLcYDipvrQ6zzafK78LOqS4xk mZ4uJ5PvrlOsKMx6nXZWvA8AL87So/jECtHfKJTq1LpwayjORa29LihH9Tdt0vOe fynqTRd8rGNtOfzsO/J1vjxgPSt3b7WdIPryhsHSokPWl5zVQ4JBWJa0yYwBK0iN k9VE67uAWOZLZU3PS+XrJGoiY4MOUkvrisnE9JX/ltmtFTExabyEYrG0H7IPptni kv1B/hXrxiNq0BGEpCcWWsEJvFj2PoLpdHxWPZxuv+IDSRazSzrsE2nq48Y0mauN z5uD/RC+tqf9w514rAPpO06QhFhoSaJOtFjpGPbv+1cYVOM2iC1HWEzEvNaxvMNi fvsM880Hg1vno6aGHZpraiyOkg4X+xf4OyerEOav+5qPgeejBEikbEecjZ4b+pSh 5poFskv35SBL9aN89rI7xLV9E8iSjNdXNhrr312svnfrAlhMm6goM90fMv+h0Xe+ IO0j3hrKnLHx2C1l2oo+4JZZD6fRo5JmNT2jnhBBBIaY6xVeZoTNLNjnAAIkYttW rCkwEgUUSdWNKuoIu80U =7kZo -----END PGP SIGNATURE----- --7uNU5NE82wV9W1IjRnxe3hPoesnJ699GL-- --===============0774298323== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0774298323==--