Re: [PATCH] drm/i915: respect previous reg values on primary plane disable

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Oct 14, 2015 at 01:33:57PM -0700, Kevin Strasser wrote:
> 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?

I just poked at the registers. I don't think we have specific test cases
for this, so any currently failing test case is just bad luck.

It would be good to write a small tool that just frobs the registers in
specific ways, and tells us if the test machine suffers from this issue.
Would be easy to run on any machine then.

What I did manually was:
intel_reg write 0x4a000 0x400000
intel_reg write 0x70180 0x0
<whatever> = intel_reg read 0x7019c
intel_reg write 0x7019c <whatever>

and as a second test I tried:
intel_reg write 0x70180 <original value & ~(1<<31))
<whatever> = intel_reg read 0x7019c
intel_reg write 0x7019c <whatever>

And the result was black in the first test, dark red in
the second.

On SKL I additionally tried to resize the plane to be smaller, and then
tried the same thing. But as stated the palette seems to misbehave
somehow, so there was no change in the output from changing entry 0 even
though most of the screen was supposed to be black.

> 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
> applied.
> 
> 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?

Register 0x4a000, 0x4a800, 0x4b000, depending on which pipe you're
using.

> 
> > 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?

Yeah, looks that way. But we do need to figure out which bits behave
this way. Ie. is it just gamma, or pipe csc too, or perhaps even some
other bits?

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx