From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: Issue after drm/i915: prefer wide & slow to fast & narrow in DP configs. Date: Wed, 20 Mar 2013 08:28:02 -0700 Message-ID: <20130320082802.120500ef@jbarnes-desktop> References: <1792597.HQauA4NgeB@dhcp79> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by gabe.freedesktop.org (Postfix) with SMTP id C7A6CE6626 for ; Wed, 20 Mar 2013 08:28:03 -0700 (PDT) In-Reply-To: <1792597.HQauA4NgeB@dhcp79> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Michal Srb Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, 20 Mar 2013 14:45:52 +0100 Michal Srb wrote: > Hi, > > I am debugging an issue with IBM POS machine (4852-570, Truman), with > 8086:0102 Intel Sandybridge graphic card and internal monitor connected over > display port. > > The issue is that sporadically, after mode change, the monitor remains blank. > There is no difference in drm.debug=0xe level log or content of /dri > between the state when monitor displays image and the state when it remains > blank. > > (The monitor supports only 1024x768, so every mode change is into this > resolution. It happens when the intel driver switches resolution during boot, > when X starts, X ends, modetest starts or modetest ends.) > > I've bisected the cause to this commit: > > commit 2514bc510d0c3aadcc5204056bb440fa36845147 > Author: Jesse Barnes > Date: Thu Jun 21 15:13:50 2012 -0700 > > drm/i915: prefer wide & slow to fast & narrow in DP configs > > High frequency link configurations have the potential to cause trouble > with long and/or cheap cables, so prefer slow and wide configurations > instead. This patch has the potential to cause trouble for eDP > configurations that lie about available lanes, so if we run into that we > can make it conditional on eDP. > > > The machine reports to have 2 lanes available and that seems to be correct. > One lane was used before the commit and the screen used to show picture after > every mode change: > > [drm:intel_dp_mode_fixup], DP ink computation with max lane count 2 max bw > 0a pixel clock 65000KHz > [drm:intel_dp_mode_fixup], DP link bw 0a lane count 1 clock 270000 bpp 24 > [drm:intel_dp_mode_fixup], DP link bw required 156000 available 216000 > > Two lanes are used after the commit and the screen occasionally remains blank > after mode change: > > [drm:intel_dp_mode_fixup], DP link computation with max lane count 2 max bw > 0a pixel clock 65000KHz > [drm:intel_dp_mode_fixup], DP link bw 06 lane count 2 clock 162000 bpp 24 > [drm:intel_dp_mode_fixup], DP link bw required 156000 available 259200 > > > Could you advise me where to look further? Could this be a hardware bug? > Reverting the commit works as a workaround, but doesn't look like correct way > to fix this... There's nothing else in the log about aux failures? Just that the training apparently succeeded but you ended up with a blank screen? -- Jesse Barnes, Intel Open Source Technology Center