Bug 30738 - [Arrandale switchable] resume from suspend does not wake up display properly
[Arrandale switchable] resume from suspend does not wake up display properly
Status: RESOLVED NOTOURBUG
Product: DRI
Classification: Unclassified
Component: DRM/Intel
DRI git
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: Jesse Barnes
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-09 12:39 UTC by Adam Williamson
Modified: 2011-02-16 10:36 UTC (History)
6 users (show)

See Also:


Attachments
/var/log/messages after resume (82.09 KB, application/octet-stream)
2010-10-09 12:41 UTC, Adam Williamson
no flags Details
Xorg.0.log after attempt to resume (60.15 KB, text/plain)
2010-10-09 12:42 UTC, Adam Williamson
no flags Details
Take down DP link (1.85 KB, patch)
2010-10-09 15:10 UTC, Chris Wilson
no flags Details | Splinter Review
messages after resume (with "drm/i915/dp: down the DP link even if the reg indicates it's already down" patch) (373.87 KB, text/plain)
2010-10-10 11:31 UTC, Adam Williamson
no flags Details
Xorg.0.log after attempt to resume (with drm/i915/dp: down the DP link even if the reg indicates it's already down patch) (56.46 KB, text/plain)
2010-10-10 11:31 UTC, Adam Williamson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Williamson 2010-10-09 12:39:10 UTC
The system here is a Sony Vaio Z VPCZ1 - the same as was at issue in https://bugs.freedesktop.org/show_bug.cgi?id=29141 .

I built a kernel from the current drm-intel-next tree to test the fixes for that bug. With that kernel I can now boot with the Intel graphics chipset, whereas I couldn't before. However, on resume from suspend, the display does not wake up properly. The backlight comes on but the screen remains blank. I cannot switch to a VT either.

The system is running and I can connect to it via ssh. Running xrandr via ssh shows this:

[adamw@vaioz ~]$ DISPLAY=:0 xrandr
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192
(null)1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 291mm x 164mm
   1600x900       59.9*+   40.0  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)

That (null)1 looks odd, I haven't checked if that's also what it says when it's working okay before suspend.

I will attach /var/log/messages with drm.debug=14 and /var/log/Xorg.0.log . I suspended the system around 12:32:25 and resumed around 12:33.
Comment 1 Adam Williamson 2010-10-09 12:41:59 UTC
Created attachment 39312 [details]
/var/log/messages after resume
Comment 2 Adam Williamson 2010-10-09 12:42:28 UTC
Created attachment 39313 [details]
Xorg.0.log after attempt to resume
Comment 3 Adam Williamson 2010-10-09 12:48:25 UTC
I tested, and yeah, it does refer to the output as (null)1 even when it's working before I suspend. Seems like a bug in itself.
Comment 4 Michael Zugelder 2010-10-09 13:16:00 UTC
I was about to file a similar bug report, but a day later this issue was already fixed. Presumably those fixes aren't merged into intel-drm-next yet.

My current kernel with working suspend:
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel
branch: edp-fixes
commit: 0c942e6cb80e3219da3e4ae168664e0f44aa91fe
Comment 5 Chris Wilson 2010-10-09 15:10:11 UTC
Created attachment 39315 [details] [review]
Take down DP link

This is the patch Jesse applied to make suspend work on his Vaio. Can you give it a test?
Comment 6 Adam Williamson 2010-10-10 11:29:12 UTC
Nope, that's not enough, still fails. Attaching new logs. I guess I'll try just building a kernel from the edp-fixes branch, it looks like it has a lot of stuff that isn't in drm-intel-next yet.
Comment 7 Adam Williamson 2010-10-10 11:31:06 UTC
Created attachment 39325 [details]
messages after resume (with "drm/i915/dp: down the DP link even if the reg indicates it's already down" patch)

