Created attachment 60708 [details] intel_reg_dumper output before entering suspend Bug description: (Sandy Bridge/Cougar Point): After resume from S3, backlight of the embedded panel is not re-enabled. The system has a second external DP and a monitor connected there lights up fine. HP did internal Display Port aux-channel analysis and everything looked fine. However, in direct testing of the signals on the motherboard, we discovered that one of the signals out of Cougar Point is not present. Here is description from our DP engineer: While running Linux (several distros with recent kernels), on a Z1 system with an internal eDP panel and an external DP monitor attached, the system is put into Suspend (S3) from the shutdown dialog. After the system is asleep for a while, wake up the system by pressing the space bar. When the system returns, the eDP panel is blank and the external monitor has video displayed. After capturing the DP AUX channel on the eDP port to the internal eDP panel, the trace shows that the panel was active and trained with no problems and data was being output to the eDP panel. The back light circuit was then checked and found that the BKLT_PWM signal is de--asserted (low). The backlight circuit for the eDP panel is controlled by the BKLT_EN and BKLT_PWM signals from the PCH (CougarPoint). It looks like the Linux driver is not handling the return from S3 properly by not asserting the BKLT_PWM signal. HP has filed a sighting with Intel: AS-1203-00F0 This platform uses DP Port D for the eDP path. Desktop-type Sandy Bridge processors are used. The problem occurs on both x86 and x86_64 versions of the OS, but mostly we test with x86_64. It occurs in both run state 5 (X server) and run state 3 (text mode). For purposes of this bugzilla, we reproduced using OpenSUSE 12.1 with a 3.4-rc3 kernel (built by Takashi Iwai) applied. Rodrigo Vivo requested that we file this to freedesktop.org. As outlined in the guide for suspend/resume issues, I am attaching log files from exercising the issue in run state 3. An interesting aspect of this issue is that a successful entry into Hibernate reactivates the eDP backlight ON THE WAY IN. So I've attached log files from after executing "echo disk >/sys/power/state" when the system had returned from S3, the eDP panel was unlit, but the external DP monitor was active. System environment: -- CPU: i3-2120 -- chipset: Intel Corporation 6 Series/C200 Series (Workstation C206) -- system architecture: 64-bit -- xf86-video-intel: info here is for the X.Org module from intel_drv.so: compiled for 1.10.4, module version = 2.16.0 -- xserver: X.Org X Server 1.10.4 -- mesa: OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop OpenGL version string: 2.1 Mesa 7.11 -- libdrm: could not find pkg-config info; RPM version: libdrm-2.4.26-15.1.2.x86_64 -- kernel: 3.4.0-rc3-3-default -- Linux distribution: OpenSUSE 12.1 plus kernel listed above -- Machine or mobo model: HP Z1 all-in-one workstation -- Display connector: display A: eDP on port D display B: external DP monitor Reproducing steps: 1. Configure system with eDP panel plus external DP monitor. 2. Boot system into state 3. 3. At this point, text console is active on both displays. 4. Go to suspend state by "echo mem >/sys/power/state". 5. System will enter S3 and power button will flash. 6. Press power button briefly or touch keyboard to start resume. 7. When recovered, the external monitor will be active but the eDP panel will be black (no backlight). Additional info: Run state 5 log files can be provided if requested.
Created attachment 60709 [details] dmesg output before entering suspend
Created attachment 60710 [details] intel_reg_dumper out after resume (backlight is off)
Created attachment 60711 [details] dmesg after resume (backlight is off)
Created attachment 60712 [details] intel_reg_dumper output after hibernate/wake (backlight is on)
Created attachment 60713 [details] dmesg after hibernate/wake (backlight went on before S4)
Created attachment 60714 [details] VBIOS dump (warning: not plain text, but guide said to say so)
Looks like the backlight is being clobbered by ACPI/video.
In a 3.4-rc2 kernel I built from source, I threw in an extra logging message in the acpi video area, after I saw that LNXVIDEO "restoring backlight" message. Since the code runs a loop to search for devices that have backlight support, I put the message where it would tell me if it found one. It did not indicate that it had found such a device. I know that the system BIOS for this platform provides the _BCL method but not _BCM, which is technically an ACPI 4.0 violation. However, I am certainly not an expert in this so I will defer to those who understand the code paths better.
(In reply to comment #8) > I know that the system BIOS for this platform provides the _BCL method but not > _BCM, which is technically an ACPI 4.0 violation. That doesn't jive with my reading of the ACPI video code, you shouldn't be seeing the "Restoring backlight state" unless you had both _BCL and _BCM. Can we get the DSDT from this system? Should be in either /proc/acpi or /sys/firmware/acpi depending on what kernel you're running.
Created attachment 61053 [details] output of acpidump for this platform
Created attachment 61054 [details] DSDT.dat (from acpiextract on previous file)
Created attachment 61055 [details] disassembled DSDT This is the disassembled DSDT that I got using a build of iasl I did. If your results differ, that would be very interesting...
Today I tested with two newer kernels: * 3.4.0-rc5 from kernel.org, and * drm-intel-next-queued (cloned drm-intel from freedesktop on 2012-05-03, then checked out the branch). Both of these kernels exhibit the same behavior, backlight not on after resuming after suspend, but it does turn back on while entering hibernate.
Shot in the dark: Can you try the linked patch on top of drm-intel-next-queued? https://bugs.freedesktop.org/attachment.cgi?id=60102
Built the drm-next kernel with the change and installed on a different OS base than OpenSUSE. The behavior around coming back from S3 did not change, except that there were kernel backtraces from ironlake_edp_panel_off and intel_dp_check_edp. I'm now building to install on OpenSUSE. I will attach system log from run state 3 suspend when I've got that tested. Say the ACPI video module is involved somehow. Is there a boot option to disable that functionality? Or at least could I rebuild the kernel without it, without dropping all ACPI support?
Created attachment 61241 [details] system log from test with patch from comment 14 Applied drm-intel-next-queued kernel plus patch referenced in comment 14, to OpenSUSE. Same behavior as usual regarding backlight. Tested in run state 3, system log attached. Observe tracebacks involving a couple of eDP-related routines in the log.
> Observe tracebacks involving a couple of eDP-related > routines in the log. Yeah, that's expected because the patch is just a Quick Hack. We'll need to dig in a different direction then ...
Rui, is this related to ACPI?
For what it's worth, I just tried kernel 3.4-rc5 with acpi_backlight=vendor and acpi_backlight=video. The behavior was the same on this platform in both cases.
Another interesting and promisng observation: Running in the Gnome interface (SLED 11 SP2 OS base in this case) with a new-enough kernel (e.g. drm-intel-next-queued as of a few days ago, or 3.4-rc5), the gnome power management applet shows a brightness control. I touched that slider while the backlight was off after coming back from S3 and voilà, it came back on. I'm not sure the levels of brightness that can be set are in any way related to the levels that the ACPI method describes. Is this control accessing some DRM functionality that is separate?
Ok, I've created some patches that might affect backlight control, available at http://cgit.freedesktop.org/~danvet/drm/log/?h=backlight-confusion Git link is git://people.freedesktop.org/~danvet/drm backlight-confusion Please test them, thanks.
Hello. I'll be out of the office from May 31 through June 11. I'll respond to your message as soon as I can. Thanks. John Sundragon Waitz
We finally received HP Z1 here and could reproduce the problem (originally reported for SLED11-SP2). In SLE11-SP2, there was a known issue that it doesn't include the intel_backlight support. After backporting the patch, the problem still remains. As John already suggested, however, this is a matter of the uninitialized backlight level. After S3 with the blank screen, running below recovers the screen. % echo 4882 > /sys/class/backlight/intel_backlight/brightness I tested the patch below and it actually works. So, my rough guess is that restoring BLC_PWM_CPU_CTL register was too early at resume, and it didn't activate the actual backlight on hardware.
Created attachment 63226 [details] [review] Test fix patch
Regarding Dan Vetter's backlight-confusion patch: Sorry for the long delay in responding to the test request. I fetched the tar.gz of the entire backlight-confusion kernel source and built it in a SLED 11 SP2 64-bit environment, using a .config I had used with 3.4.0-rc5, as a starter for "make oldconfig". The resulting kernel identifies as 3.4.0-1.2 I tested with a Sandy Bridge processor installed. This build loads i915 and the X server starts at full resolution when the system is run with the eDP panel alone. After a suspend, the screen is black and it appears the backlight is not on. I have not collected logs. After a hibernate, the backlight is on and things appear normal. The X server does not seem to be acting right on the target platform, when a non-matching external DP monitor is attached or hot-plugged. In that configuration, the eDP panel displays the text log during initial OS boot (or in run state 3), but goes kinda-blank once the X server starts. The eDP backlight is on but the video pattern looks like there is a timing problem, lots of barely-perceptible vertical stripes. The Xorg.0.log file contains mentions of lots of modelines obtained from the second display, that the eDP panel does not support, and it may be using one of those. But my xorg.conf is supposed to be forcing mirrored screens at a resolution that both displays support. Other kernels play just fine with that setup. The kernel is fine on a Sandy Bridge system with a normal DP connection to one monitor. Perhaps I did not build the kernel correctly. I could simply apply the source patch to a kernel that was already working on the target system. Or maybe the Xorg driver needed a change to go with the kernel? In other news: I have also tested Takashi Iwai's proposed patch in SLED 11 SP2, via a kernel module provided in binary. I know discussion is currently going on via email about the right approach for the general patch, and his initial change may not be the final one that is agreed to. The initial form of the patch worked for me, and I'm willing to test again with the resolution of the patch discussion. Given this, should I also pursue issues with the backlight-confusion patch from comment 21? I could collect and attach system (DRM) and Xorg logs if we want to pursue the problem.
After more investigation, we found more likely culprit. It's the order of BLC_PWM_CPU_CTL* registers restoration. More discussions on LKML are found at: http://lists.freedesktop.org/archives/intel-gfx/2012-June/018418.html The revised fix patch in Daniel's tree is below.
Created attachment 63506 [details] [review] Revised fix patch
A patch referencing this bug report has been merged in Linux v3.5-rc5: commit 6db65cbb941f9d433659bdad02b307f6d94465df Author: Takashi Iwai <tiwai@suse.de> Date: Thu Jun 21 15:30:41 2012 +0200 drm/i915: Fix eDP blank screen after S3 resume on HP desktops
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.