Created attachment 106765 [details] dmesg ==System Environment== -------------------------- Regression: Yes. Good commit: 9bbfd20abe5025adbb0ac75160bd2e41158a9e83(drm-intel-fixes). drm/i915: don't try DP_LINK_BW_5_4 on HSW ULX Non-working platforms: BSW ==kernel== -------------------------- -nightly: c920de3c631831526889a384b21da169b16b5c45 (fails) drm-intel-nightly: 2014y-09m-22d-12h-46m-45s UTC integration manifest -queued: b680c37a4d145cf4d8f2b24e46b1163e5ceb1d35 (fails) drm/i915: DocBook integration for frontbuffer tracking -fixes: 0f33be009b89d2268e94194dc4fd01a7851b6d51 (fails) Linux 3.17-rc6 ==Bug detailed description== ----------------------------- Boot machine up, eDP is black with backlight. eDP monitor fails to be detected by I-G-T testdisplay, neither do xrandr. We find this issue on one machine, but another machine works well. meesg shows: root@x-bsw02:~# /GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests/testdisplay -i Connectors: id encoder status type size (mm) modes 22 0 disconnected HDMI-A 0x0 0 27 0 disconnected DP 0x0 0 29 0 disconnected HDMI-A 0x0 0 31 0 disconnected DP 0x0 0 CRTCs: id fb pos size 8 0 (0,0) (0x0) 0 0 0 0 0 0 0 0 0 0x0 0x0 0 13 0 (0,0) (0x0) 0 0 0 0 0 0 0 0 0 0x0 0x0 0 18 0 (0,0) (0x0) 0 0 0 0 0 0 0 0 0 0x0 0x0 0 ==Reproduce steps== ---------------------------- 1. Boot machine up. 2. Check eDP monitor ==Bisect results== ----------------------------
Is this a form factor device or not? If not, please check any flip switches you may have. Have you perhaps upgraded the BIOS on the machine recently?
(In reply to comment #1) > Have you perhaps upgraded the BIOS on the machine recently? That's my question as well. I had another report of eDP going missing on one machine and there the HDMIC/DP_C registers report the port as not detected. My own RVP board with the latest BIOS seems to work just fine however. What does this say on the failing machine? intel_reg_read 0x1e1140 0x1e1160 0x1e116c 0x1e4100 0x1e4200 0x1e4300
It's RVP board, not form factor. Note this issue happens after the rework.
This machine has broken down, and is being repaired. So I can't offer information you want for now. I will update once machine is ok.
(In reply to comment #2) > (In reply to comment #1) > > Have you perhaps upgraded the BIOS on the machine recently? > Both BIOS V35 and V36 fail to detect eDP. > That's my question as well. I had another report of eDP going missing on one > machine and there the HDMIC/DP_C registers report the port as not detected. > My own RVP board with the latest BIOS seems to work just fine however. > > What does this say on the failing machine? > intel_reg_read 0x1e1140 0x1e1160 0x1e116c 0x1e4100 0x1e4200 0x1e4300 root@x-bsw02:~# intel_reg_read 0x1e1140 0x1e1160 0x1e116c 0x1e4100 0x1e4200 0x1e4300 0x1E1140 : 0x81C 0x1E1160 : 0x1A 0x1E116C : 0x82000B5E 0x1E4100 : 0x1C 0x1E4200 : 0xA0010018 0x1E4300 : 0x1C
According my bisect, it's a complex issue. +--------------------------------------+------------+ | commit | status | date | +--------------------------------------+ early | | 7895a81d | works | | | +--------------------------------------+ | | | d7f25f23 | render error | | | +--------------------------------------+ | | | c8f7a0db | render error + hang | | | +--------------------------------------+ | | | 84fd4f4e | Black screen + hang | | | +--------------------------------------+ \|/ | | d2152b25 | Black screen | latest | +---------------------------------------------------+ All commits above table except first one are first bad commit. I list commit detail. commit d2152b2524a96e6cb71097ea26c2e7c3f9e3ee12 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> AuthorDate: Mon Apr 28 14:15:24 2014 +0300 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Tue May 20 15:43:18 2014 +0200 drm/i915/chv: Set soft reset override bit for data lane resets The bits we've been setting so far only progagate the reset singal to the data lanes. To actaully force the reset signal we need to set another override bit. v2: Fix mispalced ';' (Mika) commit 84fd4f4e18885fc6b4a00f222040f24727b52514 Author: Rafael Barbalho <rafael.barbalho@intel.com> AuthorDate: Mon Apr 28 14:00:42 2014 +0300 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Tue May 20 15:22:36 2014 +0200 drm/i915/chv: Add CHV display support Add support for the third pipe in cherrview v2: Don't use spaces for indentation (Jani) Wrap long lines commit c8f7a0dbd7bfb9719d281407587f78c84f0411e6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> AuthorDate: Thu Apr 24 23:55:04 2014 +0200 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Mon May 19 15:31:06 2014 +0200 drm/i915: Inline set_base into crtc_mode_set A lot of the code in set_base is uncessary when the crtc is off, so we can get rid of it all. Also, we don't need to call the fbc/psr update functions since the crtc enable/disable hooks do that already. The only things we really need are: - Pin the new framebuffer and potentially unpin the old framebuffer (if the crtc has been on and we only change the configuration). - Update the plane registers. The first step will move out of platform code with the very next patch. v2: Don't forget about haswell ... commit d7f25f23d2e0c7898c95b2a6fd84f6358588de48 Author: Damien Lespiau <damien.lespiau@intel.com> AuthorDate: Thu May 8 22:19:40 2014 +0300 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Tue May 13 14:13:22 2014 +0200 drm/i915/chv: Implement stolen memory size detection CHV uses the same bits as SNB/VLV to code the Graphics Mode Select field (GFX stolen memory size) with the addition of finer granularity modes: 4MB increments from 0x11 (8MB) to 0x1d. Values strictly above 0x1d are either reserved or not supported. v2: 4MB increments, not 8MB. 32MB has been omitted from the list of new values (Ville Syrjälä) v3: Also correctly interpret GGMS (GTT Graphics Memory Size) (Ville Syrjälä) v4: Don't assign a value that needs 20bits or more to a u16 (Rafael Barbalho) [vsyrjala: v5: Split the early quirks to another patch]
(In reply to comment #5) > (In reply to comment #2) > > (In reply to comment #1) > > > Have you perhaps upgraded the BIOS on the machine recently? > > > Both BIOS V35 and V36 fail to detect eDP. > > That's my question as well. I had another report of eDP going missing on one > > machine and there the HDMIC/DP_C registers report the port as not detected. > > My own RVP board with the latest BIOS seems to work just fine however. > > > > What does this say on the failing machine? > > intel_reg_read 0x1e1140 0x1e1160 0x1e116c 0x1e4100 0x1e4200 0x1e4300 > > root@x-bsw02:~# intel_reg_read 0x1e1140 0x1e1160 0x1e116c 0x1e4100 0x1e4200 > 0x1e4300 > 0x1E1140 : 0x81C > 0x1E1160 : 0x1A > 0x1E116C : 0x82000B5E > 0x1E4100 : 0x1C > 0x1E4200 : 0xA0010018 > 0x1E4300 : 0x1C And what do you get if you run intel_reg_read before loading i915.ko? The detect bits seem to be read-only on my BSW at least so this seems like a board/BIOS issue. And that makes the the bisect result really unexpected.
Disable i915 root@x-bsw02:~# intel_reg_read 0x1e1140 0x1e1160 0x1e116c 0x1e4100 0x1e4200 0x1E1140 : 0x81C 0x1E1160 : 0x1A 0x1E116C : 0x82000816 0x1E4100 : 0x1C 0x1E4200 : 0xA0010018
We hit this problem as well after having the mandatory reworks for the RVP boards. We tracked it down to the R10 rework. By reverting that rework we are now able to boot with output going to the eDP panel. It's not yet clear why the R10 rework causes the failure. For reference, our failure is the one that Ville mentions in comment #2.
Created attachment 107624 [details] [review] [PATCH] drm/i915: Don't trust the DP_DETECT bit for eDP ports on CHV Ok, so it seems the DDC pins are muxed in such a way on these boards that there's no DDC pins for port C, and thus no strap for the port detect. I have no idea how it manages to work for some people (including me), but maybe the straps are sampled before the pin muxing is changed or something. Although even that is a very weak theory since the default muxing seems to be such that there's no DDC for port C. So I can't actually explain how the detect bit ends up as 1 on my machine. Anyway this patch will check the VBT to see if there should be an eDP port there even if the strap said otherwise. We anyway rely on the VBT to tell DP and eDP apart so this doesn't actually increase our dependence on the VBT.
(In reply to Ville Syrjala from comment #10) > Created attachment 107624 [details] [review] [review] > [PATCH] drm/i915: Don't trust the DP_DETECT bit for eDP ports on CHV > > Ok, so it seems the DDC pins are muxed in such a way on these boards that > there's no DDC pins for port C, and thus no strap for the port detect. > > I have no idea how it manages to work for some people (including me), but > maybe the straps are sampled before the pin muxing is changed or something. > Although even that is a very weak theory since the default muxing seems to > be such that > there's no DDC for port C. So I can't actually explain how the detect bit > ends up as 1 on my machine. > > Anyway this patch will check the VBT to see if there should be an eDP port > there even if the strap said otherwise. We anyway rely on the VBT to tell DP > and eDP apart so this doesn't actually increase our dependence on the VBT. This patch can fix the edp not light problem with R10 rework on BSW. Pls help upstream the patch, thanks. Detail configuration: BSW RVP FAB2 with R9,R10,R11 rework B1 CPU silicon KSC is 1.02 BIOS: V36 RAM: 2x 2GB OS: Ubuntu 14.04 x64
(In reply to wendy.wang from comment #11) > (In reply to Ville Syrjala from comment #10) > > Created attachment 107624 [details] [review] [review] [review] > > [PATCH] drm/i915: Don't trust the DP_DETECT bit for eDP ports on CHV > > > > Ok, so it seems the DDC pins are muxed in such a way on these boards that > > there's no DDC pins for port C, and thus no strap for the port detect. > > > > I have no idea how it manages to work for some people (including me), but > > maybe the straps are sampled before the pin muxing is changed or something. > > Although even that is a very weak theory since the default muxing seems to > > be such that > > there's no DDC for port C. So I can't actually explain how the detect bit > > ends up as 1 on my machine. > > > > Anyway this patch will check the VBT to see if there should be an eDP port > > there even if the strap said otherwise. We anyway rely on the VBT to tell DP > > and eDP apart so this doesn't actually increase our dependence on the VBT. > > This patch can fix the edp not light problem with R10 rework on BSW. Pls > help upstream the patch, thanks. > > Detail configuration: > BSW RVP FAB2 with R9,R10,R11 rework > B1 CPU silicon > KSC is 1.02 > BIOS: V36 > RAM: 2x 2GB > OS: Ubuntu 14.04 x64 Patch apply against latest drm-intel-nightly branch kernel.
Fix pushed to drm-intel-next-fixes as commit e17ac6db2ef99388b750b2141c11974dc5742913 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Oct 9 19:37:15 2014 +0300 drm/i915: Don't trust the DP_DETECT bit for eDP ports on CHV
This issue has been verified as PASS both on drm-intel-next-fixes and drm-intel-nightly branch, so close this bug as close. root@x-bsw02:~# cat /proc/cmdline BOOT_IMAGE=kernels//nightly_parents/2014_10_17/drm-intel-nightly/1361e359ee657c6dbc9528357e40f91a004c6abe/bzImage_x86_64 root=/dev/sda2 modules_path=kernels//nightly_parents/2014_10_17/drm-intel-nightly/1361e359ee657c6dbc9528357e40f91a004c6abe/modules_x86_64/lib/modules/3.17.0_drm-intel-nightly_1361e3_20141017+ acpi_rsdp=0x7b72b014
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.