Bug 84265

Summary: [BSW Bisected]System fails to find eDP monitor.
Product: DRI Reporter: liulei <lei.a.liu>
Component: DRM/IntelAssignee: Ville Syrjala <ville.syrjala>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: blocker    
Priority: high CC: intel-gfx-bugs, jinxianx.guo, wayne.boyer
Version: unspecifiedKeywords: bisected
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg
none
[PATCH] drm/i915: Don't trust the DP_DETECT bit for eDP ports on CHV none

Description liulei 2014-09-24 07:12:24 UTC
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==
----------------------------
Comment 1 Jani Nikula 2014-09-24 09:04:19 UTC
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?
Comment 2 Ville Syrjala 2014-09-24 09:29:14 UTC
(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
Comment 3 Gordon Jin 2014-09-25 07:40:44 UTC
It's RVP board, not form factor.

Note this issue happens after the rework.
Comment 4 liulei 2014-09-26 08:23:46 UTC
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.
Comment 5 liulei 2014-09-28 08:56:42 UTC
(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
Comment 6 liulei 2014-09-29 10:36:52 UTC
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]
Comment 7 Ville Syrjala 2014-09-29 10:56:17 UTC
(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.
Comment 8 liulei 2014-09-30 01:04:29 UTC
Disable i915
root@x-bsw02:~# intel_reg_read 0x1e1140 0x1e1160 0x1e116c 0x1e4100 0x1e4200
0x1E1140 : 0x81C
0x1E1160 : 0x1A
0x1E116C : 0x82000816
0x1E4100 : 0x1C
0x1E4200 : 0xA0010018
Comment 9 Wayne Boyer 2014-10-02 18:06:38 UTC
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.
Comment 10 Ville Syrjala 2014-10-09 16:35:38 UTC
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.
Comment 11 wendy.wang 2014-10-11 02:58:22 UTC
(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
Comment 12 wendy.wang 2014-10-11 03:00:20 UTC
(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.
Comment 13 Jani Nikula 2014-10-16 14:00:09 UTC
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
Comment 14 wendy.wang 2014-10-17 08:49:38 UTC
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.