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

Kevin Strasser kevin.strasser at linux.intel.com
Thu Oct 15 16:00:48 PDT 2015

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.


More information about the Intel-gfx mailing list