Bug 10985

Summary: backlight doesn't come on after resume with i915 video
Product: Drivers Reporter: Jon Dowland (jon+bugzilla.kernel.org)
Component: Video(DRI - Intel)Assignee: Jesse Barnes (jbarnes)
Status: RESOLVED CODE_FIX    
Severity: normal CC: bunk, gordon.jin, jbarnes, kernel, mjg59-kernel, sergio, sheridan.ph.hutchinson
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.26-rc8 Subsystem:
Regression: No Bisected commit-id:
Bug Depends on:    
Bug Blocks: 7216    
Attachments: output of intel_reg_dumper
output of intel_reg_dumper
diff of intel_reg_dumper output before/after a suspend
intel_reg_dumper output (and other bits) prior to suspend, in X
intel_reg_dumper output (and other bits) after suspend, in X
single user; no x; i915 loaded; before suspend
single user; no x; i915 loaded; after resume
Restore LVDS state before PLL state
intel_reg_dumper output before suspend; 2.6.26 + jesse's patch from comment #28
intel_reg_dumper output after suspend; 2.6.26 + jesse's patch from comment #28
disable panel & restore all panel state first
fix suspend/resume on x40

Description Jon Dowland 2008-06-26 02:09:20 UTC
Latest working kernel version: n/a
Earliest failing kernel version: 2.6.26-rc6
Distribution: Debian (sid)
Hardware Environment: Thinkpad X40 (82852/855GM Integrated Graphics Device)
Software Environment: n/a
Problem Description:

After performing a suspend to RAM, my laptop's backlight does not come back on. Pressing the brightness adjust keys on the laptop has no effect, neither does prodding /sys/class/backlight/thinkpad_screen/brightness,

With 2.6.25 and earlier, the software tools to manage suspend would perform quirks (S3 "bios" and "mode") which result in the backlight coming back on properly.

I first noticed this because pm-utils (the software bit that handles suspend on behalf of hal and gnome-power-manager etc.) performs a check for 2.6.26 and if found, doesn't do userspace quirking, assuming that the kernel drivers handle it all instead.

Steps to reproduce:

boot in single user mode
suspend
resume
Comment 1 Jon Dowland 2008-06-26 02:11:42 UTC
Created attachment 16633 [details]
output of intel_reg_dumper

On Matthew Garrett's advice, I booted to single user mode, and ran intel_reg_dumper (from the x86-video-intel git repo) before loading i915, afterwards, and after resuming from a suspend. This is the output from before loading i915. After is identical.
Comment 2 Jon Dowland 2008-06-26 02:12:27 UTC
Created attachment 16634 [details]
output of intel_reg_dumper

This is the output of the reg dumper after resuming from suspend, when my backlight had not resumed.
Comment 3 Adrian Bunk 2008-06-26 02:40:32 UTC
One could argue whether it's technically a kernel regression, but it should be resolved either in the kernel or in userspace before 2.6.26.
Comment 4 Rafael J. Wysocki 2008-06-26 03:23:06 UTC
Jon, could you please try suspending by

# echo mem > /sys/power/state

(obviously as root) and see what happens?
Comment 5 Jon Dowland 2008-06-26 04:58:53 UTC
I've just attempted

 * echo mem > /sys/power/state
 * pm-suspend
 * pm-suspend --quirk-s3-bios --quirk-s3-mode

with 2.6.25 and 2.6.26-rc8, both in X and without X.

In all cases, echo mem > /sys/power/state worked (with 2.6.25 and 2.6.26)

In the case of pm-suspend, only explicit quirks with 2.6.25 worked.

Does this absolve the kernel? I'm a bit puzzled.

I am now trying to figure out what pm-suspend does on top of echo mem > /sys/power/state and after resuming in my case.
Comment 6 Jon Dowland 2008-06-26 06:01:03 UTC
Hi folks, after some more digging it seems pm-suspend on my machine is back-ending to s2ram, from the uswsusp package. I haven't tried to dig into s2ram to establish why it prevents the backlight coming back up, but this suggests the kernel is fine: echo mem > ... worked fine, and pm-suspend in the absenceof s2ram works fine.

