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.
It's on drm-intel-next-queued branch.
Paulo, can you take a look?
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?
(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"
Created attachment 75663 [details] EDP-only-firstbad.dmesg
Created attachment 75664 [details] EDP-oldrevert-good.dmesg
Created attachment 75665 [details] EDP-newrevert.dmesg
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
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
(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.
(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.
Created attachment 75728 [details] intel_reg_read.log
(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 :)
(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"
Created attachment 75877 [details] edp-d-intel_reg_read.log
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.
Also please send the dmesg with BIOS configured to init eDP on port D and our current kernel without nomodeset.
(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
Created attachment 75934 [details] current-kernel-edp-d.dmesg
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
Created attachment 76001 [details] edp can't work on dell AIO
Thanks Xiong's info. That makes me more nervous.
Paulo, any fix plan?
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?
3.9-rc5 works at least on HP AiO desktop that was broken before.
(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.
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.