Bug 61542

Summary: [HSW bisected] Desktop-EDP can not work
Product: DRI Reporter: yanbing <bingx.a.yan>
Component: DRM/IntelAssignee: Paulo Zanoni <przanoni>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: critical    
Priority: highest CC: bingx.a.yan, kan.liang, przanoni, sndirsch, tiwai, xiong.y.zhang, yangweix.shui
Version: XOrg git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
EDP-no-lightup.dmesg
none
EDP-only-firstbad.dmesg
none
EDP-oldrevert-good.dmesg
none
EDP-newrevert.dmesg
none
intel_reg_read.log
none
edp-d-intel_reg_read.log
none
current-kernel-edp-d.dmesg
none
edp can't work on dell AIO none

Description yanbing 2013-02-27 07:22:05 UTC 
Created attachment 75619 [details]
EDP-no-lightup.dmesg

Environment:
--------------------

HSW desktop hd environment:
 Shark Bay Desktop Beta SDP (Flathead Creek): C3 stepping (id=0x0412, rev 06), Lynx Point 02 (B0 stepping) and Host bridge id=0x0c00 (rev 06) 4Cores/4Thread, CPU i5-4570 3.2GHz, GT2 800MHz; BIOS version: FC_Preproduction_Q87_5MB_BIOS-108_ME-9.0.0.1308 


Description:
--------------------
1.Connecting edp monitor and boot.
2.After showing the list of grub,edp monitor can not work.
3.Just on edp monitor and hsw-desktop.
4.Below is the result of bisect.

