From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [PATCH 3/4 v7] drm/i915: wait render timeout ioctl
Date: Tue, 05 Jun 2012 22:09:48 +0100
Message-ID: <1338930638_513573@CP5-2952>
References: <1337896991-4795-1-git-send-email-ben@bwidawsk.net>
	<1337896991-4795-3-git-send-email-ben@bwidawsk.net>
	<20120524201804.09bba7b8@bwidawsk.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from fireflyinternet.com (smtp.fireflyinternet.com [109.228.6.236])
	by gabe.freedesktop.org (Postfix) with ESMTP id 5E0809F02D
	for <intel-gfx@lists.freedesktop.org>;
	Tue,  5 Jun 2012 14:10:40 -0700 (PDT)
In-Reply-To: <20120524201804.09bba7b8@bwidawsk.net>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Ben Widawsky <ben@bwidawsk.net>Ben Widawsky <ben@bwidawsk.net>
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Thu, 24 May 2012 20:18:04 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> On Thu, 24 May 2012 15:03:10 -0700
> Ben Widawsky <ben@bwidawsk.net> wrote:
> 
> > This helps implement GL_ARB_sync but stops short of allowing full blown
> > sync objects. Finally we can use the new timed seqno waiting function
> > to allow userspace to wait on a buffer object with a timeout. This
> > implements that interface.
> > 
> > The IOCTL will take as input a buffer object handle, and a timeout in
> > nanoseconds (flags is currently optional but will likely be used for
> > permutations of flush operations). Users may specify 0 nanoseconds to
> > instantly check.
> > 
> > The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
> > non-zero timeout parameter the wait ioctl will wait for the given number
> > of nanoseconds on an object becoming unbusy. Since the wait itself does
> > so holding struct_mutex the object may become re-busied before this
> > completes. A similar but shorter race condition exists in the busy
> > ioctl.
> > 
> > v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris)
> > Flush the object from the gpu write domain (Chris + Daniel)
> > Fix leaked refcount in good case (Chris)
> > Naturally align ioctl struct (Chris)
> > 
> > v3: Drop lock after getting seqno to avoid ugly dance (Chris)
> > 
> > v4: check for 0 timeout after olr check to allow polling (Chris)
> > 
> > v5: Updated the comment. (Chris)
> > 
> > v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel)
> > Fix the commit message comment to be less ugly (Ben)
> > Add a warning to check the return timespec (Ben)
> > 
> > v7: Use DRM_AUTH for the ioctl. (Eugeni)

So what Ben just reminded me was that we hadn't considered enabling an
infinite non-blocking wait through this ioctl. That seems like a
gross oversight to me...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre