Re: [PATCH 4/6] drm/i915: simplify i915_reset a bit

[Daniel Vetter <daniel@ffwll.ch>]

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