From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Keith Packard" Subject: Re: [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences. Date: Sat, 03 Feb 2018 00:14:48 -0800 Message-ID: <877eruh4lj.fsf@keithp.com> References: <20180203051302.9974-1-dhinakaran.pandiyan@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1099944021==" Return-path: In-Reply-To: <20180203051302.9974-1-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?= , "Pandiyan, Dhinakaran" , dri-devel@lists.freedesktop.org, Rodrigo Vivi List-Id: dri-devel@lists.freedesktop.org --===============1099944021== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dhinakaran Pandiyan writes: > From: "Pandiyan, Dhinakaran" > > drm_vblank_count() has an u32 type returning what is a 64-bit vblank coun= t. > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user > space requested vblank sequence using this clipped 32-bit count(when the > value is >=3D 2^32) as reference, the requested sequence remains a 32-bit > value and gets queued like that. However, the code that checks if the > requested sequence has passed compares this against the 64-bit vblank > count. For patches 1-7: Reviewed-by: Keith Packard =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlp1b3gACgkQ2yIaaQAA ABFeew/9FgF9+CaKDQt2q6zJGdZa/BAspcX4V57QVpKH/GTiE/6XlKE+Q/KUZ+z8 a0CoqA/lK6ei1M/l83EjY4G1V6gEH+8hsIzmdJQhr3D6032rHHx0/gaV4DynBo25 24QClY7o2WW9nHxRPvx9nbx4WAecM90fm9kVPChuiadZiM9Gl3DyFyP1dYq+3Twt GdyT95u2qdEgv4RAZUquOpgN/u7gP20gBD5Gz8Asa1/lg6NkyjwLEaz7E1qH5IwD XqCJiP7TGGy2Bm2HK/AnDVrHPWnTItcCuG4/MtKoq46UfhPLvRdhb62+D3MP8+wE Qi9555lBbXp5KKc/F2M7FFTnD06tYxaPRxwdhOGIMdkn0lL6X2rqR+EQ/SFYk2wN NSEZnyvbm8OFfpv+Z8v5XDASC59NtE3QrpLCOIFMRU5CZqZD1su4G4MoiEfKJTHV M8vW/xh0aqmQNuZYbv8tpRiSJz44nVyezjjQRWuN3k8eQpDsEgWkVarQ4PemAgnL hh5KGlicdTGWT59qy3WQ4VvBFSLaDNGkLQLY/qioNJPHxBGncAIivgLNegG8IVyb D1D+kEzrZRm8UuufMieQe0VRb9/c24SjzR1AZXpZmL/Je6GFiLU1XfPNgp2W0nZ1 1KHbvZe43uYjbHEEA5QGd72e9XU2kjSl6EahowW0toacgdXS1PU= =r+Vs -----END PGP SIGNATURE----- --=-=-=-- --===============1099944021== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============1099944021==--