Bug 24386 - i915 (KMS): High power consumption after resume
i915 (KMS): High power consumption after resume
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: Jesse Barnes
http://lkml.org/lkml/2009/10/3/134
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-07 20:44 UTC by Andy Lutomirski
Modified: 2010-04-06 11:30 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Lutomirski 2009-10-07 20:44:05 UTC
After a suspend/resume cycle, my power consumption usually
goes up by over a watt.  I think this is due to i915, because of an
experiment I did:

1. Boot with modesetting off into single user mode.
2. Suspend and resume
3. Reload i915 with modesetting on.  Power consumption is low.
4. Suspend and resume.  Power consumption is high.
5. Unbind and rebind i915.  Power consumption is high.
6. Suspend.  System hangs (seperate bug, I guess).

I get similar results if I boot single user with modesetting on: power
consumption is low, becomes high after suspend/resume, and goes low
again after rebinding i915.

This is on 2.6.32-rc1 + a little (i.e. 84d88d5d4e from Linus' tree
plus an ext4 fix).  I'm having trouble reproducing any of this on
2.6.31.

I'm using a Lenovo X200s.
Comment 1 Eric Anholt 2009-10-13 12:40:25 UTC
Could you try again on the for-linus branch of my kernel tree?  It's got a fix from jbarnes to restore FBC setup on resume.
Comment 2 Andy Lutomirski 2009-10-15 06:46:31 UTC
On a single try using 58a27471d00dc09945cbcfbbc5cbcdcd3c28211d (from anholt/drm-inte for-linus) I couldn't reproduce the bug.  Power was 6.7 watts after resume, which is pretty good.

(Oddly enough, it was 7 watts before suspend, but maybe I just didn't wait long enough for it to settle.)

I'm a bit surprised this had any effect, since I have a GM45 and this patch wasn't applied:

http://patchwork.kernel.org/patch/53777/
Comment 3 Jesse Barnes 2009-12-04 15:42:20 UTC
So are you still seeing this with the latest bits?  We did find some issues with the self refresh programming for 945GM, but that shouldn't affect your GM45 platform... I'll see if I can reproduce on my x200.
Comment 4 Andy Lutomirski 2009-12-21 20:19:48 UTC
I still see this bug on 2.6.32.1 and on a hacked-up hybrid that's 2.6.32.1 with include/drm and drivers/gpu/drm yanked from a merge of dd59f6c and c566ec4 (i.e. Linus' tree from today with drm-next from today).  I can't usefully test on a real 2.6.33-rc1 tree because I can't get it to suspend without freezing.

Note that I've never been able to reproduce this reliably on demand.  It usually seems to happen when I'm doing something else, then I suspend, then I come back awhile later and resume.  I think that 2.6.33's driver has less of a difference between the good and bad states, but I won't swear to that (maybe it's due to RC6 support).
Comment 5 Jesse Barnes 2010-02-11 10:01:18 UTC
Any update on this Andy?  I guess you've been able to get 2.6.33-rc working at least a little (aside from the hotplug/sluggishness issue), have you been able to reproduce the power problem?
Comment 6 Andy Lutomirski 2010-02-11 12:51:20 UTC
(In reply to comment #5)
> Any update on this Andy?  I guess you've been able to get 2.6.33-rc working at
> least a little (aside from the hotplug/sluggishness issue), have you been able
> to reproduce the power problem?
> 

I haven't tested it much on 2.6.33-rcX because the hotplug bug kept my uptime from being high enough.  A single test with a kernel that has HDMI, DP, and SDVO patched out didn't show the problem, but that isn't a great test and it would mask the bug if the problem were in that code.

I'll keep you posted.
Comment 7 Jesse Barnes 2010-04-06 11:30:20 UTC
optimistically marking this as fixed