[Intel-gfx] [PATCH] drm/i915: Fix garbage pixels on top of LVDS on IVY laptop

[Takashi Iwai]

At Fri, 7 Dec 2012 18:04:06 +0100,
Daniel Vetter wrote:
> 
> On Fri, Dec 7, 2012 at 5:28 PM, Takashi Iwai <tiwai at suse.de> wrote:
> > At Fri, 7 Dec 2012 16:47:05 +0100,
> > Daniel Vetter wrote:
> >>
> >> On Fri, Dec 7, 2012 at 2:17 PM, Takashi Iwai <tiwai at suse.de> wrote:
> >> > The commit [23670b322: drm/i915: CPT+ pch transcoder workaround]
> >> > caused a regression on some HP laptops with IvyBridge.  On the top of
> >> > laptop screen, a few pixels height are blinking in the whole width
> >> > constantly.  The garbage appears only on LVDS and not on other
> >> > outputs.
> >> >
> >> > This patch reverts the minimum part for fixing this regression,
> >> > namely, the setup of CHICKEN2 bit in cpt_init_clock_gating().
> >> >
> >> > Signed-off-by: Takashi Iwai <tiwai at suse.de>
> >> > ---
> >> >
> >> > Don't ask me why this fixes :)
> >> > The bug is still present in drm-intel-next-queued as of today, at
> >> > least.
> >> >
> >> > Let me know if a better workaround is available.
> >>
> >> Since you're saying it only affects LVDS - have you tried to just move
> >> the w/a enabling earlier in the enable/modeset sequence? I'm thinking
> >> of the LVDS pin pair enabling, which now moved into the
> >> ->pre_pll_enable hook, but in 3.8-next it's still in the
> >> ironlake_crtc_mode_set. That would at least make some sense, and might
> >> also be a bit more robust since This code is only run once at
> >> resume/boot. But if we then clear things again on a subsequent
> >> modeset, LVDS might break when re-enabling ...
> >
> > You comment reminded me of testing S3/S4 I forgot, and interestingly,
> > the phenomenon is gone after S3.
> 
> Hm, could it be an issue due to the residual BIOS mode? Our code
> leaves the timing override bit enabled while the pipe is running,
> maybe the BIOS disables it once the pipe is up, leading to havoc when
> we disable the output on driver take-over? So maybe we need to fixup
> our idea of how the w/a should be set up in the crtc fixup code in
> intel_sanitize_crtc.

That's possible.  The BIOS version on the machine isn't the latest.
But it shouldn't be too old, too.

> /me is just tossing ideas around right now ...
> 
> > Also, looking at the display more closely, I found that the whole
> > screen is shifted downward for a few pixels.
> 
> No idea, can't remember a similar pattern.
> 
> > Moving the w/a to other place: I tried to put it to modeset, but it
> > didn't help.  Will try to enable code...
> 
> Hm, that would fit with the theory that we need this bit set while
> disabling the BIOS LVDS mode, not require it earlier in the modeset
> sequence.

I tried to move the w/a to enable code, but also didn't help.

So... your guess appears really feasible.
Then this is a side-effect of the new modeset code by optimizing the
enable/disable step?


thanks,

Takashi