<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#c27">Comment # 27</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:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>(In reply to <a href="show_bug.cgi?id=68718#c26">comment #26</a>) > (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. 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>