I'm sorry for wasting your time. I'm a little miffed myself (back-ending to s2ram by default if present is a debian-specific alteration to the pm-utils package, so I will have to write a similar apology to the bug there.)
Comment 7 Rafael J. Wysocki 2008-06-26 06:24:32 UTC
Actually, the problem is not only yours, because many laptops required a userland workaround quirk before 2.6.26-rc which they don't require any more and which breaks things now.

That's why the quirk was hardcoded into the s2ram whitelist and is still used by distributions.

So, as far as the kernel is concerned, this is a "will not fix" thing rather than "invalid".
Comment 8 Rafael J. Wysocki 2008-06-26 06:26:15 UTC
BTW, please just add "-f" to the s2ram's command line and things should work again.
Comment 9 Jon Dowland 2008-06-26 07:25:55 UTC
Actually, it's adding "-f" that breaks it. Invoking "s2ram" on 2.6.26 means it uses it's built-in whitelist and passes the s3 quirks. This still works for me (although the quirks are superfluous). Invoking "s2ram -f" means it doesn't check the whitelist at all. pm-utils (as patched by debian) was invoking s2ram -f, but suffixing explicitly the s3 quirks on the command line for 2.6.25, which worked, and ommitting them with 2.6.26, which (strangely) doesn't.
Comment 10 Jon Dowland 2008-07-04 07:50:05 UTC
Hi folks- back again :) Sorry about this. When I was performing my tests before, I was not doing them from a clean boot on each occasion. That means the values in /proc/sys/kernel/acpi_video_flags had been set by one method and not reset prior to trying another.

I have just performed, using 2.6.26-rc8, clean boots into single user mode, no X, the echo mem > /sys/power/state test. The backlight did not come on after resume :( I have repeated this three times.

/proc/sys/kernel/acpi_video_flags was set to 0 before and after resuming.

I shall attach the diff of the output of intel_reg_dumper before and after suspend. It appears to be larger than  last time.
Comment 11 Jon Dowland 2008-07-04 07:52:19 UTC
Created attachment 16731 [details]
diff of intel_reg_dumper output before/after a suspend

Note that I had a VGA monitor plugged into the machine for the duration of all of the three tests, from boot. At no point did anything appear on it, though (I didn't start X and I don't appear to have the BIOS configured to echo to it).
Comment 12 Rafael J. Wysocki 2008-07-04 08:15:34 UTC
Is there any difference with X?
Comment 13 Jon Dowland 2008-07-04 08:38:11 UTC
The backlight still doesn't come on. The intel regs are slightly different, because X has enabled my external display. I'm going to attach the output of the reg dumper before and after (files also include contents of acpi_video_flags and uname -a output)
Comment 14 Jon Dowland 2008-07-04 08:38:44 UTC
Created attachment 16733 [details]
intel_reg_dumper output (and other bits) prior to suspend, in X
Comment 15 Jon Dowland 2008-07-04 08:39:08 UTC
Created attachment 16734 [details]
intel_reg_dumper output (and other bits) after suspend, in X
Comment 16 Jesse Barnes 2008-07-04 10:06:50 UTC
Jon, when you booted into single user you remembered to load i915 right?  The register diffs make it look like the suspend/resume capable i915 driver wasn't loaded...
Comment 17 Jon Dowland 2008-07-05 03:29:07 UTC
Not on that last run, sorry. I've just redone them. I'll attach but here's the before/after diff for convenience:

--- regs_before.txt     2008-07-05 11:17:55.000000000 +0100
+++ regs_after.txt      2008-07-05 11:17:58.000000000 +0100
@@ -24,7 +24,7 @@
 (II):          DVOB_SRCDIM: 0x00000000
 (II):          DVOC_SRCDIM: 0x00000000
 (II):           PP_CONTROL: 0x00000001 (power target: on)
-(II):            PP_STATUS: 0xc0000008 (on, ready, sequencing idle)
+(II):            PP_STATUS: 0x4800000b (off, ready, sequencing idle)
 (II):         PFIT_CONTROL: 0x80000668
 (II):      PFIT_PGM_RATIOS: 0x00000000
 (II):      PORT_HOTPLUG_EN: 0x00000000
@@ -68,7 +68,7 @@
 (II):          DSPBTILEOFF: 0x00000000
 (II):            PIPEBCONF: 0x80000000 (enabled, single-wide)
 (II):             PIPEBSRC: 0x027f018f (640, 400)
-(II):            PIPEBSTAT: 0x80000202 (status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS)
+(II):            PIPEBSTAT: 0x80000242 (status: FIFO_UNDERRUN VSYNC_INT_STATUS LBLC_EVENT_STATUS VBLANK_INT_STATUS)
 (II):                 FPB0: 0x0003120c (n = 3, m1 = 18, m2 = 12)
 (II):                 FPB1: 0x00021207 (n = 2, m1 = 18, m2 = 7)
 (II):               DPLL_B: 0x90026000 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 2, p2 = 14)
