[Intel-gfx] [PATCH 2/4] drm/i915: Restore the display config after a GPU reset on gen4

[Daniel Vetter]

On Tue, May 20, 2014 at 11:46:42AM +0300, Ville Syrjälä wrote:
> On Tue, May 20, 2014 at 10:03:44AM +0200, Daniel Vetter wrote:
> > On Mon, May 19, 2014 at 10:25:19PM +0300, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > On pre-ctg GPU reset also resets the display hardware. Force a mode
> > > restore after the GPU reset, and also re-init clock gating.
> > > 
> > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c | 8 ++++++++
> > >  1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > > index b948c71..2ec3796 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -794,6 +794,14 @@ int i915_reset(struct drm_device *dev)
> > >  		if (INTEL_INFO(dev)->gen > 5)
> > >  			intel_reset_gt_powersave(dev);
> > >  
> > > +		if (IS_GEN4(dev) && !IS_G4X(dev)) {
> > > +			intel_init_clock_gating(dev);
> > > +
> > > +			drm_modeset_lock_all(dev);
> > > +			intel_modeset_setup_hw_state(dev, true);
> > > +			drm_modeset_unlock_all(dev);
> > 
> > Locking inversion here. I think we need to push this down to the very end.
> 
> We already dropped struct_mutex a bit earlier. Or was there some other
> lock you were worried about?

Oh right, was just confused by the mutex_unlock in the else branch.
> 
> > Also this leaves the interesting question of what happens with vblank
> > waits and friends ...
> 
> Hmm. I guess we might have some kind of refcount problem on our hands w/
> vblanks and whatnot. Might be I'd need to for_each_crtc() .crtc_disable()
> before the reset. That would match the g33 spec's recommendation to
> disable all planes, but it also does quite a bit more, maybe too much?
> But I could try it at least.

For full nasties we might need a intel_display_reset which does a few
things more and wraps the entire sequence in drm_modeset_lock_all so that
nothing can escape. Well except the vblank waiting because drm_irq.c. I
think we should grab the crtc->mutex in the vblank ioctl anyway for kms.

There's a few more trick bits:
- On ilk+ (but might as well do it for g4x+) we don't want to reprobe the
  interrupt since that breaks a few things like vblanks or pipe crc which
  we only enable at runtime. If we split this up we could just keep the
  irq reset for pre-g4x. Still leaves us with racy vblank, but meh. Do we
  have a vblank-vs-hagn testcase already?

- Full deadlock audit for the modeset locks to make sure the gpu reset
  work can actually execute.

- Probably more ...

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch