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@xxxxxxxxxxxxxxx wrote:
> > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > >
> > > 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@xxxxxxxxxxxxxxx>
> > > ---
> > > 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
