[Bug 64605] New: ChromeOS: display doesn't turn on after resume on Sandy Bridge and Ivy Bridge platforms

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64605

          Priority: medium
            Bug ID: 64605
          Assignee: intel-gfx-bugs at lists.freedesktop.org
           Summary: ChromeOS: display doesn't turn on after resume on
                    Sandy Bridge and Ivy Bridge platforms
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
          Severity: critical
    Classification: Unclassified
                OS: Linux (All)
          Reporter: josh at freedesktop.org
          Hardware: All
            Status: NEW
           Version: unspecified
         Component: DRM/Intel
           Product: DRI

ChromeOS bug: http://code.google.com/p/chromium/issues/detail?id=221562

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.
"""

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20130514/7b53b1ea/attachment.html>