[Bug 68718] [snb] vsync hang

[bugzilla-daemon at freedesktop.org]

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

--- Comment #25 from Chris Wilson <chris at chris-wilson.co.uk> ---
(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.

In fact, can you do intel_reg_read 0x4f100? Or intel_reg_write 0x4f100
0xdeadbeef; intel_reg_read 0x4f100

> No idea if these apply, and you were probably already aware of these things,
> but thought I'd mention anyways. (Is MI_SUSPEND_FLUSH used? Can the commands
> get broken up into different batch buffers behind the scenes? What's CB^2?)

No, those restrictions do not apply as we neither use suspend flush, non-secure
batch buffer for LRI, ppgtt batches or chained batchbuffers (CB^2).

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

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

-- 
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/36d3a91d/attachment.html>