Bug 84265

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