From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [PATCH 11/12 v2] drm/i915: wait render timeout ioctl
Date: Sun, 29 Apr 2012 10:27:10 +0100
Message-ID: <1335691674_85536@CP5-2952>
References: <1335481389-7232-1-git-send-email-ben@bwidawsk.net>
	<1335481389-7232-12-git-send-email-ben@bwidawsk.net>
	<1335540301_69364@CP5-2952> <20120428191134.6c501d1c@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 5D91B9E7E8
	for <intel-gfx@lists.freedesktop.org>;
	Sun, 29 Apr 2012 02:27:59 -0700 (PDT)
In-Reply-To: <20120428191134.6c501d1c@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>
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Sat, 28 Apr 2012 19:11:34 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> On Fri, 27 Apr 2012 16:24:24 +0100
> Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 
> > On Thu, 26 Apr 2012 16:03:08 -0700, Ben Widawsky <ben@bwidawsk.net>
> > wrote:
> > > This helps implement glClientWaitSync.
> > > 
> > > Finally we can use the new timed seqno waiting function to allow
> > > userspace to wait on a request with a timeout. This implements that
> > > interface.
> > > 
> > > The new ioctl is very straight forward, there is a flags field
> > > which I envision may be useful for various flush permutations of
> > > the command.
> > 
> > What are the semantics of the ioctl? A simple use case would help
> > specify the interface here.
> 
> The first time I sent out the series, I included the libdrm and igt
> test. Is this what you're looking for, or something in the commit
> message?

Whilst we will be bound by the API as used forever and a day, I found I
could not review the code against the interface for any aberrant
behaviour...

I'd at least like to some justification for the form of the interface in
the changelog and some indication of expected behaviour. That block
should be good enough also to include next to the ioctl so that we have
some ideas of what userspace is expecting when reviewing the code later.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre