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

[Kevin Strasser <kevin.strasser@linux.intel.com>]

On Thu, Oct 15, 2015 at 11:20:59AM +0300, Ville Syrjälä wrote:
> 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:
> > > 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.

Agreed, it is somewhat painful getting the whole test suite built and running in
some environments.

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

I'm using pipe A, here is the output of 'intel_reg read 0x4a000':
(0x0004a000): 0x00000000

I suppose this means palette entry 0 is black for me.

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

I did some testing and it seems that gamma and pipe csc are both needed to pass
the test on HSW. v2 of the patch sets them explicitly.

Thanks,
Kevin
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx