Can you please retest with the latest drm-intel-nightly branch from

http://cgit.freedesktop.org/drm-intel

Oops, you've done this already, nevermind.

Hi,

I tried the stable-kernel (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=refs%2Ftags%2Fv3.12.14&h=linux-3.13.y) with ubuntu 13.10; Its behavior is given below.

a) When booted with VGA + DP monitor
------------------------------------
Issue exists


b) When booted with only DP monitor
-----------------------------------

Desktop is stable.

So I did a bisect of the kernel and found that the below commit

########################################################
c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf is the first good commit
commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Oct 21 10:52:07 2013 +0300

    drm/i915/dp: workaround BIOS eDP bpp clamping issue
    
    This isn't a real fix to the problem, but rather a stopgap measure while
    trying to find a proper solution.
    
    There are several laptops out there that fail to light up the eDP panel
    in UEFI boot mode. They seem to be mostly IVB machines, including but
    apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
    UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.
    
    The difference between UEFI and CSM is that the BIOS provides a
    different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
    1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
    up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
    link, and for reasons yet unknown fail to light up the panel.
    
    Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
    2.7 GHz link, the eDP panel lights up. So essentially this is a link
    speed issue, and *not* a bpp clamping issue.
    
    The bug raised its head since
    commit 657445fe8660100ad174600ebfa61536392b7624
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Sat May 4 10:09:18 2013 +0200
    
        Revert "drm/i915: revert eDP bpp clamping code changes"
    
    which started clamping bpp *before* computing the link requirements, and
    thus affecting the required bandwidth. Clamping after the computations
    kept the link at 2.7 GHz.
    
    Even though the BIOS tells us to use 18 bpp through the VBT, it happily
    boots up at 24 bpp and 2.7 GHz itself! Use this information to
    selectively ignore the VBT provided value.
    
    We can't ignore the VBT eDP bpp altogether, as there are other laptops
    that do require the clamping to be used due to EDID reporting higher bpp
    than the panel can support.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
    Tested-by: Ulf Winkelvos <ulf@winkelvos.de>
    Tested-by: jkp <jkp@iki.fi>
    CC: stable@vger.kernel.org
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
#################################################

Fixed this problem in DP only scenario. Commits prior to this on stable linux-3.13.y branch has this issue with only DP monitor connected.

Regards,
Arun C

Hi,

I observed that if I power up the board with only DP monitor connected desktop is stable.  Then even if i connect extra VGA monitor graphics is stable.

The issue comes only if I power up the board with both DP and VGA connected.

Regards,
Arun C

Hi,


The below patch solves the problem for me

########################################
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 41bdac4..ad1d824 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -844,12 +844,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
        /* Walk through all bpp values. Luckily they're all nicely spaced with 2
         * bpc in between. */
        bpp = pipe_config->pipe_bpp;
-       if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp &&
-           dev_priv->vbt.edp_bpp < bpp) {
-               DRM_DEBUG_KMS("clamping bpp for eDP panel to BIOS-provided %i\n",
-                             dev_priv->vbt.edp_bpp);
-               bpp = dev_priv->vbt.edp_bpp;
-       }
 
        for (; bpp >= 6*3; bpp -= 2*3) {
                mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,

###########################################


In the case of VGA + DP overriding of BIOS provided max bpp is not happening as
 intel_dp_get_config() is called after calling intel_dp_compute_config(). That function overrides pipe bpp with BIOS provided one.


I think it happens because the when both DP and VGA is connected, DP is powered on lately and intel_dp_get_hw_state() returns false so 
intel_modeset_readout_hw_state() is not calling intel_dp_get_config() during the booting.


Regards,
Arun C

We've shuffled the code a lot recently. Please try current drm-intel-nightly and report back.

Arun, please re-open if this isn't fixed in current code.