[Intel-gfx] SNB LVDS goes all stripy at times with rc6 enabled

Jesse Barnes jbarnes at virtuousgeek.org
Wed Jul 27 18:06:09 CEST 2011


On Wed, 27 Jul 2011 02:29:19 -0700
"Keith Packard" <keithp at keithp.com> wrote:

> 
> Ok, that took all evening. And, I don't have a fix, but I do know a lot
> more about the problem.
> 
> To recap:
> 
>         On Sandybridge, sometimes, when you simultaneously change two
>         outputs, one of them turns into stripes, or as solid color.
> 
> Here's how I reproduce it:
> 
>         First, connect an external monitor to your laptop. I've seen
>         this with HDMI and DisplayPort, but never with VGA. No, I don't
>         know why. DisplayPort seems to reliably reproduce it for me.
> 
>                 $ xrandr --output DP2 --auto --output LVDS1 --auto --below DP2
> 
>         The key is to place LVDS1 at a position other than 0x0 so that
>         it will get a full mode set in the subsequence step.
> 
>         Now, work around a bug in the kernel where it doesn't set crtc
>         DPMS state in intel_crtc_mode_set (how many times do we have to
>         fix this bug?):
> 
>                 $ xset dpms force off
> 
>         (alternatively, apply the patch I sent out to set the DPMS state
>         in intel_crtc_mode_set).
> 
>         Finally, turn off DP2:
> 
>                 $ xrandr --output DP2 --off
> 
>         With luck, you'll see stripes on your LVDS monitor instead of
>         the expected image.
> 
> Knowing that things worked (at least before any DPMS fired) without the
> intel_crtc_mode_set DPMS fix, I set about trying to figure out how the
> two paths differed (with and without the DPMS fix). The differences were
> minimal, and I slowly hacked up the code to eliminate all of them,
> except for the step which actually disabled the idle CRTC which had been
> driving the DP port.
> 
> At this point, I had exactly matching register write sequences between
> the two cases, except for he addition of the DP CRTC disable, which
> happened right at the beginning of the mode setting sequence.
> 
> Nothing worked, except when I stopped disabling the DP CRTC.
> 
> Finally, I tried disabling fbc and rc6. Surprise! things worked
> perfectly now. I then isolated the effect to just rc6. With rc6 enabled,
> I'd get garbage on the screen. With rc6 disabled, things work correctly.
> 
> I tried holding force_wake across a few functions in intel_display.c
> without success; I have to assume that there's some register reads or
> writes which are going wrong with rc6 enabled.

I tried this last week with my patch

commit 2a9852c3809f5fd03a4755381e2ef47da72d22ef
Author: Jesse Barnes <jbarnes at virtuousgeek.org>
Date:   Fri Jul 22 13:17:05 2011 -0700

    drm/i915: apply timing generator bug workaround on CPT and PPT

and wasn't able to reproduce it.  I may have been just getting lucky,
but it's worth having you try as well.  I can imagine RC6 affecting the
timing generator bug...

-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list