<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED --- - [snb] vsync hang" href="https://bugs.freedesktop.org/show_bug.cgi?id=68718#c26">Comment # 26</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED --- - [snb] vsync hang" href="https://bugs.freedesktop.org/show_bug.cgi?id=68718">bug 68718</a> from <a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> Ilia Mirkin</a> <pre>(In reply to <a href="show_bug.cgi?id=68718#c25">comment #25</a>) > (In reply to <a href="show_bug.cgi?id=68718#c24">comment #24</a>) > > 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. > > 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 > > 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? > > > 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)? 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...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>