On Thu, Sep 04, 2014 at 04:42:36PM +0300, Jani Nikula wrote: > On Thu, 04 Sep 2014, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Thu, Sep 04, 2014 at 02:12:10PM +0300, Jani Nikula wrote: > >> On Wed, 27 Aug 2014, Daniel Vetter <daniel.vetter@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx