From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 4/6] drm/i915: simplify i915_reset a bit
Date: Wed, 25 Apr 2012 23:04:24 +0200
Message-ID: <20120425210424.GI5079@phenom.ffwll.local>
References: <1335355033-3854-1-git-send-email-daniel.vetter@ffwll.ch>
	<1335355033-3854-5-git-send-email-daniel.vetter@ffwll.ch>
	<20120425091821.19fc7808@jbarnes-desktop>
	<20120425202712.GH5079@phenom.ffwll.local>
	<20120425133445.3dba673f@jbarnes-desktop>
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-wi0-f171.google.com (mail-wi0-f171.google.com
	[209.85.212.171])
	by gabe.freedesktop.org (Postfix) with ESMTP id 15E3A9ED8D
	for <intel-gfx@lists.freedesktop.org>;
	Wed, 25 Apr 2012 14:03:24 -0700 (PDT)
Received: by wibhj13 with SMTP id hj13so4215691wib.12
	for <intel-gfx@lists.freedesktop.org>;
	Wed, 25 Apr 2012 14:03:24 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20120425133445.3dba673f@jbarnes-desktop>
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: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, Intel Graphics Development <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Wed, Apr 25, 2012 at 01:34:45PM -0700, Jesse Barnes wrote:
> On Wed, 25 Apr 2012 22:27:12 +0200
> Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Wed, Apr 25, 2012 at 09:18:21AM -0700, Jesse Barnes wrote:
> > > On Wed, 25 Apr 2012 13:57:11 +0200
> > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > 
> > > > - need_display is always true, scrap it.
> > > > - don't reacquire the mutex to do nothing after having restored the
> > > >   gem state.
> > > > 
> > > 
> > > Actually I think we generally *don't* need to reset display.  It's
> > > currently there just because we haven't tried reset handling without
> > > it.  But not resetting display would make resets a little less visible,
> > > which would be nice.  Now that you have a nice test setup, can you try
> > > testing without the display engine bit set (i.e. only reset render and
> > > media at hang time)?
> > 
> > Imo 'less visible' and gpu hang don't go well together, the 3 second
> > freeze plus screen flicker at least ensure that users report bugs. And I
> > have no idea whether resetting the entire gpu or just the render portion
> > has a greater chance of survival. So I'm not sure whether working on this
> > has much benefit ... at least opposed to working on the bugs ;-)
> 
> With the CPU/PCH split, display reset is actually a really big hammer.
> Theoretically, just doing a render/media reset will be more reliable
> and have less chance of wedging the system really hard.

Hm, yeah. I think on pch we already only do a reset of the render/media
core and no longer of the display unit. So I think we could just add a
pch_split test around the. But atm we still have some funny things like
the flags parameter which half the reset functions ignore that I'd like to
clean up first. So imo this can wait a bit.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48