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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
