Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH i-g-t 1/3] lib/igt_kms: Drop all stale events on first commit.
Date: Thu, 7 Dec 2017 16:57:09 +0100	[thread overview]
Message-ID: <20dea8d1-da6c-3391-1346-8e5ac86c6c07@linux.intel.com> (raw)
In-Reply-To: <151266182525.25422.7863195793286779501@mail.alporthouse.com>

Op 07-12-17 om 16:50 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2017-12-07 15:42:54)
>> Op 07-12-17 om 16:03 schreef Chris Wilson:
>>> Quoting Maarten Lankhorst (2017-12-07 13:40:25)
>>>> I've been trying to make kms_cursor_legacy work when subtests fail.
>>>> Other subtests will start failing too because of expired events or
>>>> stale pipe crc. The latter can be resolved in the test, but the former
>>>> could affect other tests
>>>>
>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>> ---
>>>>  lib/igt_kms.c | 39 ++++++++++++++++++++++++++++++++++++++-
>>>>  lib/igt_kms.h |  1 +
>>>>  2 files changed, 39 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>>>> index 223dbe4ca565..9e14f071ea57 100644
>>>> --- a/lib/igt_kms.c
>>>> +++ b/lib/igt_kms.c
>>>> @@ -2943,7 +2943,10 @@ display_commit_changed(igt_display_t *display, enum igt_commit_style s)
>>>>                         output->changed &= 1 << IGT_CONNECTOR_CRTC_ID;
>>>>         }
>>>>  
>>>> -       display->first_commit = false;
>>>> +       if (display->first_commit) {
>>>> +               igt_display_drop_events(display);
>>>> +               display->first_commit = false;
>>>> +       }
>>> So I spent quite a bit of time debating whether there is merit in "do
>>> something; set-first-mode" that this would then clobber. After some
>>> thought, no that doesn't seem like a wise test construction. I would
>>> however suggest that we igt_debug() if we drop any events here.
>>> -Chris
>> Exactly. I'm using igt_info since it's supposed to be uncommon, is it ok if I upgrade it to a igt_warn() since nothing in CI will trigger it?
> Oh, I wouldn't have put it inside drop_events itself, since that is just
> doing its job -- whether or not it is relevant depends on the caller. So
> I would suggest reducing it to igt_debug, or just reporting the number
> dropped and making the judgement in the caller.
>
> No, I don't this should be an igt_warn, as then CI blames the following
> test for environmental errors left over from previous runs.
> -Chris

It's not even possible, CI runs each test separately. When you open a
new copy of the drm fd you don't get events for the previous fd.

Only when subtests fail you should get a dropped event, because of this
it will never happen in CI and it's safe to change to a warn.

~Maarten

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-12-07 15:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-07 13:40 [PATCH i-g-t 1/3] lib/igt_kms: Drop all stale events on first commit Maarten Lankhorst
2017-12-07 13:40 ` [PATCH i-g-t 2/3] tests/kms_cursor_legacy: Perform lazy cleanup between tests Maarten Lankhorst
2017-12-22  9:14   ` Mika Kahola
2017-12-22 12:50   ` Mika Kahola
2017-12-07 13:40 ` [PATCH i-g-t 3/3] tests/kms_cursor_legacy: Rework the 2x-*-vs-cursor-* tests Maarten Lankhorst
2017-12-22  8:55   ` Mika Kahola
2018-01-02  8:45     ` Maarten Lankhorst
2017-12-07 15:03 ` [PATCH i-g-t 1/3] lib/igt_kms: Drop all stale events on first commit Chris Wilson
2017-12-07 15:42   ` Maarten Lankhorst
2017-12-07 15:50     ` Chris Wilson
2017-12-07 15:57       ` Maarten Lankhorst [this message]
2017-12-07 16:12         ` Chris Wilson
2017-12-19 13:18           ` Chris Wilson
2017-12-07 18:43 ` ✓ Fi.CI.BAT: success for series starting with [1/3] " Patchwork
2017-12-07 22:54 ` ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20dea8d1-da6c-3391-1346-8e5ac86c6c07@linux.intel.com \
    --to=maarten.lankhorst@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox