From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 09/10] drm/i915: wait render timeout ioctl
Date: Sun, 22 Apr 2012 12:11:38 +0200
Message-ID: <20120422101138.GD4723@phenom.ffwll.local>
References: <1334971412-4826-1-git-send-email-ben@bwidawsk.net>
	<1334971412-4826-10-git-send-email-ben@bwidawsk.net>
	<1335088110_18651@CP5-2952>
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 mail-we0-f177.google.com (mail-we0-f177.google.com
	[74.125.82.177])
	by gabe.freedesktop.org (Postfix) with ESMTP id 6E0E19E73F
	for <intel-gfx@lists.freedesktop.org>;
	Sun, 22 Apr 2012 03:10:39 -0700 (PDT)
Received: by werp11 with SMTP id p11so8498068wer.36
	for <intel-gfx@lists.freedesktop.org>;
	Sun, 22 Apr 2012 03:10:38 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <1335088110_18651@CP5-2952>
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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>, intel-gfx@lists.freedesktop.org, Ben Widawsky <benjamin.widawsky@intel.com>
List-Id: intel-gfx@lists.freedesktop.org

On Sun, Apr 22, 2012 at 10:48:01AM +0100, Chris Wilson wrote:
> On Fri, 20 Apr 2012 18:23:31 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> > +int
> > +i915_gem_wait_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
> > +{
> > +	struct drm_i915_gem_wait *args = data;
> > +	struct drm_i915_gem_object *obj;
> > +	struct intel_ring_buffer *ring;
> > +	long timeout;
> > +	u32 seqno = 0;
> > +	int ret = 0;
> > +
> > +	ret = i915_mutex_lock_interruptible(dev);
> > +	if (ret)
> > +		return ret;
> > +
> > +	obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->bo_handle));
> > +	if (&obj->base == NULL) {
> > +		mutex_unlock(&dev->struct_mutex);
> > +		return -ENOENT;
> > +	}
> > +
> > +	timeout = args->timeout_ns;
> 
> We discussed on IRC whether or not we needed to flush here. For the
> drm_intel_gem_bo_wait_rendering() use-case, we do need to be able to first
> queue a flush.
> 
>   if (args->flags & I915_WAIT_FINISH)
> 	i915_gem_object_flush_gpu_write_domain(obj);
> 
> Borrowing the terminology from glFlush/glFinish. This becomes moot if
> the flushing list is ever vanquished, but still a useful distinction and
> required today.

Yeah, I agree that emitting any required flushes (akin to the busy ioctl)
makes sense here. While I bikeshed, the mutex_lock can be moved after
drm_gem_object_lookup - we only need the mutex when dropping the reference
(and hence the unref_unlocked variant).
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48