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

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

On Thu, Oct 15, 2015 at 04:00:48PM -0700, Kevin Strasser wrote:
> 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.

It means it's supposed to be black. But if you saw a difference between
black when it went through the gamma and when it didn't, then I guess
black is not hitting entry 0 on hsw either. So something seems fishy.

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

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