Comment 18 Jon Dowland 2008-07-05 03:43:57 UTC
Created attachment 16744 [details]
single user; no x; i915 loaded; before suspend
Comment 19 Jon Dowland 2008-07-05 03:44:26 UTC
Created attachment 16745 [details]
single user; no x; i915 loaded; after resume
Comment 20 Rafael J. Wysocki 2008-07-06 10:55:57 UTC
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Comment 21 Jon Dowland 2008-07-06 13:38:20 UTC
Where abouts are the hw quirks in the code? I've skimmed over most of the i915* files in drivers/char/drm but nothing is jumping out of me. I doubt I'd spot a bug (nor be able to provide a fix) but I am curious :)
Comment 22 Sérgio M Basto 2008-07-06 19:28:50 UTC
(In reply to comment #5)
> I've just attempted
> 
>  * echo mem > /sys/power/state
>  * pm-suspend
>  * pm-suspend --quirk-s3-bios --quirk-s3-mode
> 
> with 2.6.25 and 2.6.26-rc8, both in X and without X.
> 
> In all cases, echo mem > /sys/power/state worked (with 2.6.25 and 2.6.26)
> 
> In the case of pm-suspend, only explicit quirks with 2.6.25 worked.
> 
> Does this absolve the kernel? I'm a bit puzzled.
> 
> I am now trying to figure out what pm-suspend does on top of echo mem >
> /sys/power/state and after resuming in my case.
> 

Noting, pm-suspend could do something more and echo mem >/sys/power/state, (has far I know).
If you say that "echo mem > /sys/power/state" works, where is the bug ? 
and if you say that pm-suspend fail in something, so it is a pm-utils bug.
isn't it ? 
IMHO
  
Comment 23 Sérgio M Basto 2008-07-07 05:28:03 UTC
I am trying marking this bug related or depend on bug 6001 and bug 9642.
Report please consider this patch http://bugzilla.kernel.org/attachment.cgi?id=14745

It is a very close problem, backlight problem with i915 drm . 

So in my H opinion I'd not consider one regression. 
Comment 24 Jon Dowland 2008-07-08 08:28:32 UTC
(In reply to comment #22)
> If you say that "echo mem > /sys/power/state" works, where is the bug

I realised by comment #10 that my tests had been flawed and in fact echo mem > /sys/power/state does not work.

(In reply to comment #23)
> Report please consider this patch
> http://bugzilla.kernel.org/attachment.cgi?id=14745

I've just tried that patch and I'm afraid my backlight still did not come on.

> So in my H opinion I'd not consider one regression. 

I'd agree with Adrian in #3 that it is not a regression since this doesn't work for 2.6.25 or earlier either.
Comment 25 Jon Dowland 2008-07-09 03:09:12 UTC
(In reply to comment #23)
> I am trying marking this bug related or depend on bug 6001 and bug 9642.
> Report please consider this patch
> http://bugzilla.kernel.org/attachment.cgi?id=14745

That patch adds a printk to acpi_video_device_query which does not appear in my dmesg so acpi_video_device_query is not called as part of my suspend sequence. I do not know if acpi_video_bus_start_devices is called or not (I shall try adding a printk to that, too).

(In reply to comment #21)
> Where abouts are the hw quirks in the code? I've skimmed over most of the
> i915*
> files in drivers/char/drm but nothing is jumping out of me.

Should I be looking at drivers/acpi/video too, then?
Comment 26 Matthew Garrett 2008-07-09 03:14:20 UTC
No, all of this should be handled entirely by the drm. The X40 doesn't have ACPI backlight control.
Comment 27 Rafael J. Wysocki 2008-07-13 11:50:07 UTC
I've dropped this bug from the list of recent regressions on the basis of Comment #24.
Comment 28 Jesse Barnes 2008-07-16 16:12:02 UTC
Created attachment 16852 [details]
Restore LVDS state before PLL state

Can you give something like this a try (it may not apply directly depending on what version you use, but it should be easy to fix).  LVDS state is supposed to be restored before the PLLs are enabled or the panel might not come up.  I hope that's the problem here...  Please let me know if this works for you.
Comment 29 Jon Dowland 2008-07-17 04:27:10 UTC
Hi - I just tried that against 2.6.26 (hunks applied against i915_drv.c). Unfortunately it didn't fix the problem. I'll attach the intel_reg_dumper output before/after as usual. This is the script I use to test:

#!/bin/sh
set -u
set -e

modprobe i915

/root/intel_reg_dumper > /root/x_regs_before.txt
uname -a > /root/BEFORE
echo acpi_video_flags: >> /root/BEFORE
cat /proc/sys/kernel/acpi_video_flags >> /root/BEFORE

echo mem > /sys/power/state

/root/intel_reg_dumper > /root/x_regs_after.txt
uname -a > /root/AFTER
echo acpi_video_flags: >> /root/AFTER
cat /proc/sys/kernel/acpi_video_flags >> /root/AFTER
dmesg >> /root/AFTER

sync
Comment 30 Jon Dowland 2008-07-17 04:28:01 UTC
Created attachment 16860 [details]
intel_reg_dumper output before suspend; 2.6.26 + jesse's patch from comment #28
Comment 31 Jon Dowland 2008-07-17 04:28:50 UTC
Created attachment 16861 [details]
intel_reg_dumper output after  suspend; 2.6.26 + jesse's patch from comment #28

Here's the diff:
--- x_regs_before.txt	2008-07-17 12:12:37.000000000 +0100
+++ x_regs_after.txt	2008-07-17 12:12:37.000000000 +0100
@@ -24,7 +24,7 @@
 (II):          DVOB_SRCDIM: 0x00000000
 (II):          DVOC_SRCDIM: 0x00000000
 (II):           PP_CONTROL: 0x00000001 (power target: on)
-(II):            PP_STATUS: 0xc0000008 (on, ready, sequencing idle)
+(II):            PP_STATUS: 0x4800000b (off, ready, sequencing idle)
 (II):         PFIT_CONTROL: 0x80000668
 (II):      PFIT_PGM_RATIOS: 0x00000000
 (II):      PORT_HOTPLUG_EN: 0x00000000
@@ -68,7 +68,7 @@
 (II):          DSPBTILEOFF: 0x00000000
 (II):            PIPEBCONF: 0x80000000 (enabled, single-wide)
 (II):             PIPEBSRC: 0x027f018f (640, 400)
-(II):            PIPEBSTAT: 0x80000202 (status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS)
+(II):            PIPEBSTAT: 0x80000242 (status: FIFO_UNDERRUN VSYNC_INT_STATUS LBLC_EVENT_STATUS VBLANK_INT_STATUS)
 (II):                 FPB0: 0x0003120c (n = 3, m1 = 18, m2 = 12)
 (II):                 FPB1: 0x00021207 (n = 2, m1 = 18, m2 = 7)
 (II):               DPLL_B: 0x90026000 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 2, p2 = 14)
Comment 32 Jesse Barnes 2008-07-17 14:35:30 UTC
Jon, can you try the drm tree?  It's working well on my 855 test machine and is easier for me to test/generate diffs against.

$ git clone git://git.freedesktop.org/git/mesa/drm
$ cd linux-core
$ make DRM_MODULES=i915
$ rmmod i915; rmmod drm; insmod ./drm.ko; insmod i915.ko
# suspend/resume

That should work as long as your kernel development headers are installed...

Thanks,
Jesse
Comment 33 Albert Hopkins 2008-07-18 18:16:40 UTC
I tried the git tree today on my ThinkPad R61, but the backlight did not come on.  However I also noticed that the suspend LED (the crescent moon) was still lit as well, so I'm not sure if the system is waking up or not.
Comment 34 Jon Dowland 2008-07-20 03:28:19 UTC
(In reply to comment #32)
> Jon, can you try the drm tree?  It's working well on my 855 test machine and
> is
> easier for me to test/generate diffs against.

Sure. Actually this is easier for me too. I've tried that tree (HEAD 7cfdba2b30), the backlight does not come on. Would the register dumps be useful?
Comment 35 Jesse Barnes 2008-07-21 13:01:25 UTC
Created attachment 16927 [details]
disable panel & restore all panel state first

this one tries to disable the panel first thing, since that should unlock some of the regs that we may be failing to restore.
Comment 36 Jon Dowland 2008-07-21 13:59:00 UTC
Hello; tried that patch against refs/heads/master = b5cddbcc1536 ; I'm afraid it did not fix it.
Comment 37 Jesse Barnes 2008-07-21 14:41:59 UTC
And I don't suppose the register diff changes either?
Comment 38 Jon Dowland 2008-07-22 14:43:03 UTC
I'm afraid not.

Would it be helpful if I could find other people experiencing this? I know of a few X40 owners I might convince to test this too.
Comment 39 Jesse Barnes 2008-07-22 15:22:57 UTC
Yeah it would be good to get some confirmation, but istr seeing another, similar report for another thinkpad but I don't remember the details.  I wonder if there's some ACPI call we're missing here?  The PP_STATUS regs definitely change in your config, but they're also undocumented in my 855 manual, so I wonder if there are some other bits we don't know about on this machine that are required to bring the panel back up...
Comment 40 Jesse Barnes 2008-07-22 15:27:37 UTC
Heh, now I see it was comment #33 that had the other thinkpad report.  It sounds like that's a different suspend/resume problem though, since the sleep light was still on...
Comment 41 Jon Dowland 2008-11-22 08:13:37 UTC
I've just had an email from someone who has reproduced this on a thinkpad x30.

My understanding is that Jesse has confirmed this and has access to x40 hardware now.
Comment 42 Jesse Barnes 2008-11-24 11:48:39 UTC
Right I just need to find some time to work on bugs...  I have a few more theories to test now at least, and hw.
Comment 43 Sheridan Hutchinson 2009-08-27 01:24:18 UTC
Hi,

I have a Thinkpad X40 (855 chipset) running Debian that used to parse two quirks passed to it from the GRUB command line in order for the panel to turn back on when the machine resumed from suspend (S3).

Is there any chance we could go back to the old behaviour because I've been unable to use suspend for around 6 months now :(
Comment 44 Gordon Jin 2009-09-18 02:45:31 UTC
Does this still exist now?
Comment 45 Jon Dowland 2009-09-18 12:21:43 UTC
Unfortunately I loaned out my X40. I should have it back within the next four weeks so I will try bleeding-edge drm/i915 when I get it back.
Comment 46 Jesse Barnes 2009-10-14 19:35:29 UTC
Created attachment 23409 [details]
fix suspend/resume on x40

Turns out we weren't saving & restoring a register that's important on this model.  I'm not sure how many other machines it affects...
Comment 47 Jesse Barnes 2009-12-02 19:47:04 UTC
I think this one is fixed.