All of lore.kernel.org
 help / color / mirror / Atom feed
* Issue after drm/i915: prefer wide & slow to fast & narrow in DP configs.
@ 2013-03-20 13:45 Michal Srb
  2013-03-20 15:28 ` Jesse Barnes
  0 siblings, 1 reply; 2+ messages in thread
From: Michal Srb @ 2013-03-20 13:45 UTC (permalink / raw)
  To: intel-gfx

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 <debugfs>/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 <jbarnes@virtuousgeek.org>
  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...

Thank you,
Michal Srb

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Issue after drm/i915: prefer wide & slow to fast & narrow in DP configs.
  2013-03-20 13:45 Issue after drm/i915: prefer wide & slow to fast & narrow in DP configs Michal Srb
@ 2013-03-20 15:28 ` Jesse Barnes
  0 siblings, 0 replies; 2+ messages in thread
From: Jesse Barnes @ 2013-03-20 15:28 UTC (permalink / raw)
  To: Michal Srb; +Cc: intel-gfx

On Wed, 20 Mar 2013 14:45:52 +0100
Michal Srb <msrb@suse.com> 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 <debugfs>/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 <jbarnes@virtuousgeek.org>
>   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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-03-20 15:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-20 13:45 Issue after drm/i915: prefer wide & slow to fast & narrow in DP configs Michal Srb
2013-03-20 15:28 ` Jesse Barnes

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.