Bisect result:
--------------------
cc464b2a17c59adedbdc02cc54341d630354edc3 is the first bad commit
commit cc464b2a17c59adedbdc02cc54341d630354edc3
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Jan 25 16:59:16 2013 -0200

    drm/i915: set TRANSCODER_EDP even earlier

    Instead of setting it at the beginning of haswell_crtc_mode_set, let's
    set it at the beginning of intel_crtc_mode_set. When
    intel_crt_mode_set calls drm_vblank_pre_modeset we already need to
    have the transcoder_edp correctly set, because eventually
    drm_vblank_pre_modeset calls functions that call i915_pipe_enabled
    from i915_irq.c, which will read PIPECONF(cpu_transcoder).

    This is a bug that affects us since we added support for
    TRANSCODER_EDP, but I was only able to see the problem after
    suspending a machine with the power well disabled (got an "unclaimed
    register" error.

    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>





I attached the dmesg.
Comment 1 yanbing 2013-02-27 07:54:04 UTC 
It's on drm-intel-next-queued branch.
Comment 2 Chris Wilson 2013-02-27 17:13:40 UTC 
Paulo, can you take a look?
Comment 3 Paulo Zanoni 2013-02-27 17:46:57 UTC 
1 - EDP works for me here on my mobile machine.

2 - The dmesg complains about EDID being zero. I have seen this message sometimes (on HDMI), and just rebooting seemed to have "fixed" the problem for me. Do you see this "EDID is zero" message all the time?

3 - Dmesg also says that "pipe A is connected to port D and pipe B is connected to port C". Are you using eDP only?

4 - Can you please revert the code to a state where it worked, boot it and send me the dmesg?
Comment 4 yanbing 2013-02-28 05:54:25 UTC 
(In reply to comment #3)
> 1 - EDP works for me here on my mobile machine.
> 

EDP also works for us on mobile machine,this bug just exist on hsw-desktop.

> 2 - The dmesg complains about EDID being zero. I have seen this message
> sometimes (on HDMI), and just rebooting seemed to have "fixed" the problem
> for me. Do you see this "EDID is zero" message all the time?
> 

Yes,I see "EDID is zero" message all the time not only on bad commit but also on some good commit,you can see it on the "EDP-oldrevert-good.dmesg"

> 3 - Dmesg also says that "pipe A is connected to port D and pipe B is
> connected to port C". Are you using eDP only?
> 

For comparison test,I connect EDP and HDMI at the same time.But now I just only connect EDP  and get some new info at 4-2 & 4-3.The first bad commit was still that one.

> 4 - Can you please revert the code to a state where it worked, boot it and
> send me the dmesg?

Just only using EDP,I got some dmesg again.

4-1: By using first bad commit,just only using EDP and attched on "EDP-only-firstbad.dmesg"

4-2: When bisect the first bad commit and revert it at once (not git pull to the latest),it works well just only using EDP. I attached on "EDP-oldrevert-good.dmesg".

4-3: Git pull to the latest,and revert the code.Using only EDP is black,but EDP+HDMI works well. I attached on "EDP-newrevert.dmesg"
Comment 5 yanbing 2013-02-28 05:54:51 UTC 
Created attachment 75663 [details]
EDP-only-firstbad.dmesg
Comment 6 yanbing 2013-02-28 05:55:14 UTC 
Created attachment 75664 [details]
EDP-oldrevert-good.dmesg
Comment 7 yanbing 2013-02-28 05:55:39 UTC 
Created attachment 75665 [details]
EDP-newrevert.dmesg
Comment 8 Paulo Zanoni 2013-02-28 20:28:32 UTC 
Hi

So it looks like your machine has eDP on port D...

Can you please boot it with nomodeset and then run the following command and paste its output here?

intel_reg_read -d 0x60400 0x61400 0x62400 0x6f400 0x64000 0x64100 0x64200 0x64300 0x64400 0x130040 0x46020 0x46040 0x46060 0x46100 0x46104 0x46108 0x4610C 0x46110 0x46140 0x46144 0x46148

Thanks,
Paulo
Comment 9 Paulo Zanoni 2013-02-28 22:26:52 UTC 
Please check if your BIOS is configured to start eDP on port D:
Intel Advanced Menu -> System Agent (SA) Configuration -> Graphics Configuration -> LCD control -> Active LFP -> eDP Port-D
Comment 10 yanbing 2013-03-01 08:53:57 UTC 
(In reply to comment #8)
> Hi
> 
> So it looks like your machine has eDP on port D...
> 
> Can you please boot it with nomodeset and then run the following command and
> paste its output here?
> 
> intel_reg_read -d 0x60400 0x61400 0x62400 0x6f400 0x64000 0x64100 0x64200
> 0x64300 0x64400 0x130040 0x46020 0x46040 0x46060 0x46100 0x46104 0x46108
> 0x4610C 0x46110 0x46140 0x46144 0x46148
> 
> Thanks,
> Paulo

I attached the intel_reg_read.log.
Comment 11 yanbing 2013-03-01 08:54:42 UTC 
(In reply to comment #9)
> Please check if your BIOS is configured to start eDP on port D:
> Intel Advanced Menu -> System Agent (SA) Configuration -> Graphics
> Configuration -> LCD control -> Active LFP -> eDP Port-D

Yeah,I check my BIOS is configured to start eDP on port A.
Comment 12 yanbing 2013-03-01 08:55:06 UTC 
Created attachment 75728 [details]
intel_reg_read.log
Comment 13 Paulo Zanoni 2013-03-01 14:07:37 UTC 
(In reply to comment #11)
> (In reply to comment #9)
> > Please check if your BIOS is configured to start eDP on port D:
> > Intel Advanced Menu -> System Agent (SA) Configuration -> Graphics
> > Configuration -> LCD control -> Active LFP -> eDP Port-D
> 
> Yeah,I check my BIOS is configured to start eDP on port A.

So please change to "eDP Port-D" and test again, sending new logs :)
Comment 14 yanbing 2013-03-04 01:38:25 UTC 
(In reply to comment #13)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > Please check if your BIOS is configured to start eDP on port D:
> > > Intel Advanced Menu -> System Agent (SA) Configuration -> Graphics
> > > Configuration -> LCD control -> Active LFP -> eDP Port-D
> > 
> > Yeah,I check my BIOS is configured to start eDP on port A.
> 
> So please change to "eDP Port-D" and test again, sending new logs :)


1.When I boot it with nomodeset I found both edp-A and edp-D can work now.
2.When I boot it with modeset both can not work.
3.I attached the new log which is edp-D and nomodeset called "edp-d-intel_reg_read.log"
Comment 15 yanbing 2013-03-04 01:38:52 UTC 
Created attachment 75877 [details]
edp-d-intel_reg_read.log
Comment 16 yanbing 2013-03-04 03:06:04 UTC 
When I boot it with nomodeset on edp-D,the monitor can work.After that I start i915 by below commands to make i915 working:

modprobe -r drm
modprobe -r i915
modprobe drm
modrprobe i915 modeset=1

And the monitor turn to black immediately.So I think the issue maybe exist in driver.
Comment 17 Paulo Zanoni 2013-03-04 19:58:20 UTC 
Also please send the dmesg with BIOS configured to init eDP on port D and our current kernel without nomodeset.
Comment 18 yanbing 2013-03-05 01:19:01 UTC 
(In reply to comment #17)
> Also please send the dmesg with BIOS configured to init eDP on port D and
> our current kernel without nomodeset.


As you said, I attached the dmesg and below is the latest info of kernel on drm-intel-next-queued.

Kernel: (drm-intel-next-queued)ebd37ce1f74e1b735dc094334ad99d17ec66926b
Some additional commit info:
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Mar 1 14:35:39 2013 +0200

    drm/i915: Single thread force wake isn't used on HSW anymore
Comment 19 yanbing 2013-03-05 01:19:27 UTC 
Created attachment 75934 [details]
current-kernel-edp-d.dmesg
Comment 20 XiongZhang 2013-03-06 08:03:31 UTC 
It seems this is a common issue. I try it on a dell AIO machine which use Haswell C3 stepping (id=0x0412, rev 06) and fix eDP to DDI port D. 

Today I compile drm-intel-next-queue branch then I get the same error dmesg as yanbing. With Paulo's patch set, the error message "unclaimed register write" have almost disappered on another HSW machine. But on this machine there are still "unclaimed register" error message which may result in the failure of dp link training.

I paste the dmesg with the name of edp_lost
Comment 21 XiongZhang 2013-03-06 08:10:28 UTC 
Created attachment 76001 [details]
edp can't work on dell AIO
Comment 22 Gordon Jin 2013-03-10 04:40:15 UTC 
Thanks Xiong's info. That makes me more nervous.
Comment 23 Gordon Jin 2013-04-01 05:50:15 UTC 
Paulo, any fix plan?
Comment 24 Daniel Vetter 2013-04-02 08:21:34 UTC 
Haswell desktop eDP breakage in 3.9-rc kernels (and also -nigthly branch should all be fixed (by reverting the offending commits). Can you please retest and confirm?
Comment 25 Takashi Iwai 2013-04-05 13:27:02 UTC 
3.9-rc5 works at least on HP AiO desktop that was broken before.
Comment 26 shui yangwei 2013-04-07 02:41:04 UTC 
(In reply to comment #24)
> Haswell desktop eDP breakage in 3.9-rc kernels (and also -nigthly branch
> should all be fixed (by reverting the offending commits). Can you please
> retest and confirm?

I checked with -nightly branch 3.9-rc kernel, eDP worked well, so I verified it here.
Comment 27 Jari Tahvanainen 2016-10-07 05:37:23 UTC 
Closing verified+fixed.

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.