[Bug 68718] [snb] vsync hang

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=68718

--- Comment #27 from Chris Wilson <chris at chris-wilson.co.uk> ---
(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > Lastly, it looks like there's a PIPEA_SLC (0x70004) which I guess needs to
> > > be programmed on [DevSNB:D2], whatever that is (I'm hoping "pre-release hw").
> > 
> > Right, (SLC = scanline counter) which is programmed by setting DE_LOAD_SL.
> > The tricky part is that DE_LOAD_SL only exists for later chips - some early
> > production chips do not have the register and so have no way to program
> > PIPE*_SLC.
> 
> My read was that they did -- you had to write the bottom bits of PIPE*_SLC.
> And on the chips with DE_LOAD_SL, those bottom bits flip to reserved. I'm
> not too familiar with the Intel PRM notation though, so I could easily have
> misunderstood.

But you can't actually program an inclusive window into SLC -- how the memories
are coming back to me.

> > In fact, can you do intel_reg_read 0x4f100? Or intel_reg_write 0x4f100
> > 0xdeadbeef; intel_reg_read 0x4f100
> 
> intel-gpu-tools # ./tools/intel_reg_write 0x4f100 0xdeadbeef
> Value before: 0x1000100
> Value after: 0xDEADBEEF
> intel-gpu-tools # ./tools/intel_reg_read 0x4f100
> 0x4F100 : 0xDEADBEEF
> (wait a little while)
> intel-gpu-tools # ./tools/intel_reg_read 0x4f100
> 0x4F100 : 0x1000100

Bleh, so either it's a working chip or this method of detection for nonworking
chips is inadequate. :(

> > > Lastly, is the masking logic for DERRMR correct? It uses ~event... I
> > > couldn't find the spec for what the various bits actually mean, I guess
> > > they're meant to line up with the MI_WAIT_FOR_EVENT bits?
> > 
> > It is just a happy coincidence on SNB that the bits do line up between
> > DERRMR and the WAIT_FOR_EVENT. Yes, I have checked those many times.
> 
> I'm sure you're right, but could you point out where those are specified?
> They weren't next to DERRMR. BTW, may be worth pointing out that right now I
> have 2 screens connected, which I guess means both pipes get used?

Scan through for a block titled
"Display Engine Render Response Message Bit Definition"


> > 
> > > Would be good to
> > > double-check... (Also, why do you need to store the DERRMR value somewhere?
> > > Seems odd to me, but what do I know.)
> > 
> > Because the hardware is broken, and this is one of the w/a. I don't think it
> > is required because the wait will ensure that the flush will happen before
> > we write to the same register again, hence why I left it out of the original
> > code. But it was something easy enough to test. Again.
> 
> Good reason for me to be confused :)
> 
> Another oddity:
> 
> 	/* Always program one less than the desired value */
> 	if (--y1 < 0)
> 		y1 = crtc->bounds.y2;
> 
> ...
> 
> 	if (y2 == y1)
> 		return false;
> 
> Should that perhaps be if (y2 < y1)?

It's actually legal for y2 to be less than y1 - e.g. any window that starts on
the top line.

> And one last thought: Should the DE_LOAD_SL stuff still be done if
> full_height == true? Then we're just waiting for the vsync...

You could skip the LRI in that case - it is just simpler to always emit it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20140211/4c30175c/attachment-0001.html>