From: "Lisovskiy, Stanislav via igt-dev" <igt-dev@lists.freedesktop.org>
To: "daniel@ffwll.ch" <daniel@ffwll.ch>
Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
"juhapekka.heikkila@intel.com" <juhapekka.heikkila@intel.com>,
"Syrjala, Ville" <ville.syrjala@intel.com>,
"Peres, Martin" <martin.peres@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t] igt/tests: Fix error checking in kms_atomic_transition
Date: Thu, 14 Feb 2019 08:31:52 +0000 [thread overview]
Message-ID: <729d50520419f53ae843ac495ad467948935b29c.camel@intel.com> (raw)
In-Reply-To: <20190214082542.GQ23159@phenom.ffwll.local>
On Thu, 2019-02-14 at 09:25 +0100, Daniel Vetter wrote:
> On Thu, Feb 14, 2019 at 08:22:29AM +0000, Lisovskiy, Stanislav wrote:
> > On Wed, 2019-02-13 at 21:41 +0100, Daniel Vetter wrote:
> > > On Wed, Feb 13, 2019 at 06:18:17PM +0200, Stanislav Lisovskiy via
> > > igt-dev wrote:
> > > > There is no guarantee that error return value will be
> > > > always EINVAL, made a check more general as it can be
> > > > ERANGE, ENOSPC, EINVAL and probably others, which all
> > > > mean the same in context of this test case: i.e this sprite
> > > > size is not valid.
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109225
> > > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.c
> > > > om>
> > >
> > > Kernel atomic spec is pretty clear that it's either EINVAL or
> > > ERANGE,
> > > and
> > > nothing else. In the docs we even limit to EINVAL (scroll down to
> > > atomic_check):
> > >
> > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html?highlight=d
> > > rm_m
> > > ode_config_funcs#c.drm_mode_config_funcs
> > >
> > > Would be great if you can submit a kernel patch to add the
> > > ERANGE.
> > > And
> > > change this one here to only accept ERANGE and EINVAL as "sprite
> > > doesn't
> > > work".
> >
> > Unfortunately, in reality it is not like that. We have a bug
> > fdo#109225, where it returns ENOSPC. DRM does this when plane size
> > exceeds the framebuffer size(check drm_atomic.c,
> > drm_atomic_plane_check).
> > We hit this issue when we happen to have resolution lower than
> > expected
> > by IGT, so we actually create a framebuffer of smaller size than it
> > sets for the plane and then we
> > hit ENOSPC instead EINVAL, which is treated now as OK by the test
> > case.
> > So adding ERANGE will not help for this bug.
> > Either I should add all three to IGT(ERANGE, ENOSPC, EINVAL) or fix
> > it
> > in the kernel, so that it returns EINVAL instead of ENOSPC.
>
> Hm yeah, pls do, and pls do update the kernel documentation. I'm also
> wondering whether we shouldn't wrap some checks around calls to
> atomic_check in the kernel for this.
> -Daniel
So do you mean I should fix the kernel or igt? :)
>
> >
> > > -Daniel
> > >
> > > > ---
> > > > tests/kms_atomic_transition.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/tests/kms_atomic_transition.c
> > > > b/tests/kms_atomic_transition.c
> > > > index ec5d25de..58bf6280 100644
> > > > --- a/tests/kms_atomic_transition.c
> > > > +++ b/tests/kms_atomic_transition.c
> > > > @@ -282,7 +282,7 @@ retry:
> > > > wm_setup_plane(display, pipe, (1 << n_planes)
> > > > - 1,
> > > > parms, false);
> > > > ret = igt_display_try_commit_atomic(display,
> > > > DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_ATOMIC_ALLOW_MODESET,
> > > > NULL);
> > > >
> > > > - if (ret == -EINVAL) {
> > > > + if (ret != 0) {
> > > > if (cursor_width == sprite_width &&
> > > > cursor_height == sprite_height) {
> > > > igt_assert_f(alpha,
> > > > @@ -472,7 +472,7 @@ run_transition_test(igt_display_t *display,
> > > > enum pipe pipe, igt_output_t *output
> > > > igt_pipe_request_out_fence(pipe_obj);
> > > >
> > > > ret = igt_display_try_commit_atomic(display,
> > > > DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_ATOMIC_ALLOW_MODESET,
> > > > NULL);
> > > > - if (ret != -EINVAL || pipe_obj->n_planes < 3)
> > > > + if (ret == 0 || pipe_obj->n_planes < 3)
> > > > break;
> > > >
> > > > ret = 0;
> > > > --
> > > > 2.17.1
> > > >
> > > > _______________________________________________
> > > > igt-dev mailing list
> > > > igt-dev@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> > >
> > >
> >
> > --
> > Best Regards,
> >
> > Lisovskiy Stanislav
>
>
--
Best Regards,
Lisovskiy Stanislav
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-02-14 8:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 16:18 [igt-dev] [PATCH i-g-t] igt/tests: Fix error checking in kms_atomic_transition Stanislav Lisovskiy via igt-dev
2019-02-13 17:45 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2019-02-13 20:41 ` [igt-dev] [PATCH i-g-t] " Daniel Vetter
2019-02-14 8:22 ` Lisovskiy, Stanislav via igt-dev
2019-02-14 8:25 ` Daniel Vetter
2019-02-14 8:31 ` Lisovskiy, Stanislav via igt-dev [this message]
2019-02-14 8:33 ` Daniel Vetter
2019-02-14 12:14 ` Lisovskiy, Stanislav via igt-dev
2019-02-14 15:30 ` Daniel Vetter
2019-02-14 9:28 ` [igt-dev] ✓ Fi.CI.IGT: success for " 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=729d50520419f53ae843ac495ad467948935b29c.camel@intel.com \
--to=igt-dev@lists.freedesktop.org \
--cc=daniel@ffwll.ch \
--cc=juhapekka.heikkila@intel.com \
--cc=martin.peres@intel.com \
--cc=stanislav.lisovskiy@intel.com \
--cc=ville.syrjala@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox