From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH 2/2] drm/lima: driver for ARM Mali4xx GPUs Date: Thu, 07 Feb 2019 11:38:47 -0800 Message-ID: <87wombmlrs.fsf@anholt.net> References: <20190206131457.1072-1-yuq825@gmail.com> <20190206131457.1072-3-yuq825@gmail.com> <87va1wsp4x.fsf@anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1730222635==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Qiang Yu Cc: Marek Vasut , Simon Shields , lima@lists.freedesktop.org, Neil Armstrong , Maxime Ripard , David Airlie , dri-devel , Vasily Khoruzhick , Andreas Baierl , Sean Paul , Erico Nunes List-Id: dri-devel@lists.freedesktop.org --===============1730222635== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Qiang Yu writes: > On Thu, Feb 7, 2019 at 3:17 AM Eric Anholt wrote: >> >> Qiang Yu writes: >> > +int lima_gem_wait(struct drm_file *file, u32 handle, u32 op, u64 timeout_ns) >> > +{ >> > + bool write = op & LIMA_GEM_WAIT_WRITE; >> > + struct drm_gem_object *obj; >> > + struct lima_bo *bo; >> > + signed long ret; >> > + unsigned long timeout; >> > + >> > + obj = drm_gem_object_lookup(file, handle); >> > + if (!obj) >> > + return -ENOENT; >> > + >> > + bo = to_lima_bo(obj); >> > + >> > + timeout = timeout_ns ? lima_timeout_to_jiffies(timeout_ns) : 0; >> > + >> > + ret = lima_bo_reserve(bo, true); >> > + if (ret) >> > + goto out; >> > + >> > + /* must use long for result check because in 64bit arch int >> > + * will overflow if timeout is too large and get <0 result >> > + */ >> > + ret = reservation_object_wait_timeout_rcu(bo->tbo.resv, write, true, timeout); >> > + if (ret == 0) >> > + ret = timeout ? -ETIMEDOUT : -EBUSY; >> > + else if (ret > 0) >> > + ret = 0; >> > + >> > + lima_bo_unreserve(bo); >> > +out: >> > + drm_gem_object_put_unlocked(obj); >> > + return ret; >> > +} >> >> From Documentation/botching-up-ioctls.txt: >> >> * For timeouts, use absolute times. If you're a good fellow and made your >> ioctl restartable relative timeouts tend to be too coarse and can >> indefinitely extend your wait time due to rounding on each restart. >> Especially if your reference clock is something really slow like the display >> frame counter. With a spec lawyer hat on this isn't a bug since timeouts can >> always be extended - but users will surely hate you if their neat animations >> starts to stutter due to this. >> >> (I made v3d's timeouts relative, but decrement the timeout value the >> user passed by how much I waited so that the timeout probably gets >> reduced after a restartable signal. I should have done absolute.) > timeout_ns in lima is already an absolute one which will be converted to > relative one in lima_timeout_to_jiffies, is this what you want or I miss > understand? Yeah, not sure how I missed the lima function, wich is clearly doing absolute. Sorry! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlxciUgACgkQtdYpNtH8 nujD2xAAunRYTK7014JVtKZO/uR28wHN7haSaFkXawnR9QO7zHvjx05AWXdrq9cL SUYNCYy8xfXI4WXpGX6rVs/gYxpo+Uksa9ImeGTU2WRkGCEUAaXpcMatIbqgMjMj HFVN+5eWEAWMcjWYdkuDo63zS/KjQ8lUC+ZrmmFiFHufRg5thR9Oenr3oM/A12al sgZQy+iCjKC7YemdmeS4l6ziDcSlKO3VmYF9F4uLv3/llxpt70iRge67BNxzUYhu 2fty4soHjUgfsMC68FOIOa2FWPdfQrpYe8YrWm4tz+umXFRkXKLKrbQ1Egi2Z45J OHt9HyyTHo+DxYiVCZH9pQjE5T2IW4d3RY137ZKcPXhdesmNuGp2/BXsiLihLjxB Kq6EpCTn7id9js/gUhfEvzbilexm/ZPTN4fYQNOmbGprHxCK1xZIUeTmmxMQ0UCV ISU4Xfa44+kdqRMTEvkZGEhkXGSuD5Rj+MttL0RCOcPNLQ2RdTQfj9GRG91WE4vQ DfHziJIPJsaXOf3fSH28YGJ39Tu/MmpJVvNfe5Dm//coKtvfsB5qMS7GcEV9LKOY nQ7+qQ9WQIOD6GTKx22Ny0OiTb2D505ozjGIsS+dPl0Iv1elO4pcR09b22y0femP Wk2UI3JAuT9iOKPmml7NcFebBt2WM849wyKoE24V6nSz9MLsA9A= =7dp2 -----END PGP SIGNATURE----- --=-=-=-- --===============1730222635== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1730222635==--