[Intel-gfx] [PATCH 4/4] drm/i915: set pm._irqs_disabled at IRQ init time

Jesse Barnes jbarnes at virtuousgeek.org
Mon Jul 14 22:25:01 CEST 2014


On Mon, 14 Jul 2014 14:47:07 -0300
Paulo Zanoni <przanoni at gmail.com> wrote:

> 2014-07-14 14:26 GMT-03:00 Daniel Vetter <daniel at ffwll.ch>:
> > On Mon, Jul 14, 2014 at 12:23:11PM -0300, Paulo Zanoni wrote:
> >> 2014-06-20 13:29 GMT-03:00 Jesse Barnes <jbarnes at virtuousgeek.org>:
> >> > Before we've installed the handler, we can set this and avoid confusing
> >> > init code that then thinks IRQs are enabled and spews complaints
> >> > everywhere.
> >>
> >> But then at some point the DRM layer will call our IRQ init callbacks,
> >> which will initalize the interrupts but leave irqs_disabled as true,
> >> which will also confuse some code somewhere at some point. And it will
> >> only be set to false after we {runtime,}-suspend/resume.
> >
> > The drm irq stuff is _strictly_ a helper library, at least for modesetting
> > drivers. Which means it will never call our callbacks on its own.
> 
> I was talking about drm_irq_install(), which is called by i915_driver_load().

Since this set fixes the failures I've found, I'd rather see it merged
than to regress everyone's power consumption.

I think it'll probably take us awhile to figure out how we want to do
this stuff.  Paulo, maybe you can create a task with some of the things
you'd like to see done?

With these patches, we go away from ever using the drm irq bits except
for at load and unload.  We use the pm irq fields for tracking our own
stuff, which means some special init handling and then calls at
suspend/resume, so I don't think it's too complex as-is, but if you
want to do something better, that's ok too.

-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list