Bug 79610

Summary: [BDW-Y Bisected ] eDP display not light after entering the kernel.
Product: DRI Reporter: liulei <lei.a.liu>
Component: DRM/IntelAssignee: Daniel Vetter <daniel>
Status: CLOSED INVALID QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: critical    
Priority: highest CC: intel-gfx-bugs, przanoni
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg none

Description liulei 2014-06-04 02:28:21 UTC 
Created attachment 100376 [details]
dmesg

==System Environment==
--------------------------
Regression: Yes. 

Non-working platforms: BDW-Y

==kernel==
--------------------------
origin/drm-intel-nightly: 085391259463f3bda367fc3e078504d83cd8dc0e(works)
    drm-intel-nightly: 2014y-05m-29d-23h-55m-55s integration manifest
origin/drm-intel-next-queued: 192155025197cc4765702a180904c3b62c152b7a(fails)
    drm/i915: Drop locking around fbdev-fb in debugfs   
origin/drm-intel-fixes: d23db88c3ab233daed18709e3a24d6c95344117f(works)
    drm/i915: Prevent negative relocation deltas from wrapping

==Bug detailed description==
-----------------------------
Booting with eDP, monitor can't be lighted up after entering the kernel. I can't find a good commit on -next-queued

==Reproduce steps==
---------------------------- 
Boot with eDP

==Bisect results==
----------------------------
Bisect shows: 38aecea0ccbb909d635619cba22f1891e589b434 is the first bad commit:

commit 38aecea0ccbb909d635619cba22f1891e589b434
Author:     Daniel Vetter <daniel.vetter@ffwll.ch>
AuthorDate: Mon Mar 3 11:18:10 2014 +0100
Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
CommitDate: Wed Mar 5 21:30:42 2014 +0100

    drm/i915: reverse dp link param selection, prefer fast over wide again

    ... it's this time of the year again. Originally we've frobbed this to
    fix up some regressions, but maybe our DP code improved sufficiently
    now that we can dare to do again what the spec recommends.

    This reverts

    commit 2514bc510d0c3aadcc5204056bb440fa36845147
    Author: Jesse Barnes <jbarnes@virtuousgeek.org>
    Date:   Thu Jun 21 15:13:50 2012 -0700

        drm/i915: prefer wide & slow to fast & narrow in DP configs

    I'm pretty sure I'll regret this patch, but otoh I expect we won't
    make progress here without poking the devil occasionally.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73694
    Cc: peter@colberg.org
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Tested-by: Itai BEN YAACOV <candeb@free.fr>
    Tested-by: David En <d.engraf@arcor.de>
    Reported-and-Tested-by: Marcus Bergner <marcusbergner@gmail.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 1 liulei 2014-06-04 04:31:15 UTC 
At first, I didn't find a good commit. Because system always hang when I try to boot with earlier kernel. So I gave up finding a good commit. The next day, I tried again, and system hang didn't happen. So I did bisect.
Comment 2 Jani Nikula 2014-06-06 11:20:07 UTC 
CC Paulo, might be interesting to see if his patches to match recent BDW documentation updates make a difference here.
Comment 3 Guang Yang 2014-06-13 08:17:46 UTC 
Paulo, do you have any ideas about this issue.
Comment 4 Paulo Zanoni 2014-06-18 11:49:22 UTC 
(In reply to comment #3)
> Paulo, do you have any ideas about this issue.

Please test drm-intel-nightly from today.

The following commit is what we're interested in:

drm/i915: update BDW DDI buffer translations

http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=9576c27f5287f873505583350049100896a48299
Comment 5 Paulo Zanoni 2014-06-18 11:55:59 UTC 
Actually, it also looks like your Kernel doesn't include the following commit:

"drm/i915/dp: force eDP lane count to max available lanes on BDW"

I believe it should fix the problem you reported.
Comment 6 Paulo Zanoni 2014-06-18 12:03:29 UTC 
(In reply to comment #0)

> ==kernel==
> --------------------------
> origin/drm-intel-nightly: 085391259463f3bda367fc3e078504d83cd8dc0e(works)
>     drm-intel-nightly: 2014y-05m-29d-23h-55m-55s integration manifest
> origin/drm-intel-next-queued: 192155025197cc4765702a180904c3b62c152b7a(fails)
>     drm/i915: Drop locking around fbdev-fb in debugfs   
> origin/drm-intel-fixes: d23db88c3ab233daed18709e3a24d6c95344117f(works)
>     drm/i915: Prevent negative relocation deltas from wrapping
> 

Now that I re-read this, it makes even more sense to me.

It is normal and acceptable for certain things to work on drm-intel-nightly and drm-intel-fixes but fail on drm-intel-next-queued for a certain period of time. Sometimes patches are committed directly to -fixes, so -next-queued won't include the fix until it is merged back. I don't even consider cases like this as "bugs", and I certainly wouldn't classify such a case as P1/critical.
Comment 7 Daniel Vetter 2014-06-18 12:19:24 UTC 
Failure on dinq but working on -nightly is not a bug. It simply means the bugfix hasn't been merged through dinq but some other tree. Usually -fixes to get the patch into the next -rc kernel.
Comment 8 liulei 2014-06-19 02:12:48 UTC 
(In reply to comment #7)
> Failure on dinq but working on -nightly is not a bug. It simply means the
> bugfix hasn't been merged through dinq but some other tree. Usually -fixes
> to get the patch into the next -rc kernel.

Agree with you. That makes sense. I retest and both -fixes and -nightly work well.
Comment 9 Jari Tahvanainen 2016-10-12 12:02:43 UTC 
Closing verified+invalid.

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.