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 27 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
