[Intel-gfx] [PATCH] drm/i915: respect previous reg values on primary plane disable

Kevin Strasser kevin.strasser at linux.intel.com
Wed Oct 14 13:33:57 PDT 2015

On Wed, Oct 14, 2015 at 10:48:52PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 14, 2015 at 11:59:59AM -0700, Kevin Strasser wrote:
> > Just to level set, these cases will produce different CRCs on HSW:
> >  1. Primary plane disabled, gamma correction disabled
> >  2. Primary plane disabled, gamma correction enabled
> > 
> > Case 2 is visibly brighter than case 1 and looks more like the enabled black
> > primary plane case.
> Ugh. That's weird. I thought data not going through any plane would
> bypass the gamma too.
> > The purpose of this patch is to get the behavior of a
> > disabled primary plane to match that of an enabled black plane, just as it does
> > on non-HSW platforms.
> Does it? I just tried it on IVB, and behaves just like you said. So not
> sure how far back this goes.

Ah, so this test case is failing on IVB too? Are there any reporting tools we
can look at to find out what tests are passing for each platform?

> And now I'm really wondering about platforms where the primary
> plane need not be fullscreen (gen2/3 and chv).
> I tried this on SKL too, but that confused me even more. The data not
> going through any plane seems to be gamma corrected regardless of any
> plane control bits, so that's good. However the legacy palette seems
> all fubar. Black input apparently doesn't map to palette entry 0.
> I wonder if you're seeing this on HSW too, or is your palette entry 0
> supposed to be non-black?

I also tried on BDW and it is passing the test with and without my patch

I'm not really sure what 'palette entry 0' you are looking for. Could you point
me to where in the code I can find out?

> Looks like quite a bit more testing is needed to get to the bottom of
> this.

Agreed, this does seem to extend beyond HSW. For now do you think my patch is
the right approach at least for HSW alone?


More information about the Intel-gfx mailing list