From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 3/5] drm/i915: don't return a spurious -EIO
 from intel_ring_begin
Date: Mon, 25 Jun 2012 22:49:03 +0200
Message-ID: <20120625204903.GG4708@phenom.ffwll.local>
References: <1340548956-4097-1-git-send-email-daniel.vetter@ffwll.ch>
	<1340548956-4097-4-git-send-email-daniel.vetter@ffwll.ch>
	<1340656383_69674@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-bk0-f49.google.com (mail-bk0-f49.google.com
	[209.85.214.49])
	by gabe.freedesktop.org (Postfix) with ESMTP id 268BB9E790
	for <intel-gfx@lists.freedesktop.org>;
	Mon, 25 Jun 2012 13:47:25 -0700 (PDT)
Received: by bkwj4 with SMTP id j4so3992623bkw.36
	for <intel-gfx@lists.freedesktop.org>;
	Mon, 25 Jun 2012 13:47:25 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <1340656383_69674@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: Daniel Vetter <daniel.vetter@ffwll.ch>, Intel Graphics Development <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Mon, Jun 25, 2012 at 09:32:23PM +0100, Chris Wilson wrote:
> On Sun, 24 Jun 2012 16:42:34 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > We have a careful logic in i915_gem_check_wedge already to asses whether
> > the gpu reset has been tried already and hence whether to return -EIO
> > or -EAGAIN.
> > 
> > Having this early check in intel_ring_begin doesn't buy us anything,
> > since we'll be calling into wait_request in the usual case already
> > anyway. In the corner case of not waiting for free space using the
> > last_retired_head we simply need to do the same check, too.
> > 
> > With these changes we'll only ever get an -EIO from intel_ring_begin
> > if the gpu has truely been declared dead.
> 
> The intention here was that only operations that queued a command to a
> wedged GPU would trigger the EIO. That has been superseded by the error
> checking during mutex acquisition. The patch looks sane, but I'd like
> it split into two, one to remove the wedged check before
> intel_ring_begin (with some of the rationale about it now being
> superfluous) and a separate patch to reuse check_wedge().
> 
> It looks like the patch to reuse check_wedge() should be first as it is
> the common theme in the series.

Hm, actually I think I'll smash the check_wedge into the last patch. With
that change, this patch would solely be about not returning spurious -EIO,
whereas the last patch would be solely about not returning -EAGAIN in
cases we can't handle. Does that make some sense?
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48