* i915: high power consumption after suspend/resume
@ 2009-10-03 16:39 Andrew Lutomirski
2009-10-03 16:50 ` [resend] " Andrew Lutomirski
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Lutomirski @ 2009-10-03 16:39 UTC (permalink / raw)
To: dri-devel, linux-kernel, intel-gfx
Hi-
First, thanks for all the great work on i915's power saving features
-- power consumption on my laptop (Lenovo X200s) is now almost as low
on Linux as on Windows.
After a suspend/resume cycle, though, 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.
Thanks,
Andy
^ permalink raw reply [flat|nested] 15+ messages in thread
* [resend] i915: high power consumption after suspend/resume
2009-10-03 16:39 i915: high power consumption after suspend/resume Andrew Lutomirski
@ 2009-10-03 16:50 ` Andrew Lutomirski
2009-10-05 16:21 ` Jesse Barnes
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Lutomirski @ 2009-10-03 16:50 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, linux-kernel
[resend b/c the intel-gfx list doesn't allow non-member posting]
Hi-
First, thanks for all the great work on i915's power saving features
-- power consumption on my laptop (Lenovo X200s) is now almost as low
on Linux as on Windows.
After a suspend/resume cycle, though, 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.
Thanks,
Andy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-10-03 16:50 ` [resend] " Andrew Lutomirski
@ 2009-10-05 16:21 ` Jesse Barnes
2009-10-08 3:44 ` Andrew Lutomirski
0 siblings, 1 reply; 15+ messages in thread
From: Jesse Barnes @ 2009-10-05 16:21 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: intel-gfx, linux-kernel, dri-devel
On Sat, 3 Oct 2009 12:50:01 -0400
Andrew Lutomirski <luto@mit.edu> wrote:
> [resend b/c the intel-gfx list doesn't allow non-member posting]
>
> Hi-
>
> First, thanks for all the great work on i915's power saving features
> -- power consumption on my laptop (Lenovo X200s) is now almost as low
> on Linux as on Windows.
>
> After a suspend/resume cycle, though, 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 probably need to save/restore some more of the power saving state
across suspend/resume... Can you file a bug for this at
bugs.freedesktop.org so it doesn't get lost?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-10-05 16:21 ` Jesse Barnes
@ 2009-10-08 3:44 ` Andrew Lutomirski
2009-10-29 16:47 ` Jesse Barnes
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Lutomirski @ 2009-10-08 3:44 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx, linux-kernel, dri-devel
On Mon, Oct 5, 2009 at 12:21 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Sat, 3 Oct 2009 12:50:01 -0400
> Andrew Lutomirski <luto@mit.edu> wrote:
>
>> [resend b/c the intel-gfx list doesn't allow non-member posting]
>>
>> Hi-
>>
>> First, thanks for all the great work on i915's power saving features
>> -- power consumption on my laptop (Lenovo X200s) is now almost as low
>> on Linux as on Windows.
>>
>> After a suspend/resume cycle, though, 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 probably need to save/restore some more of the power saving state
> across suspend/resume... Can you file a bug for this at
> bugs.freedesktop.org so it doesn't get lost?
Submitted as https://bugs.freedesktop.org/show_bug.cgi?id=24386
Thanks,
Andy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-10-08 3:44 ` Andrew Lutomirski
@ 2009-10-29 16:47 ` Jesse Barnes
2009-10-29 17:22 ` Andrew Lutomirski
0 siblings, 1 reply; 15+ messages in thread
From: Jesse Barnes @ 2009-10-29 16:47 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: intel-gfx, linux-kernel, dri-devel
On Wed, 7 Oct 2009 23:44:35 -0400
Andrew Lutomirski <luto@mit.edu> wrote:
> > I probably need to save/restore some more of the power saving state
> > across suspend/resume... Can you file a bug for this at
> > bugs.freedesktop.org so it doesn't get lost?
>
> Submitted as https://bugs.freedesktop.org/show_bug.cgi?id=24386
Andrew, are you still seeing this after the various fixes that have
landed in Linus's tree?
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-10-29 16:47 ` Jesse Barnes
@ 2009-10-29 17:22 ` Andrew Lutomirski
2009-10-29 17:40 ` Andrew Lutomirski
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Lutomirski @ 2009-10-29 17:22 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx, linux-kernel, dri-devel
On Thu, Oct 29, 2009 at 12:47 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Wed, 7 Oct 2009 23:44:35 -0400
> Andrew Lutomirski <luto@mit.edu> wrote:
>> > I probably need to save/restore some more of the power saving state
>> > across suspend/resume... Can you file a bug for this at
>> > bugs.freedesktop.org so it doesn't get lost?
>>
>> Submitted as https://bugs.freedesktop.org/show_bug.cgi?id=24386
>
> Andrew, are you still seeing this after the various fixes that have
> landed in Linus's tree?
I'm not entirely convinced it's suspend/resume related any more, but
there's still a problem. When I got your email, my system had been up
for awhile (running Linus' 964fe080d94db82a3268443e9b9ece4c60246414
(approximately 2.6.32-rc5) plus drm-intel/for-linus from a couple days
ago for the watermark fix)), suspended and resumed several times, and
logged in and out several times. I turned off wireless and power
consumption was 9.0 watts.
I switched to console and killed X. Power consumption still 9.0
watts. The system was almost completely idle.
I rebound i915. Power consumption dropped to 7.3 watts.
I restarted X and logged back in. System froze hard (whoops).
It looks like something is getting the chip stuck in a high-power state.
--Andy
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-10-29 17:22 ` Andrew Lutomirski
@ 2009-10-29 17:40 ` Andrew Lutomirski
2009-10-30 6:25 ` Andrew Lutomirski
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Lutomirski @ 2009-10-29 17:40 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx, linux-kernel, dri-devel
On Thu, Oct 29, 2009 at 1:22 PM, Andrew Lutomirski <luto@mit.edu> wrote:
> On Thu, Oct 29, 2009 at 12:47 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> On Wed, 7 Oct 2009 23:44:35 -0400
>> Andrew Lutomirski <luto@mit.edu> wrote:
>>> > I probably need to save/restore some more of the power saving state
>>> > across suspend/resume... Can you file a bug for this at
>>> > bugs.freedesktop.org so it doesn't get lost?
>>>
>>> Submitted as https://bugs.freedesktop.org/show_bug.cgi?id=24386
>>
>> Andrew, are you still seeing this after the various fixes that have
>> landed in Linus's tree?
>
> I'm not entirely convinced it's suspend/resume related any more, but
> there's still a problem. When I got your email, my system had been up
> for awhile (running Linus' 964fe080d94db82a3268443e9b9ece4c60246414
> (approximately 2.6.32-rc5) plus drm-intel/for-linus from a couple days
> ago for the watermark fix)), suspended and resumed several times, and
> logged in and out several times. I turned off wireless and power
> consumption was 9.0 watts.
>
> I switched to console and killed X. Power consumption still 9.0
> watts. The system was almost completely idle.
>
> I rebound i915. Power consumption dropped to 7.3 watts.
>
> I restarted X and logged back in. System froze hard (whoops).
>
> It looks like something is getting the chip stuck in a high-power state.
I just suspended and resumed and power consumption stayed low. I'll
try and get an intel_reg_dumper diff next time I trigger this bug.
--Andy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-10-29 17:40 ` Andrew Lutomirski
@ 2009-10-30 6:25 ` Andrew Lutomirski
2009-10-30 15:37 ` Jesse Barnes
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Lutomirski @ 2009-10-30 6:25 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx, linux-kernel, dri-devel
On Thu, Oct 29, 2009 at 1:40 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>
> I just suspended and resumed and power consumption stayed low. I'll
> try and get an intel_reg_dumper diff next time I trigger this bug.
intel_reg_dumper blames RENCLK_GATE_D2. Patch coming.
Maybe my BIOS doesn't always reset it.
--Andy
>
> --Andy
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-10-30 6:25 ` Andrew Lutomirski
@ 2009-10-30 15:37 ` Jesse Barnes
2009-10-30 18:55 ` Andrew Lutomirski
0 siblings, 1 reply; 15+ messages in thread
From: Jesse Barnes @ 2009-10-30 15:37 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: intel-gfx, linux-kernel, dri-devel
On Fri, 30 Oct 2009 02:25:21 -0400
Andrew Lutomirski <luto@mit.edu> wrote:
> On Thu, Oct 29, 2009 at 1:40 PM, Andrew Lutomirski <luto@mit.edu>
> wrote:
> >
> > I just suspended and resumed and power consumption stayed low. I'll
> > try and get an intel_reg_dumper diff next time I trigger this bug.
>
> intel_reg_dumper blames RENCLK_GATE_D2. Patch coming.
>
> Maybe my BIOS doesn't always reset it.
Does resetting that reg get your power savings back?
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-10-30 15:37 ` Jesse Barnes
@ 2009-10-30 18:55 ` Andrew Lutomirski
2009-11-05 4:00 ` Andrew Lutomirski
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Lutomirski @ 2009-10-30 18:55 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx, linux-kernel, dri-devel
On Fri, Oct 30, 2009 at 11:37 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Fri, 30 Oct 2009 02:25:21 -0400
> Andrew Lutomirski <luto@mit.edu> wrote:
>
>> On Thu, Oct 29, 2009 at 1:40 PM, Andrew Lutomirski <luto@mit.edu>
>> wrote:
>> >
>> > I just suspended and resumed and power consumption stayed low. I'll
>> > try and get an intel_reg_dumper diff next time I trigger this bug.
>>
>> intel_reg_dumper blames RENCLK_GATE_D2. Patch coming.
>>
>> Maybe my BIOS doesn't always reset it.
>
> Does resetting that reg get your power savings back?
Surprisingly, no. With my kernel patched to restore it on resume, I
still see high power consumption, and rebinding still fixes it. (As
an aside, I think hat i915's ability to survive rebinding without
crashing on the next X startup has gotten worse recently. I
invariably OOPS awhile after rebinding with recent kernels.)
I diffed the output of intel_reg_dumper (2.9.0, I think):
--- /tmp/pre-rebind 2009-10-30 14:35:24.267236469 -0400
+++ /tmp/post-rebind 2009-10-30 14:39:22.649986477 -0400
@@ -46,7 +46,7 @@
(II): PFIT_CONTROL: 0x00000000
(II): PFIT_PGM_RATIOS: 0x00000000
(II): PORT_HOTPLUG_EN: 0x3e040320
-(II): PORT_HOTPLUG_STAT: 0x38560800
+(II): PORT_HOTPLUG_STAT: 0x38000000
(II): DSPACNTR: 0x00000000 (disabled, pipe A)
(II): DSPASTRIDE: 0x00000000 (0 bytes)
(II): DSPAPOS: 0x00000000 (0, 0)
@@ -149,7 +149,7 @@
(II): FBC_COMMAND: 0x08c80034
(II): FBC_STATUS: 0x00000000
(II): FBC_CONTROL2: 0x00000000
-(II): FBC_FENCE_OFF: 0x00008000
+(II): FBC_FENCE_OFF: 0x10000000
(II): FBC_MOD_NUM: 0x00000060
(II): MI_MODE: 0x00000200
(II): MI_ARB_STATE: 0x00000040
intel_reg_write doesn't seem to work right on FBC_FENCE_OFF (previous
value doesn't agree w/ intel_reg_dumper), and I'm not sure exactly
what that's supposed to do.
--Andy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-10-30 18:55 ` Andrew Lutomirski
@ 2009-11-05 4:00 ` Andrew Lutomirski
2009-11-05 16:28 ` Jesse Barnes
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Lutomirski @ 2009-11-05 4:00 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx, linux-kernel, dri-devel
Here's some more info. I write a little script:
#!/bin/sh
for ((i=0; $i < 15; i=$i+1)); do cat
/sys/class/power_supply/BAT0/power_now; sleep 1 ; done
echo 'Wedging'
echo 1 > /sys/kernel/debug/dri/0/i915_wedged
for ((i=0; $i < 15; i=$i+1)); do cat
/sys/class/power_supply/BAT0/power_now; sleep 1 ; done
I triggered the high power consumption twice today. I logged out of
X, logged into a console, and ran the script each time. (The first
time, I did 10 iterations, not 15.) Here are the results:
9586000
9574000
9574000
9586000
9586000
9574000
9574000
9629000
9629000
9607000
Wedging
9607000
9614000
9614000
9173000
9173000
8775000
8775000
8535000
8535000
8341000
and
9080000
9080000
9022000
9022000
9112000
9112000
9100000
9100000
9100000
9100000
9123000
9123000
9112000
9112000
9135000
Wedging
9135000
9053000
9053000
8618000
8618000
8309000
8309000
8056000
8056000
7861000
7861000
7712000
7712000
7643000
7643000
so it looks like it's not a register setting after all. Maybe my BIOS
leaves the renderer in some weird state.
--Andy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-11-05 4:00 ` Andrew Lutomirski
@ 2009-11-05 16:28 ` Jesse Barnes
2009-11-06 20:25 ` Andrew Lutomirski
0 siblings, 1 reply; 15+ messages in thread
From: Jesse Barnes @ 2009-11-05 16:28 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: intel-gfx, linux-kernel, dri-devel
On Wed, 4 Nov 2009 23:00:14 -0500
Andrew Lutomirski <luto@mit.edu> wrote:
> so it looks like it's not a register setting after all. Maybe my BIOS
> leaves the renderer in some weird state.
Note that the register dumping tool doesn't capture everything. If you
really want to do some detective work you could dump the whole MMIO
space and compare differences. You should be able to find definitions
for many of the reg offsets in the docs at intellinuxgraphics.org,
maybe there's something we don't dump that's changing and that explains
your power consumption changes.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-11-05 16:28 ` Jesse Barnes
@ 2009-11-06 20:25 ` Andrew Lutomirski
2009-11-06 21:57 ` Jesse Barnes
0 siblings, 1 reply; 15+ messages in thread
From: Andrew Lutomirski @ 2009-11-06 20:25 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx, linux-kernel, dri-devel
On Thu, Nov 5, 2009 at 11:28 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Wed, 4 Nov 2009 23:00:14 -0500
> Andrew Lutomirski <luto@mit.edu> wrote:
>> so it looks like it's not a register setting after all. Maybe my BIOS
>> leaves the renderer in some weird state.
>
> Note that the register dumping tool doesn't capture everything. If you
> really want to do some detective work you could dump the whole MMIO
> space and compare differences. You should be able to find definitions
> for many of the reg offsets in the docs at intellinuxgraphics.org,
> maybe there's something we don't dump that's changing and that explains
> your power consumption changes.
Here's the diff for another i915_wedged test. - is high power and +
is low power.
--- /tmp/regs_pre_wedge 2009-11-06 14:46:44.042345316 -0500
+++ /tmp/regs_post_wedge 2009-11-06 14:47:14.798345239 -0500
@@ -45,8 +45,8 @@
(II): PP_DIVISOR: 0x003e7f03
(II): PFIT_CONTROL: 0x00000000
(II): PFIT_PGM_RATIOS: 0x00000000
-(II): PORT_HOTPLUG_EN: 0x3e040320
-(II): PORT_HOTPLUG_STAT: 0x38560800
+(II): PORT_HOTPLUG_EN: 0x3e040200
+(II): PORT_HOTPLUG_STAT: 0x38000300
(II): DSPACNTR: 0x00000000 (disabled, pipe A)
(II): DSPASTRIDE: 0x00000000 (0 bytes)
(II): DSPAPOS: 0x00000000 (0, 0)
@@ -179,9 +179,9 @@
(II): AUD_CONFIG: 0x00000004
(II): AUD_HDMIW_STATUS: 0x00000000
(II): AUD_CONV_CHCNT: 0x00000000
-(II): VIDEO_DIP_CTL: 0x20000602
+(II): VIDEO_DIP_CTL: 0x20000603
(II): AUD_PINW_CNTR: 0x00000140
-(II): AUD_CNTL_ST: 0x00002042
+(II): AUD_CNTL_ST: 0x00002063
(II): AUD_PIN_CAP: 0x00000094
(II): AUD_PINW_CAP: 0x004073bd
(II): AUD_PINW_UNSOLRESP: 0x00000000
@@ -2285,8 +2285,8 @@
00002024: 00000000
00002028: 00000900
0000202C: 00000000
-00002030: 00005B10
-00002034: 07205B10
+00002030: 00000000
+00002034: 02000000
00002038: 02000000
0000203C: 0001F001
00002040: 00000000
@@ -2302,7 +2302,7 @@
00002068: 01000000
0000206C: FFFFFFFE
00002070: 0001E000
-00002074: 07205B10
+00002074: 02000000
00002078: 02005B10
0000207C: FFFFFFFF
00002080: 01FFF000
@@ -2316,7 +2316,7 @@
000020A0: 00028053
000020A4: 00000000
000020A8: FFFC5FAE
-000020AC: 00020000
+000020AC: 00000000
000020B0: 00000000
000020B4: FFFFFF05
000020B8: 00000001
@@ -2407,7 +2407,7 @@
0000220C: 10800001
00002210: 00000000
00002214: 00000000
-00002218: 07205B10
+00002218: 02000000
0000221C: 00000000
00002220: 00000000
00002224: 00000000
@@ -2487,8 +2487,8 @@
0000234C: 00000000
00002350: 2364819D
00002354: 00000000
-00002358: 55A00000
-0000235C: 56C9F19D
+00002358: A9000000
+0000235C: 5892DB63
00002360: 00000000
00002364: 00000000
00002368: 00000000
@@ -16935,7 +16935,7 @@
0001050C: 00000000
00010510: 00000000
00010514: 00000000
-00010518: 25280A0B
+00010518: 25270A0B
0001051C: 00000000
00010520: 00000000
00010524: 00000000
@@ -17169,7 +17169,7 @@
000108B4: 00000024
000108B8: 00000000
000108BC: 00000000
-000108C0: 00003B37
+000108C0: 00003937
000108C4: 00000807
000108C8: 0000211F
000108CC: 00000000
@@ -17577,7 +17577,7 @@
00010F14: 00000000
00010F18: 00000000
00010F1C: 00000000
-00010F20: 20024808
+00010F20: 28036A8D
00010F24: 00000000
00010F28: 00000000
00010F2C: 00000000
@@ -17633,9 +17633,9 @@
00010FF4: 00000000
00010FF8: 00000000
00010FFC: 000007D0
-00011000: 0093007A
-00011004: 007C0400
-00011008: 0000007C
+00011000: 0093007F
+00011004: 00FF0000
+00011008: 000000FF
0001100C: 00000000
00011010: 80000009
00011014: 00000000
@@ -17747,7 +17747,7 @@
000111BC: 00000000
000111C0: 03030100
000111C4: 0A030A03
-000111C8: 00000020
+000111C8: 00000021
000111CC: 00000017
000111D0: 00000000
000111D4: 00000000
@@ -17891,9 +17891,9 @@
000113FC: 00000000
00011400: 00113300
00011404: 00000000
-00011408: 0FFEFFFF
+00011408: 00047E7F
0001140C: 80010880
-00011410: 60002C59
+00011410: 40002C59
00011414: 24049801
00011418: 00000000
0001141C: 00000000
@@ -18068,7 +18068,7 @@
000116C0: 00000000
000116C4: 00000000
000116C8: 00000000
-000116CC: 0000007C
+000116CC: 000000FF
000116D0: 00000000
000116D4: 00000400
000116D8: 00000000
@@ -99621,8 +99621,8 @@
00061104: 00000000
00061108: 00000000
0006110C: 00000000
-00061110: 3E040320
-00061114: 38560800
+00061110: 3E040200
+00061114: 38000300
00061118: 00000000
0006111C: 00000000
00061120: 00000000
@@ -99645,7 +99645,7 @@
00061164: 00000000
00061168: 00000000
0006116C: 00000000
-00061170: 20000602
+00061170: 20000603
00061174: 00000000
00061178: 00000000
0006117C: 00000000
@@ -99705,7 +99705,7 @@
00061254: 0CF80CF8
00061258: 00000000
0006125C: 00000000
-00061260: 00000002
+00061260: 00000003
00061264: 00000000
00061268: 00000000
0006126C: 00000000
@@ -100622,7 +100622,7 @@
000620A8: 00000001
000620AC: 00000002
000620B0: 00000140
-000620B4: 00002042
+000620B4: 00002063
000620B8: 00000000
000620BC: 18560010
000620C0: 00000000
@@ -115937,7 +115937,7 @@
00070FF4: 00000000
00070FF8: 00000000
00070FFC: 00000000
-00071000: 00000172
+00071000: 00000286
00071004: 834C0384
00071008: C0000000
0007100C: 00000000
@@ -115953,9 +115953,9 @@
00071034: 00000000
00071038: 00000000
0007103C: 00000000
-00071040: 0001218C
+00071040: 00012784
00071044: 00000004
-00071048: 56CAB03B
+00071048: 5893BC94
0007104C: 4C8BF9B3
00071050: 00000000
00071054: 00000000
Here's what the docs say:
2030, 2034: ring buffer head/tail
2074: Active head pointer register
20AC: Interrupt Status Register (ISR)
2218: Reserved
2358, 235C: TIMESTAMP
1xxxx: MCHBAR aperture
61110: PORT_HOTPLU_EN
61114: PORT_HOTPLU_STAT
61170: UDI_IF_CTL (UDI InfoFrame Control)
61260: BLM_HIST_CTL (Image BLM Histogram Control Register)
620B4: Reserved (for High Definition?)
71000: PIPEB_DSL (Pipe B Display Scan Line Count)
71040: PIPEBFRAMEH: Pipe B Frame Count High
71048: Reserved
Any ideas?
Thanks,
Andy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-11-06 20:25 ` Andrew Lutomirski
@ 2009-11-06 21:57 ` Jesse Barnes
2009-11-10 14:42 ` Andrew Lutomirski
0 siblings, 1 reply; 15+ messages in thread
From: Jesse Barnes @ 2009-11-06 21:57 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: intel-gfx, linux-kernel, dri-devel
On Fri, 6 Nov 2009 15:25:26 -0500
Andrew Lutomirski <luto@mit.edu> wrote:
> Here's what the docs say:
>
>
> 2030, 2034: ring buffer head/tail
> 2074: Active head pointer register
> 20AC: Interrupt Status Register (ISR)
> 2218: Reserved
> 2358, 235C: TIMESTAMP
>
> 1xxxx: MCHBAR aperture
>
> 61110: PORT_HOTPLU_EN
> 61114: PORT_HOTPLU_STAT
> 61170: UDI_IF_CTL (UDI InfoFrame Control)
>
> 61260: BLM_HIST_CTL (Image BLM Histogram Control Register)
>
> 620B4: Reserved (for High Definition?)
>
> 71000: PIPEB_DSL (Pipe B Display Scan Line Count)
> 71040: PIPEBFRAMEH: Pipe B Frame Count High
> 71048: Reserved
>
> Any ideas?
Thanks, that helps. It doesn't look like the documented ones would
have much effect (maybe hotplug enable bits?), I'll have to look
through the MCHBAR differences to see if there's anything there we
should worry about.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [resend] i915: high power consumption after suspend/resume
2009-11-06 21:57 ` Jesse Barnes
@ 2009-11-10 14:42 ` Andrew Lutomirski
0 siblings, 0 replies; 15+ messages in thread
From: Andrew Lutomirski @ 2009-11-10 14:42 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx, linux-kernel, dri-devel
Just to confuse matters further, the following patch does *not* help.
Even with this patch applied, power consumption often goes high when
resuming, and writing 1 to i915_wedged after fully resuming fixes it.
I now officially have no clue what's going on. Maybe there's
something wrong with the i915 resume code that increases power
consumption.
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f436ec..71472a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -99,11 +99,28 @@ static int i915_resume(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
int ret = 0;
+ u8 gdrst;
+ unsigned long timeout;
+
if (pci_enable_device(dev->pdev))
return -1;
pci_set_master(dev->pdev);
+ pci_read_config_byte(dev->pdev, GDRST, &gdrst);
+ pci_write_config_byte(dev->pdev, GDRST, gdrst | GDRST_RENDER);
+ udelay(50);
+ //pci_write_config_byte(dev->pdev, GDRST, gdrst & 0xfe);
+
+ /* ...we don't want to loop forever though, 500ms should be plenty */
+ timeout = jiffies + msecs_to_jiffies(500);
+ do {
+ udelay(100);
+ pci_read_config_byte(dev->pdev, GDRST, &gdrst);
+ } while ((gdrst & 0x1) && time_after(timeout, jiffies));
+ printk(KERN_INFO "i915: Reset on resume took %d ms\n",
+ jiffies_to_msecs(jiffies - timeout + msecs_to_jiffies(500)));
+
i915_restore_state(dev);
intel_opregion_init(dev, 1);
--Andy
^ permalink raw reply related [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-11-10 14:42 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-03 16:39 i915: high power consumption after suspend/resume Andrew Lutomirski
2009-10-03 16:50 ` [resend] " Andrew Lutomirski
2009-10-05 16:21 ` Jesse Barnes
2009-10-08 3:44 ` Andrew Lutomirski
2009-10-29 16:47 ` Jesse Barnes
2009-10-29 17:22 ` Andrew Lutomirski
2009-10-29 17:40 ` Andrew Lutomirski
2009-10-30 6:25 ` Andrew Lutomirski
2009-10-30 15:37 ` Jesse Barnes
2009-10-30 18:55 ` Andrew Lutomirski
2009-11-05 4:00 ` Andrew Lutomirski
2009-11-05 16:28 ` Jesse Barnes
2009-11-06 20:25 ` Andrew Lutomirski
2009-11-06 21:57 ` Jesse Barnes
2009-11-10 14:42 ` Andrew Lutomirski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.