[Intel-gfx] [PATCH] drm/i915: Fix irq enable tracking in driver load

[Daniel Vetter]

On Thu, Sep 04, 2014 at 04:42:36PM +0300, Jani Nikula wrote:
> On Thu, 04 Sep 2014, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Thu, Sep 04, 2014 at 02:12:10PM +0300, Jani Nikula wrote:
> >> On Wed, 27 Aug 2014, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> >> > A bunch of warnings fire on some ->irq_postinstall hooks since those
> >> > can enable interrupts (e.g. rps interrupts). And then our ordering
> >> > self-checks fire and complain.
> >> >
> >> > To fix that set the tracking boolen before enabling the irqs witho
> >> > drm_irq_install. Quoting the discussion with Jesse why that's safe:
> >> 
> >> Yi Sun's testing result needs to be addressed one way or another before
> >> merging this:
> >> 
> >> http://mid.gmane.org/D9F66AA509623343B6A9A3D4502D5A52112B0676@SHSMSX101.ccr.corp.intel.com
> >
> > Shrug it off as an unstable test result. Both mine and Jesse's patch
> > really only change the logic we use to WARN about interrupt state. We
> > don't use pm._irqs_disabled for anything else at all.
> 
> Okay, so this is a PITA to review, but at least
> ironlake_enable_display_irq will behave differently during
> drm_irq_install because of this patch.

Oops, I've somehow completely missed the early return in there. That means
we actually break the ironlake rps setup done in postinstall without any
of these patches. I've mixed this up with the pipestat check I've done
where I just WARN, but don't bail out.

tbh not sure why we bail out, at worst we'll get a few unclaimed register
warnings.

The only other place is if we get an interrupt right away, but that means
the preinstall hook has a bug somewhere. So the only place where behaviour
chances is still only ironlake, so still no explanation why hsw/bdw
suddenly start to fall over all together.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch