On Wed, 27 Jul 2011 02:29:19 -0700
"Keith Packard" <kei...@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 <jbar...@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
