Bug 49712

Summary: [ILK REGRESSION]Fail to light up DP after booting
Product: DRI Reporter: Guang Yang <guang.a.yang>
Component: DRM/IntelAssignee: Daniel Vetter <daniel>
Status: CLOSED FIXED QA Contact:
Severity: critical    
Priority: high CC: ben, chris, daniel, florian, jbarnes
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
booting with DP 's dmesg info
none
The first bad commit booting dmesg info
none
last good commit booting dmesg info
none
Enable the PLL for !CPT
none
with two patchs booting dmesg info
none
fixed pch pll to pipe mapping on ibx none

Description Guang Yang 2012-05-09 18:41:12 UTC
Created attachment 61317 [details]
booting with DP 's dmesg info

System Environment:
--------------------------
Kernel: (drm-intel-testing)25fcc53b96dd4801907d9b1cc4b76258ab0f3d65
platform: ILK(E6510)

Bug detailed description:
-------------------------
   Boot the system with DP,a error will exists on the screen and the DP monitor can't linght up.
   The error is :[drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting,it will exist every few seconds.
   I try with Kernel: (drm-intel-fixes)2e7a44814d802c8ba479164b8924070cd908d6b5,
the bug doesn't occur; and the bug occurs with Kernel: (drm-intel-next-queued)38e490fea7d2885d79fcd1ca37edb64e489d470d.
Comment 1 Daniel Vetter 2012-05-10 01:41:04 UTC
Hm, the dmesg is cut off at the beginning. Can you please reproduce this again and then attach the complete dmesg? Maybe there's something interesting going on at the top (dmesg with drm.debug=0xe of course).

Another question: Which is the last known-good commit on drm-intel-next-queued where this still works? If it's newer than 083f9560cdff268e2ca8 please also attach the dmesg of the working kernel (again with drm.debug=0xe). 083f9560cdff268e2ca adds some useful debug information for DP ports, hence this could be very interesting.

Also, please start a bisect, I guess we need it here to get anywhere.
Comment 2 Guang Yang 2012-05-11 01:00:09 UTC
Created attachment 61424 [details]
The first bad commit booting dmesg info

(In reply to comment #1)
> Hm, the dmesg is cut off at the beginning. Can you please reproduce this again
> and then attach the complete dmesg? Maybe there's something interesting going
> on at the top (dmesg with drm.debug=0xe of course).
> Another question: Which is the last known-good commit on drm-intel-next-queued
> where this still works? If it's newer than 083f9560cdff268e2ca8 please also
> attach the dmesg of the working kernel (again with drm.debug=0xe).
> 083f9560cdff268e2ca adds some useful debug information for DP ports, hence this
> could be very interesting.
> Also, please start a bisect, I guess we need it here to get anywhere.

I have finished the bisect,is shows:
ee7b9f93fd96a72e5d09e2b44024c11880873c6b is the first bad commit
commit ee7b9f93fd96a72e5d09e2b44024c11880873c6b
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Apr 20 17:11:53 2012 +0100

The error refreshs on screen so fast,I get the dmesg after booting as early as possble, it may cut off a little.
Comment 3 Guang Yang 2012-05-11 01:03:56 UTC
Created attachment 61425 [details]
last good commit booting dmesg info

(In reply to comment #1)
> Hm, the dmesg is cut off at the beginning. Can you please reproduce this again
> and then attach the complete dmesg? Maybe there's something interesting going
> on at the top (dmesg with drm.debug=0xe of course).
> Another question: Which is the last known-good commit on drm-intel-next-queued
> where this still works? If it's newer than 083f9560cdff268e2ca8 please also
> attach the dmesg of the working kernel (again with drm.debug=0xe).
> 083f9560cdff268e2ca adds some useful debug information for DP ports, hence this
> could be very interesting.
> Also, please start a bisect, I guess we need it here to get anywhere.

The last good commit is:
(drm-intel-next-queued)c2798b19bac2538393fc932bfbe59807a4734b3e .
this commit is newer than 083f9560cdff268e2ca8.
Comment 4 Chris Wilson 2012-05-11 01:20:57 UTC
Can you please try with

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 8d55dc9..12dba60 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2878,6 +2878,8 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
        int pipe = intel_crtc->pipe;
        u32 reg, temp;
 
+       assert_transcoder_disabled(dev_priv, pipe);
+
        /* For PCH output, training FDI link */
        dev_priv->display.fdi_link_train(crtc);


to see if that catches the culprit behind the link training failure.
Comment 5 Chris Wilson 2012-05-13 01:55:39 UTC
Created attachment 61545 [details] [review]
Enable the PLL for !CPT
Comment 6 Guang Yang 2012-05-13 20:09:06 UTC
Created attachment 61592 [details]
with two patchs booting dmesg info

I try the two patchs before with commit 659900dd3fa07b4ddffebfff07f6ee0341988943 at drm-intel-next-queued, the error still occurs and I attach the dmesg.
Comment 7 Daniel Vetter 2012-05-19 13:36:36 UTC
Quick question: Do you only see this issue on ilk DP machines?
Comment 8 Daniel Vetter 2012-05-20 09:43:46 UTC
Created attachment 61880 [details] [review]
fixed pch pll to pipe mapping on ibx

New patch on top of latest drm-intel-next-queued which hopefully fixes the bug.
Comment 9 Guang Yang 2012-05-20 19:35:18 UTC
(In reply to comment #8)
> Created attachment 61880 [details] [review] [review]
> fixed pch pll to pipe mapping on ibx
> New patch on top of latest drm-intel-next-queued which hopefully fixes the bug.
I try the kernel with latest commit:
Kernel: (drm-intel-next-queued)98b6bd998ae057611d2bc040ace1fc847f575b84
the bug doesn't occur,fixed with that.
Comment 10 Chris Wilson 2012-05-21 03:00:52 UTC
commit 98b6bd998ae057611d2bc040ace1fc847f575b84
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 20 20:00:25 2012 +0200

    drm/i915: IBX has a fixed pch pll to pch pipe mapping
    
    This should fix breakage introduced in
    
    commit ee7b9f93fd96a72e5d09e2b44024c11880873c6b
    Author: Jesse Barnes <jbarnes@virtuousgeek.org>
    Date:   Fri Apr 20 17:11:53 2012 +0100
    
        drm/i915: manage PCH PLLs separately from pipes
    
    v2: Add a DRM_DEBUG_KMS message to explain why a given pll was
    selected, suggested by Chris Wilson.
    
    v3: Actually run git add.
    
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49712
Comment 11 Florian Mickler 2012-07-01 03:38:49 UTC
A patch referencing this bug report has been merged in Linux v3.5-rc1:

commit e7e164db6db292d6f804ec6cd25f29ff62dd0618
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri May 11 09:21:25 2012 +0100

    drm/i915: Assert that the transcoder is indeed off before modifying it
Comment 12 Florian Mickler 2012-07-01 03:43:48 UTC
A patch referencing this bug report has been merged in Linux v3.5-rc1:

commit 6f13b7b5be500178d5541b69ab911af2a77ec488
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun May 13 09:54:09 2012 +0100

    drm/i915: Enable the PCH PLL for all generations after link training
Comment 13 Elizabeth 2017-10-06 14:50:15 UTC
Closing old verified.

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.