[Intel-gfx] [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
jbarnes at virtuousgeek.org
Thu Dec 9 09:20:24 PST 2010
On Wed, 8 Dec 2010 13:33:20 -0500
Andrew Lutomirski <luto at mit.edu> wrote:
> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <luto at mit.edu> wrote:
> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto at mit.edu> wrote:
> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto at mit.edu> wrote:
> >>> > Hi all-
> >>> >
> >>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
> >>> > 188.8.131.52, i915 started generating exactly 50 interrupts per second
> >>> > (suspiciously equal to my refresh rate) when X is running. I have the
> >>> > Xorg driver 2.12.0 (specifically
> >>> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text
> >>> > console but leave X running, the interrupts stop.
> >>> >
> >>> > Any ideas what to look at?
> >>> Quitting compiz fixes it. Suspending compiz also fixes it.
> >> So it is the vblank interrupt. The vblank interrupt is get alive for a few
> >> seconds after the last use. If it keeps going, then either the system is
> >> as idle as you believe or we lost track of the last user and forget to
> >> switch off the interrupt.
> >> drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
> >> gory details of who/when triggers the vblank interrupt.
> >> -Chris
> > It's the seconds on the clock. That causes activity once per second,
> > which looks like this:
> > Maybe that "several seconds" (5, according to the source) timer is way
> > too long. Is there any reason that drm_vblank_put doesn't turn off
> > interrupts immediately (or, at the latest, on the very next vblank
> > interrupt)? After all, preventing deep sleep whenever there is
> > display activity every five seconds seems like a waste of power.
> This patch fixes it. It's obviously not ready for prime time, but if
> you're OK with the idea I can fix it up and submit it.
> Signed-off-by: Andy Lutomirski <luto at mit.edu>
> Diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 9d3a503..49eca3f 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -471,7 +471,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
> /* Last user schedules interrupt disable */
> if (atomic_dec_and_test(&dev->vblank_refcount[crtc]))
> - mod_timer(&dev->vblank_disable_timer, jiffies + 5*DRM_HZ);
> + mod_timer(&dev->vblank_disable_timer, jiffies);
This will just move the problem around a bit; 5s is arguably too long
to wait before disabling interrupts, but having a second hand or
blinking : in your clock is the real issue here. Why don't you disable
Jesse Barnes, Intel Open Source Technology Center
More information about the Intel-gfx