<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - ChromeOS: display doesn't turn on after resume on Sandy Bridge and Ivy Bridge platforms"
href="https://bugs.freedesktop.org/show_bug.cgi?id=64605">64605</a>
</td>
</tr>
<tr>
<th>Assignee</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Summary</th>
<td>ChromeOS: display doesn't turn on after resume on Sandy Bridge and Ivy Bridge platforms
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Severity</th>
<td>critical
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Reporter</th>
<td>josh@freedesktop.org
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Intel
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr></table>
<p>
<div>
<pre>ChromeOS bug: <a href="http://code.google.com/p/chromium/issues/detail?id=221562">http://code.google.com/p/chromium/issues/detail?id=221562</a>
Quoting comments #12 and #13 there:
"""
Bisecting is proving difficult because the UI isn't coming up on vanilla
kernels either, need to investigate that separately as I'm pretty sure it used
to work.
I looked at this for a while with marcheu@ and it looks like this really only
works when we do a powerd_suspend because that also does a vt-switch. So,
basically all Sandy and Ivy Bridge platforms seem to be totally broken in any
of our normal resume paths, either lid suspend or idle suspend.
The new drm code appears to look at the state of the hardware and sees that the
lvds pipe and transcoder are off and doesn't attempt to set them, whereas on
the 3.4 kernel it was forcing them on at resume time. Our firmware does
nothing with respect to setting up the display hardware, and we think that the
kernel is expecting it to be set up.
specifically we're talking about __i915_drm_thaw() calling
intel_modeset_setup_hw_state() which is now looking at hardware state prior to
doing any mode setting.
"""
"""
after marcheu spoke with upstream Intel folks, it looks like the issue isn't a
firmware issue but rather that they are expecting a VT switch after suspend to
set the mode, and ChromeOS doesn't do this in normal mode on a lid close (I
believe to save time). If you just call powerd_suspend from the command line,
however, you will get a vt switch and this is why that scenario was apparently
working.
"""</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>