From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [PATCH 28/50] drm: Remove DRM_WAIT_ON from all drivers Date: Wed, 18 Dec 2013 10:37:54 +0100 Message-ID: <52B16CF2.4050209@vmware.com> References: <1386758111-3446-1-git-send-email-daniel.vetter@ffwll.ch> <1386758111-3446-29-git-send-email-daniel.vetter@ffwll.ch> <20131218082519.GC26371@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by gabe.freedesktop.org (Postfix) with ESMTP id 57622FB6F0 for ; Wed, 18 Dec 2013 01:37:58 -0800 (PST) In-Reply-To: <20131218082519.GC26371@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Daniel Vetter Cc: Daniel Vetter , DRI Development List-Id: dri-devel@lists.freedesktop.org On 12/18/2013 09:25 AM, Daniel Vetter wrote: > On Wed, Dec 18, 2013 at 11:39:27AM +1000, Dave Airlie wrote: >> On Wed, Dec 11, 2013 at 8:34 PM, Daniel Vetter wrote: >>> Since this is all old ums stuff (including the one in the radeon >>> driver) I've just tried to perfectly replicate the existing semantics. >>> >>> Reinventing wait queue code with semantics that differ from all the >>> standard linux wait functions is just hairy, so now we can get rid of >>> this and so make sure it'll never again be used. >>> >>> Oh and: via futexes ... *shudder* >> This one worries me, I've had numerous attempts to rip this out in the >> past and they always changed semantics on some devices and broke >> stuff. >> >> The sneaky timeout is essential for a lot of the hardware >> >> https://urldefense.proofpoint.com/v1/url?u=http://marc.info/?l%3Ddri-devel%26m%3D111383274225047%26w%3D1&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=wgfMdGK1q8n48mRclOyEBEeb4OB1u5PwhRxswGxwjGY%3D%0A&s=6e87c42702c679927c4e0fab27ef8874b2a22707cb860f0de000df4798199e63 >> >> So I think I'd like a few more people to review this one before I go >> near it again :-) > Oh, and I've thought the only tricky stuff is mapping the errno's > correctly. I think if we have such cases of racy drivers then the right > thing to do is to shovel this macro into drivers and slap a big comment > about signalling races on top of that code. > > Thomas report doesn't say so, but I guess it's for via. Thomas, do you > still have a vague recollection of what this has been about? Yes, this was with via, but IIRC there were other drivers affected as well, but OTOH, I think the kernel wait code was fixed for races some time after that.... /Thomas > > Dave, do you want me to just respin this one with via left as-is (and the > macro pushed into the via driver)? > > Thanks, Daniel