[Bug 86268] [BSW regression] eDP goes black after running tesdisplay

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Nov 20 18:23:07 PST 2014


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

Li Xu <li.l.xu at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |ASSIGNED

--- Comment #10 from Li Xu <li.l.xu at intel.com> ---
(In reply to Brian Lovin from comment #9)
> Here's what I've found for the bad commit; it appears to be in the middle of
> a patch series Ville commited - Someone will have to take a look at what's
> going on.
> 
> 093e3f134e2eff13503f708b81aecc2501e7aecb is the first bad commit
> commit 093e3f134e2eff13503f708b81aecc2501e7aecb
> Author: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Date: Thu Oct 16 21:27:33 2014 +0300 
> 
> drm/i915: Hold the pps mutex across the whole panel power enable sequence
> 
> 
> This commit doesn't revert cleanly on drm-intel-testing from 11/7, which was
> all I had time to test for now.

We have tried with Brian's result, and find it can light up ,and after
testdisplay screen can light up.

I finished the bisect, the result is following:
baa4e575d6a18dcd6f2e622784aa16ab24024f09 is the first bad commit
commit baa4e575d6a18dcd6f2e622784aa16ab24024f09
Author: Ville Syrjälä <ville.syrjala at linux.intel.com>
Date:   Mon Oct 27 16:07:32 2014 +0200

    drm/i915: Enable pipe-a power well on chv

    It seems that the pipe-a power well has replaced the disp2d power well
    on chv. At least that's the case with the current punit firmware. So
    enable the pipe-a power and expand its domains to cover everything the
    disp2d well ought to cover.

    The other power wells (apart from the cmnlane wells) still seem awol
    in the current punit firmware. So leave them disabled in the code.

    This fixes a hilarious oops during resume on bsw where
    intel_hdmi_get_config() would read the port register and get back
    0xffffffff and thus think the port is enabled on pipe D. It would then
    go and index the pipe_to_crtc_mapping[] array with PIPE_D and blow up
    when intel_hdmi_get_config() tries to write to crtc->config. Someone
    really ought to replace all naked pipe_to_crtc_mapping[] uses with the
    appropriate function call so we could add a warning there if the pipe
    doesn't actually exist...

    We must also call the power seqeuencer state reset function from
    the pipe-a well disable just like we do from disp2d on vlv. Otherwise
    the eDP panel won't recover at resume time since the PPS has lost its
    hold on the port.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84903
    Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
    Reviewed-by: Jesse Barnes <jbarnes at virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list 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/20141121/2edd4629/attachment.html>


More information about the intel-gfx-bugs mailing list