From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Keith Packard" Subject: Re: [PATCH 2/5] drm/vblank: Fix data type width for drm_crtc_arm_vblank_event() Date: Tue, 30 Jan 2018 22:49:07 -0800 Message-ID: <87d11qldzw.fsf@keithp.com> References: <20180112215707.3084-1-dhinakaran.pandiyan@intel.com> <20180112215707.3084-2-dhinakaran.pandiyan@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0353737460==" Return-path: In-Reply-To: <20180112215707.3084-2-dhinakaran.pandiyan@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: intel-gfx@lists.freedesktop.org Cc: Michel =?utf-8?Q?D=C3=A4nzer?= , Dhinakaran Pandiyan , dri-devel@lists.freedesktop.org, rodrigo.vivi@intel.com List-Id: intel-gfx@lists.freedesktop.org --===============0353737460== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dhinakaran Pandiyan writes: > Now that drm_vblank_count() returns all bits of the vblank count, update > drm_crtc_arm_vblank_event() so that it queues the correct sequence. > Otherwise, this leads to prolonged waits for a vblank sequence when the > current count is >=3D2^32. The summary for this patch is incorrect; the function being fixed is drm_crtc_accurate_vblank_event. And, I'm afraid you've uncovered a rabbit hole here -- there are a couple of users of this function outside of the core, including i915 in a couple of places and nouveau. We should at least review the whole call graph starting here and make sure it does what we think it should. Thanks for finding these bugs! =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlpxZuMACgkQ2yIaaQAA ABFkJg//ed/tdbvWjGA7NAUUm55VJuzeeVqmDyRixnQRGky2g37MhTIbaF4VgV0Q O5LXpeXq/sCkB3gGWY++b/hivGm5NhozVH3KSvY9aJRVQ6BZ7M70mXzb2ue8J8hE PpWD0Fo5KTLSiAtJkS20/CfR37GygRtpdcfHNTezzqzNhM4HGYeA/uPTa+MrClnI 1OfCzf3OcbqH1HvS3STQTf7cSuZHU6XOmmVeaGRO8mDjZPJjt7zbN1oW3585SZAq jOSZIdhUGKQ3WZKIzwpMVoxZFEFYU/mimvQLIOkZU0NjcTdQ3aiPvtGe1lnEjjVH SjMlCH6I1Hb0PB93OyAEUrEDrD4oBh9BmntkYNIYd8EYyPPM/pdGGUUUiRK0DUzO u3Ohhzf3f0D9CriHFtCi/P3xG3kKnySQs1mAEMx9IScvNslU1ncevWunalow1CbW q/cs8KQSlLoA1O8EDYFJnzheUGNTQihp0wE97+Kru8TMvFssOvr8DlL8KdE23F06 ab6rGYxYUNvr8TMP2V4jsVBVcxwYQJDzQ8aY/zSRSr50zBXL4aJVTrUaGABRQrhy nySDulHDDcVYTyTuLqlqYTzAVq7GpWdp/k8UtYhOunX3uCe5r0G+5cY9iXNkl252 c7tbCHm4TKtv+2rQMQ+coCansF9QGN+YTMa+UuAJUbsM2h2Fkc0= =yC1J -----END PGP SIGNATURE----- --=-=-=-- --===============0353737460== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============0353737460==--