Bug 24386

Summary:	i915 (KMS): High power consumption after resume
Product:	DRI	Reporter:	Andy Lutomirski <luto>
Component:	DRM/Intel	Assignee:	Jesse Barnes <jbarnes>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	medium	CC:	fdziarmagowski, preining, zdenek.kabelac
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
URL:	http://lkml.org/lkml/2009/10/3/134
Whiteboard:
i915 platform:		i915 features:

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

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.