On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes <[email protected]> wrote: > On Wed, 8 Dec 2010 13:33:20 -0500 > Andrew Lutomirski <[email protected]> wrote: > >> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <[email protected]> wrote: >> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <[email protected]> >> > wrote: >> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <[email protected]> wrote: >> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <[email protected]> wrote: >> >>> > Hi all- >> >>> > >> >>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 + >> >>> > 2.6.36.1, 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 <[email protected]> >> >> 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); >> } >> EXPORT_SYMBOL(drm_vblank_put); > > 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 > that instead?
I did. But I might also scroll a webpage every second or so (or have a webpage loaded at some point that updates itself every second) and I see no reason to prevent the system from going into its maximum sleep state in between updates. IOW, I think we should optimize for mostly-idle machines in addition to completely-idle machines. --Andy > > -- > Jesse Barnes, Intel Open Source Technology Center > _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