suspend is at 11:26:15, resume at 11:27:44.
Comment 8 Adam Williamson 2010-10-10 11:31:51 UTC
Created attachment 39326 [details]
Xorg.0.log after attempt to resume (with drm/i915/dp: down the DP link even if the reg indicates it's already down patch)
Comment 9 Adam Williamson 2010-10-10 12:22:52 UTC
OK, so I built direct from jesse's edp-fixes tree and suspend/resume works. Looks like it needs some of the other commits too. Should I close this or wait till it's moved into the drm-intel-next queue?
Comment 10 Jesse Barnes 2010-10-11 12:07:54 UTC
Does this fix the suspend/resume problem?

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8e019c8..a3e8a21 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -919,6 +919,7 @@ static void intel_dp_prepare(struct drm_encoder *encoder)
 
        if (is_edp(intel_dp)) {
                ironlake_edp_backlight_off(dev);
+               ironlake_edp_panel_off(dev);
                ironlake_edp_panel_on(intel_dp);
                if (!is_pch_edp(intel_dp))
                        ironlake_edp_pll_on(encoder);
Comment 11 Adam Williamson 2010-10-11 15:24:15 UTC
hey, jesse. As I said in my last comment, with your edp-fixes branch it works fine. are you trying to isolate the patch needed to fix it against drm-intel-next? do you want me to try a drm-intel-next build with just that patch added? not sure what you need to check, let me know :) thanks!
Comment 12 Jesse Barnes 2010-10-11 15:27:27 UTC
Yeah, my edp-fixes branch had a patch that worked for me but not for others.  I'm hoping the patch in the last comment (against drm-intel-next) will actually fix it for everyone.
Comment 13 Adam Williamson 2010-10-11 15:34:04 UTC
ah I see - okay, will test and let you know how it works.
Comment 14 Adam Williamson 2010-10-11 17:28:35 UTC
It works, but not quite as smoothly as the edp-fixes branch. It resumes from suspend to a black screen with the cursor visible; I have to switch to a VT and back for the rest of the desktop to show up. (I have the same symptoms using the NVIDIA adapter and the nouveau driver on the same system, oddly enough). The edp-fixes branch resumes flawlessly with the desktop fully visible.
Comment 15 Jan-Hendrik Zab 2010-10-12 05:45:32 UTC
Suspend/resume works fine for me (on a VPCZ11C5E) with the patch from #10 and the drm-intel-next branch. There's no need to switch to VT and back for me. Userspace is a current Ubuntu 10.10.

It also works with the current edp-fixes branch (head is the patch against the flickering) from Jesses repository.
Comment 16 Adam Williamson 2010-10-12 09:21:14 UTC
I may not have been testing entirely rigorously, there may be other factors involved - at the time I had multiple results to the same effect with both kernels, but since then I've seen at least one resume-to-black-with-cursor with the edp-fixes kernel. So it may just be random and I got a string of oddly consistent results at first, or it may depend on something else (may be to do with metacity vs compiz vs gnome-shell, actually). So I guess discount my finding unless I can confirm it more carefully.
Comment 17 marvin 2010-10-18 16:02:58 UTC
suspend/resume works for me with:
repo: ickle/drm-intel.git branch: drm-intel-next
and the patch from comment #10 applied

Sony Vaio VPCZ11Z9E

it's the first time resume worked, thx!
Comment 18 Jan-Hendrik Zab 2010-11-16 07:34:20 UTC
(In reply to comment #15)
> Suspend/resume works fine for me (on a VPCZ11C5E) with the patch from #10 and
> the drm-intel-next branch. There's no need to switch to VT and back for me.
> Userspace is a current Ubuntu 10.10.
> 
> It also works with the current edp-fixes branch (head is the patch against the
> flickering) from Jesses repository.

This is again broken for me on next (a17577c942e774520ca61479e1e48a232b1e27d7) and fixes (1bb95834bbcdc969e477a9284cf96c17a4c2616f), but adding the line from #c10 still fixes the problem.
Comment 19 marc 2011-01-08 08:23:34 UTC
So why is Jesse's patch (comment 10) not in linux 2.6.37 nor in linux-next?
Did I miss something?
Comment 20 manuelcarro 2011-01-21 14:12:22 UTC
(In reply to comment #18)
> (In reply to comment #15)
> > Suspend/resume works fine for me (on a VPCZ11C5E) with the patch from #10 and
> > the drm-intel-next branch. There's no need to switch to VT and back for me.
> > Userspace is a current Ubuntu 10.10.
> > 
> > It also works with the current edp-fixes branch (head is the patch against the
> > flickering) from Jesses repository.
> 
> This is again broken for me on next (a17577c942e774520ca61479e1e48a232b1e27d7)
> and fixes (1bb95834bbcdc969e477a9284cf96c17a4c2616f), but adding the line from
> #c10 still fixes the problem.

Suspend / resume is also broken for me in drm-intel-next (fe4402931e43e81a4129eba41d05cf8907603af5) even after adding #c10.  Jesse's edp-2 branch works fine in this respect. I have a dell e6510 with an HD panel but *not* with switchable graphics.  What happens to my laptop is that the backlight is not switched on after resuming.  It can be activated with the keyboard backlight controls, but it stays in the console and alt-f7 does not take me to the X server display.  I was wondering whether it could be due to some suspend / resume script not making some critical call?
Comment 21 manuelcarro 2011-01-30 09:55:55 UTC
(In reply to comment #20)\
 
> Suspend / resume is also broken for me in drm-intel-next
> (fe4402931e43e81a4129eba41d05cf8907603af5) even after adding #c10.  Jesse's
> edp-2 branch works fine in this respect. I have a dell e6510 with an HD panel
> but *not* with switchable graphics.  What happens to my laptop is that the
> backlight is not switched on after resuming.  It can be activated with the
> keyboard backlight controls, but it stays in the console and alt-f7 does not
> take me to the X server display.  I was wondering whether it could be due to
> some suspend / resume script not making some critical call?


Further information at https://bugs.freedesktop.org/show_bug.cgi?id=33439#c17
Comment 22 Jesse Barnes 2011-01-31 10:19:41 UTC
I think we're in upstream bug territory now...    Something is going awry with the ACPI/backlight handling code.  Fortunately everything else seems to be coming back ok.
Comment 23 Jesse Barnes 2011-02-10 12:17:13 UTC
Does https://patchwork.kernel.org/patch/499221/ help?
Comment 24 manuelcarro 2011-02-11 11:01:12 UTC
(In reply to comment #23)
> Does https://patchwork.kernel.org/patch/499221/ help?

Seems to work (in a E6510 with intel graphics only).  I patched it against drm-intel-next, but could not try it a lot, since that branch is right now in a very unstable state; the X server crashes very  frequently.
Comment 25 Jesse Barnes 2011-02-11 11:05:57 UTC
hm drm-intel-next has been ok for me, aside from wireless crashes (using the brcm80211 staging driver), but either way that's a separate bug, can you file it along with whatever info you can collect?
Comment 26 Jesse Barnes 2011-02-16 10:36:43 UTC
Ok, I guess this is one of the non-gfx suspend/resume bugs.  Any runtime hangs should be reported as separate bugs.