All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset
Date: Tue, 7 Apr 2020 20:10:51 +0300	[thread overview]
Message-ID: <20200407171051.GI6112@intel.com> (raw)
In-Reply-To: <0db0f75f-ea12-f04a-7bcc-254c98c9d4ad@gmail.com>

On Tue, Apr 07, 2020 at 08:07:16PM +0300, Juha-Pekka Heikkila wrote:
> On 7.4.2020 19.22, Juha-Pekka Heikkila wrote:
> > On 7.4.2020 19.08, Ville Syrjälä wrote:
> >> On Tue, Apr 07, 2020 at 06:54:09PM +0300, Juha-Pekka Heikkila wrote:
> >>> On 7.4.2020 18.36, Ville Syrjälä wrote:
> >>>> On Tue, Apr 07, 2020 at 02:09:04PM +0300, Juha-Pekka Heikkila wrote:
> >>>>> This change will slow this test down a bit. In mid test starting
> >>>>> to use higher bpp pixel format (say 64bpp) can cause modeset.
> >>>>> Use blocking commit so there's wait for modeset to happen.
> >>>>
> >>>> We already wait for the event the next time around. So this
> >>>> doesn't make sense to me.
> >>>
> >>> There's those logs like this
> >>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_470/fi-icl-guc/igt@kms_plane@pixel-format-pipe-c-planes-source-clamping.html 
> >>>
> >>>
> >>> where going to 64bpp pixel format will cause modeset and fail running
> >>> test.
> >>
> >> Hmm. Seems we don't have drm.debug=0x10 enabled so we don't see the
> >> actual debug message :( Anyways, the real bug seems to be the lack of
> >> ALLOW_MODESET.
> > 
> > I'll try that and see how it changes situation. I originally had idea 
> > modeset will block the flip and making this commit blocking would always 
> > force things always into correct order as current test didn't fail every 
> > time for me.
> 
> Having that commit saying
> 
> igt_display_commit_atomic(&data->display,
> 	DRM_MODE_ATOMIC_ALLOW_MODESET |
> 	DRM_MODE_ATOMIC_NONBLOCK |
> 	DRM_MODE_PAGE_FLIP_EVENT, NULL);
> 
> I see test failing as before so it will not alone fix this issue. On my 
> ICL box the test fail maybe 1/5 times, with the patch on list it never 
> failed so far.

Why does it fail?

> 
> > 
> >>
> >>> I was testing this on ICL and see errors randomly, on ci those
> >>> seem to be less random. Making this one commit blocking will cause
> >>> modeset to settle without interrupting test, at least on my ICL.
> >>>
> >>> If there's a way to sort those pixel formats according to bpp and start
> >>> with highest there's no need for this.
> >>>
> >>>>
> >>>>>
> >>>>> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1214
> >>>>> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
> >>>>> ---
> >>>>>    tests/kms_plane.c | 6 ++----
> >>>>>    1 file changed, 2 insertions(+), 4 deletions(-)
> >>>>>
> >>>>> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
> >>>>> index 805795cd..2324fb6e 100644
> >>>>> --- a/tests/kms_plane.c
> >>>>> +++ b/tests/kms_plane.c
> >>>>> @@ -569,12 +569,10 @@ static void capture_format_crcs(data_t *data, 
> >>>>> enum pipe pipe,
> >>>>>            if (data->display.is_atomic) {
> >>>>>                /*
> >>>>> -             * Use non-blocking commits to allow the next fb
> >>>>> -             * to be prepared in parallel while the current fb
> >>>>> -             * awaits to be latched.
> >>>>> +             * Use blocking commit because there maybe
> >>>>> +             * modeset when going to higher bpp pixel format.
> >>>>>                 */
> >>>>>                igt_display_commit_atomic(&data->display,
> >>>>> -                          DRM_MODE_ATOMIC_NONBLOCK |
> >>>>>                              DRM_MODE_PAGE_FLIP_EVENT, NULL);
> >>>>>            } else {
> >>>>>                /*
> >>>>> -- 
> >>>>> 2.17.1
> >>>>>
> >>>>> _______________________________________________
> >>>>> igt-dev mailing list
> >>>>> igt-dev@lists.freedesktop.org
> >>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
> >>>>
> >>
> > 

-- 
Ville Syrjälä
Intel
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2020-04-07 17:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07 11:09 [igt-dev] [PATCH i-g-t] tests/kms_plane: survive cdclk caused modeset Juha-Pekka Heikkila
2020-04-07 11:56 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2020-04-07 15:36 ` [igt-dev] [PATCH i-g-t] " Ville Syrjälä
2020-04-07 15:54   ` Juha-Pekka Heikkila
2020-04-07 16:08     ` Ville Syrjälä
2020-04-07 16:22       ` Juha-Pekka Heikkila
2020-04-07 17:07         ` Juha-Pekka Heikkila
2020-04-07 17:10           ` Ville Syrjälä [this message]
2020-04-07 17:24             ` Juha-Pekka Heikkila
2020-04-07 17:42               ` Ville Syrjälä
2020-04-08 19:08                 ` Juha-Pekka Heikkila
2020-04-09 16:08                   ` Ville Syrjälä
2020-04-09 16:50                     ` Juha-Pekka Heikkila
2020-04-07 17:59 ` [igt-dev] ✓ Fi.CI.IGT: success for " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2020-04-17 10:18 [igt-dev] [PATCH i-g-t] " Juha-Pekka Heikkila
2020-04-17 13:18 ` Ville Syrjälä

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=20200407171051.GI6112@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=juhapekka.heikkila@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.