Bug 29791

The machine came from zhenyu.

Created attachment 38277 [details]
dmesg information

Does the edp-testing branch from git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git work?

(In reply to comment #3)
> Does the edp-testing branch from
> git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git work?

The kernel doesn't work. There is no error during install the kernel, but when boot up with it, just display "request_modules....." on screen.

(In reply to comment #4)
> (In reply to comment #3)
> > Does the edp-testing branch from
> > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git work?
> 
> The kernel doesn't work. There is no error during install the kernel, but when
> boot up with it, just display "request_modules....." on screen.

Sounds like a mis-installation of the new kernel. Can you recompile [for reference Jesse's eDP patches are included in http://cgit.freedesktop.org/~ickle/drm-intel/ ] and check that you have not only installed the modules and the kernel, but also built the initramfs (if you use one).

I recompiled the kernel on both Jesse's edp-testing branch and Chris's drm-intel-fixes branch. The issue still exists with two kernels, black screen and able to login with ssh.

Using [SNB] as the tag for bugs specific to Sandybridge hardware.

The issue still exists in (drm-intel-next)kernel-2.6.36-rc8 and (drm-intel-fixes)2.6.36-rc7

Promoting to P1, as this may indicate all SNB eDP machines broken.

Now zhenyu owns this machine.

an update: commit in the original report has been reverted.

(In reply to comment #10)
> an update: commit in the original report has been reverted.

So does it work with the latest code?

Yi, please try this patch:

From: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue, 14 Dec 2010 13:14:07 -0800
Subject: [PATCH] drm/i915: unconditionally unlock panel regs

In the panel_on function we skip everything if the panel is already
powered up.  However, if it's powered up but not unlocked, subsequent
register writes may fail.

So unlock the regs regardless of the panel state to allow other mode
setting programming to occur normally.

[Still waiting to hear from bug reporters & testers on this one, but
it does get my Vaio working again, with or without the eDP VBT patch
reverted.]

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
 drivers/gpu/drm/i915/intel_dp.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f74a706..ddfd585 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -818,17 +818,21 @@ static bool ironlake_edp_panel_on (struct intel_dp *intel_dp)
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	u32 pp, idle_on_mask = PP_ON | PP_SEQUENCE_STATE_ON_IDLE;
 
+	/* Always unlock the protected regs so other writes work */
+	pp = I915_READ(PCH_PP_CONTROL);
+	pp |= PANEL_UNLOCK_REGS;
+	I915_WRITE(PCH_PP_CONTROL, pp);
+	POSTING_READ(PCH_PP_CONTROL);
+
 	if (I915_READ(PCH_PP_STATUS) & PP_ON)
 		return true;
 
-	pp = I915_READ(PCH_PP_CONTROL);
-
 	/* ILK workaround: disable reset around power sequence */
 	pp &= ~PANEL_POWER_RESET;
 	I915_WRITE(PCH_PP_CONTROL, pp);
 	POSTING_READ(PCH_PP_CONTROL);
 
-	pp |= PANEL_UNLOCK_REGS | POWER_TARGET_ON;
+	pp |= POWER_TARGET_ON;
 	I915_WRITE(PCH_PP_CONTROL, pp);
 	POSTING_READ(PCH_PP_CONTROL);

(In reply to comment #0)
> As soon as kernel boot up, the screen trun to black. But we can use ssh to
> login the machine. 
> With bisect, we found the culprit commit is as following:
> 
> commit 5620ae29f1eabe655f44335231b580a78c8364ea
> Author:     Jesse Barnes <jbarnes@virtuousgeek.org>
> AuthorDate: Mon Jul 26 13:51:22 2010 -0700
> Commit:     Linus Torvalds <torvalds@linux-foundation.org>
> CommitDate: Mon Jul 26 15:34:16 2010 -0700
> 
>     drm/i915: make sure we shut off the panel in eDP configs
> 
>     Fix error from the last pull request.  Making sure we shut the panel off
>     is more correct and saves power.
> 
>     Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> Signed-off-by: Linus Torvalds torvalds@linux-foundation.org


I did trace on this issue. It seems that the link training sequence is failed. For the CR phase, the LANEx_CR_DONE bits are always 0 but not 1. The EQ phase failed, too. 

First, I checked this issue on 35-rc6 with the above commit reverted, then all is good: I can see the LANEx_CR_DONE bits are set and EQ is Ok. 

Then, I undo the above revert, the screen is black when i915 is loaded. I can see the LANEx_CR_DONE bits are always 0. 

So, what stuff stop sink device setting those LANEx_CR_DONE bits? The above commit? I doubt it, since even though I revert that commit on an upstream kernel, I still get a black screen.

Jesse, any ideas?

Thanks.

Yeah DP training doesn't seem to interact very well with the panel sequencer.  I've seen what look like random failures with or without the panel power applied (both VDD AUX override and normal).  I don't really understand it; it could be that we really do need to avoid doing any AUX handshaking for eDP and use the VBT provided values (as a previous patch for my Vaio did), but to do that we need to parse that data correctly...

Reducing prio; doesn't affect all SNB machines.  It would be nice to have some test hardware here...

Update:

Jesse has a patch to fix this issue.


--

Intel-gfx] [PATCH] drm/i915: skip FDI & PCH enabling for DP_A 						

eDP on the CPU doesn't need the PCH set up at all, it can in fact cause
problems.  So avoid FDI training and PCH PLL enabling in that case.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
 drivers/gpu/drm/i915/intel_display.c |   97 +++++++++++++++++++++-------------
 1 files changed, 60 insertions(+), 37 deletions(-)

(In reply to comment #16)
> Update:
> 
> Jesse has a patch to fix this issue.
> 
> 
> --
> 
> Intel-gfx] [PATCH] drm/i915: skip FDI & PCH enabling for DP_A                   
> 
> eDP on the CPU doesn't need the PCH set up at all, it can in fact cause
> problems.  So avoid FDI training and PCH PLL enabling in that case.
> 
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> ---
>  drivers/gpu/drm/i915/intel_display.c |   97 +++++++++++++++++++++-------------
>  1 files changed, 60 insertions(+), 37 deletions(-)

This patch has been pushed to drm-intel-staging, so mark as fixed.

--
commit 8002e2cc32dc471e6663b7b2a0af1d17274ebdf8
Author:     Jesse Barnes <jbarnes@virtuousgeek.org>
AuthorDate: Wed Jan 5 10:31:48 2011 -0800
Commit:     Chris Wilson <chris@chris-wilson.co.uk>
CommitDate: Thu Jan 6 12:13:41 2011 +0000

    drm/i915: skip FDI & PCH enabling for DP_A

    eDP on the CPU doesn't need the PCH set up at all, it can in fact cause
    problems.  So avoid FDI training and PCH PLL enabling in that case.

    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Tested-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/intel_display.c |   97 +++++++++++++++++++++-------------
 1 files changed, 60 insertions(+), 37 deletions(-)