[Bug 68718] [snb] vsync hang

[bugzilla-daemon at freedesktop.org]

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

--- Comment #24 from Ilia Mirkin <imirkin at alum.mit.edu> ---
I read a bunch of documentation, I'm sure you already know all this, but here
is what I found:

About the scanline thing (DE_LOAD_SL, aka 0x4f100):

"""
Notes for command streamer programming to use this display load scan lines
register: 

Either MMIO or a MI_LOAD_REGISTER_IMM command can be used to unmask the scan
line render response 0x44050. That can be done any time before programming this
register. 

In order to use MI_WAIT_FOR_EVENT on scan line window, DE_LOAD_SL must be
programmed using MI_LOAD_REGISTER_IMM immediately prior to the
MI_WAIT_FOR_EVENT on scan line window, both commands must be in the same
cacheline, both commands must be executed using the same tail or batch update,
and if sync flush is enabled, MI_SUSPEND_FLUSH must be used to suspend flushes
prior to the commands.
"""

Also this in MI_WAIT_FOR_EVENT:

"""
Software must disable MI_WAIT_FOR_EVENT RC6 entry via RC_PSMI_CTRL if
MI_WAIT_FOR_EVENT is parsed in a batch buffer with the following attributes
set: 

* batch buffer in PPGTT space (labeled “non-secure” in command)
* CB^2 batch buffer 

MI_NOOP setting NOP register (or any other benign command) must be set after
MI_WAIT_FOR_EVENT under the following conditions 

* Back-to-back MI_WAIT_FOR_EVENT commands
* MI_WAIT_FOR_EVENT is the last command before head = tail
"""

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

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

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

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