[Bug 68718] [snb] vsync hang

[bugzilla-daemon at freedesktop.org]

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

--- Comment #26 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(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.

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

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