All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Peres, Martin" <martin.peres@intel.com>
To: "Hiler, Arkadiusz" <arkadiusz.hiler@intel.com>,
	"igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>
Cc: "Latvala, Petri" <petri.latvala@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t 2/2] tests/kms_chamelium: Don't fail random palnes tests on invalid config
Date: Thu, 12 Mar 2020 11:15:11 +0000	[thread overview]
Message-ID: <bc3aec7ff3264fb397beb80c6dc25caa@intel.com> (raw)
In-Reply-To: 20200312095137.551252-2-arkadiusz.hiler@intel.com

s/palnes/planes

On 2020-03-12 11:51, Hiler, Arkadiusz wrote:
> It is possible to generate a configuration that the driver rejects
> because it cannot be handled (e.g. exceeding the number of available
> scalers). Until now the test was failing in such cases with:
> 
>   igt_kms-CRITICAL: Test assertion failure function igt_display_commit_atomic, file ../lib/igt_kms.c:3490:
>   igt_kms-CRITICAL: Failed assertion: ret == 0
>   igt_kms-CRITICAL: Last errno: 22, Invalid argument
>   igt_kms-CRITICAL: error: -22 != 0
> 
> With this change we will just note that the atomic commit is invalid and
> pass the test without causing random noise.

I was about to object strongly, but thinking about it further, I think
this whole subtest makes no sense. We have a ton of tests for planes,
and if the targeted HW does not have support for CRCs, then it should be
emulated using pipe writeback or using chamelium as a source of CRC.

Anyway, fixing this test would require a loop of atomic tries until a
suitable configuration would be found, until then, I would rather skip
than give the idea that the test could test anything.

In summary, either:

 - nuke the subtest
 - make it skip upon atomic check failure
 - fix it by looking for valid configurations

I am just against the idea of passing a test without it doing anything.

Martin
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  parent reply	other threads:[~2020-03-12 11:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-12  9:51 [igt-dev] [PATCH i-g-t 1/2] tests/kms_chamelium: Don't use CCS modifiers in random plane setup Arkadiusz Hiler
2020-03-12  9:51 ` [igt-dev] [PATCH i-g-t 2/2] tests/kms_chamelium: Don't fail random palnes tests on invalid config Arkadiusz Hiler
2020-03-12 10:12   ` Petri Latvala
2020-03-12 11:15   ` Peres, Martin [this message]
2020-03-12 11:23     ` Arkadiusz Hiler
2020-03-12 10:47 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/2] tests/kms_chamelium: Don't use CCS modifiers in random plane setup Patchwork
2020-03-13  3:20 ` [igt-dev] ✓ Fi.CI.IGT: " 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=bc3aec7ff3264fb397beb80c6dc25caa@intel.com \
    --to=martin.peres@intel.com \
    --cc=arkadiusz.hiler@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=petri.latvala@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 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.