[Intel-gfx] [PATCH 3/3] drm/i915: remove the vblank_wait hack from HSW+

[Paulo Zanoni]

2013/12/20 Lee, Chon Ming <chon.ming.lee at intel.com>:
> On 12/20 12:32, Paulo Zanoni wrote:
>> 2013/12/19 Daniel Vetter <daniel at ffwll.ch>:
>> > On Thu, Dec 19, 2013 at 10:12 PM, Paulo Zanoni <przanoni at gmail.com> wrote:
>> >> From: Paulo Zanoni <paulo.r.zanoni at intel.com>
>> >>
>> >> When I forked haswell_crtc_enable I copied all the code from
>> >> ironlake_crtc_enable. The last piece of the function contains a big
>> >> comment with a call to intel_wait_for_vblank. After this fork, we
>> >> rearranged the Haswell code so that it enables the planes as the very
>> >> last step of the modeset sequence, so we're sure that we call
>> >> intel_enable_primary_plane after the pipe is really running, so the
>> >> vblank waiting functions work as expected. I really believe this is
>> >> what fixes the problem described by the big comment, so let's give it
>> >> a try and get rid of that intel_wait_for_vblank, saving around 16ms
>> >> per modeset (and init/resume). We can always revert if needed :)
>> >>
>> >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
>> >
>> > If kms_flip doesn't start failing you're good. Iirc I've added some
>> > flip vs. modeset and flip vs. dpms tests specifically for this.

Okay, on drm-intel-nightly kms_flip was failing even without my
patches, so I opened
https://bugs.freedesktop.org/show_bug.cgi?id=72917. It seems we need
to revert one of your PPGTT reverts, but even with that we still get
occasional backtraces on dmesg if we run the full suite (instead of
separate subtests).

So I switched to drm-intel-next-queued, then noticed kms_flip can't
even run 50% of the subtests if you just "./kms_flip" (without doing
one subtest per command invocation). I did some fixes on IGT and
submitted them to the mailing list.

So with drm-intel-next-queued + the IGT patches, kms_flip runs nice,
with or without this series. I applied my patches and I still get
SUCCESS on all tests, so I believe I'm not regressing any kms_flip
subtests with this patch.


>>
>> It already fails on plain -nightly, even without any of my patches on it :(
>>
>> I'm testing on a HSW ULT with eDP-only. It's hard to see all the tests
>> that fail due to the huge output print by the test, but I can see here
>> that at least flip-vs-modeset-vs-hang, flip-vs-panning-vs-hang and
>> flip-vs-dpms-off-vs-modeset fail, and also my machine is frozen while
>> running single-buffer-flip-vs-dpms-off-vs-modeset... So I can't even
>> run kms_flip with my patches and then without them to compare if I
>> introduce a new regression
>>
>> I also don't see a bug report about this specific Haswell failure, so
>> I wonder for how long this is broken :(
>>
>> I also feel I have to complain about the fact that kms_flip runs for
>> about 45 minutes (before it hangs my machine, so total time may be
>> even more). I just wanted to do a quick "check if I broke the test
>> which exercises the bug", but then it takes forever to finish... Can
>> you please point at specific subtests you were talking about?
>>
>
> I was running kms_flip yesterday to test out BYT.  Getting the same hang after
> flip-vs-panning-vs-hang.  Haven't have a chance to bisect it yet.
>
> But if I running just the flip-vs-panning-vs-hang subtest multiple times, I
> don't see the hang.  Only will get the hang when running all subtests.  And it
> hang at the same location.

Yeah, please check https://bugs.freedesktop.org/show_bug.cgi?id=72917.
Also, please try plain drm-intel-next-queued instead of
drm-intel-nightly.

Thanks,
Paulo

>
> Regards,
> Chon Ming
>
>
>> > -Daniel
>> > --
>> > Daniel Vetter
>> > Software Engineer, Intel Corporation
>> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>
>>
>>
>> --
>> Paulo Zanoni
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Paulo Zanoni