From: "Modem, Bhanuprakash" <bhanuprakash.modem@intel.com>
To: "Navare, Manasi" <manasi.d.navare@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [i-g-t 3/5] tests/kms_vrr: Add Negative tests to validate VRR
Date: Mon, 7 Mar 2022 10:27:41 +0530 [thread overview]
Message-ID: <5d5bd74b-1cbd-29d2-0cfe-dee50e870442@intel.com> (raw)
In-Reply-To: <9296e826-a323-9038-f7c6-17803cecd2e1@intel.com>
On Fri-04-03-2022 09:32 am, Modem, Bhanuprakash wrote:
> On Fri-04-03-2022 06:50 am, Navare, Manasi wrote:
>> On Thu, Feb 24, 2022 at 10:46:46AM +0530, Bhanuprakash Modem wrote:
>>> This patch will try to enable VRR on Non-VRR panel. VRR should
>>> not be enabled on the Non-VRR panel. Hence Kernel should reject
>>> the commit.
>>>
>>> Cc: Manasi Navare <manasi.d.navare@intel.com>
>>> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
>>> ---
>>> tests/kms_vrr.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++--
>>> 1 file changed, 67 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tests/kms_vrr.c b/tests/kms_vrr.c
>>> index 8976d4a6c3..7deab77311 100644
>>> --- a/tests/kms_vrr.c
>>> +++ b/tests/kms_vrr.c
>>> @@ -45,6 +45,7 @@ enum {
>>> TEST_DPMS = 1 << 0,
>>> TEST_SUSPEND = 1 << 1,
>>> TEST_FLIPLINE = 1 << 2,
>>> + TEST_NEGATIVE = 1 << 3,
>>> };
>>> typedef struct range {
>>> @@ -244,6 +245,34 @@ static void prepare_test(data_t *data,
>>> igt_output_t *output, enum pipe pipe)
>>> igt_display_commit2(&data->display, COMMIT_ATOMIC);
>>> }
>>> +static void prepare_negative_test(data_t *data, igt_output_t
>>> *output, enum pipe pipe)
>>> +{
>>> + drmModeModeInfo *mode;
>>> +
>>> + /* Reset output */
>>> + igt_display_reset(&data->display);
>>> + igt_output_set_pipe(output, pipe);
>>> +
>>> + /* Capture VRR range */
>>> + data->range = get_vrr_range(data, output);
>>> +
>>> + /* Prepare resources */
>>> + mode = igt_output_get_mode(output);
>>> + igt_assert(igt_create_fb(data->drm_fd, mode->hdisplay,
>>> mode->vdisplay,
>>> + DRM_FORMAT_XRGB8888, DRM_FORMAT_MOD_LINEAR,
>>> + &data->fb0));
>>> +
>>> + /* Take care of any required modesetting before the test begins. */
>>> + data->primary = igt_output_get_plane_type(output,
>>> DRM_PLANE_TYPE_PRIMARY);
>>> + igt_plane_set_fb(data->primary, &data->fb0);
>>> +
>>> + /* Clear vrr_enabled state before enabling it, because
>>> + * it might be left enabled if the previous test fails.
>>> + */
>>> + igt_pipe_set_prop_value(&data->display, pipe,
>>> IGT_CRTC_VRR_ENABLED, 0);
>>> + igt_display_commit2(&data->display, COMMIT_ATOMIC);
>>> +}
>>> +
>>> /* Performs an atomic non-blocking page-flip on a pipe. */
>>> static void
>>> do_flip(data_t *data, igt_fb_t *fb)
>>> @@ -430,6 +459,32 @@ test_basic(data_t *data, enum pipe pipe,
>>> igt_output_t *output, uint32_t flags)
>>> igt_remove_fb(data->drm_fd, &data->fb0);
>>> }
>>> +/* VRR on Non-VRR panel: VRR should not be enabled on the Non-VRR
>>> panel.
>>> + * Kernel should reject the commit.
>>> + */
>>> +static void
>>> +test_negative_basic(data_t *data, enum pipe pipe,
>>> + igt_output_t *output, uint32_t flags)
>>> +{
>>> + int ret;
>>> +
>>> + igt_info("VRR Negative Test execution on %s, PIPE_%s.\n",
>>> + output->name, kmstest_pipe_name(pipe));
>>> +
>>> + prepare_negative_test(data, output, pipe);
>>> + igt_pipe_set_prop_value(&data->display, pipe,
>>> IGT_CRTC_VRR_ENABLED, 1);
>>> +
>>> + ret = igt_display_try_commit2(&data->display, COMMIT_ATOMIC);
>>> + igt_assert_f(ret == 0, "VRR shouln't be enabled on Non-VRR
>>> panel.\n");
>>
>> No this is not correct since in the kernel, if its a non VRR panel
>> then it will just
>> do the modeset without enabling VRR so you will just see the visual
>> artifacts but not reject it.
>
> Hmm, intel_vrr_compute_config() will just return & even don't care about
> "vrr_enabled" if the panel is Non-VRR.
>
> In general, if we try to commit with invalid config, Kernel must reject
> (with -22 invalid arg) right? Here, we requested to enable VRR, but
> Kernel returned success without enabling it.
>
> So the flow would be:
> * Set "vrr_enabled" on selected pipe & do modeset
> * Readback the "vrr_enabled" prop to make sure that Kernel enabled the
> VRR on selected pipe.
Floated to try-bot: https://patchwork.freedesktop.org/series/100463
Logs:
https://intel-gfx-ci.01.org/tree/drm-tip/TrybotIGT_488/bat-all.html?testfilter=kms_vrr@negative
https://intel-gfx-ci.01.org/tree/drm-tip/TrybotIGT_488/fi-tgl-1115g4/igt@kms_vrr@negative-basic@pipe-a-dp-1.html
Starting subtest: negative-basic
Starting dynamic subtest: pipe-A-DP-1
(kms_vrr:5413) CRITICAL: Test assertion failure function
test_negative_basic, file ../tests/kms_vrr.c:483:
(kms_vrr:5413) CRITICAL: Failed assertion: !vrr_enabled
(kms_vrr:5413) CRITICAL: VRR shouln't be enabled on Non-VRR panel.
Dynamic subtest pipe-A-DP-1 failed.
VRR is getting enabled on non-VRR panels.
- Bhanu
>
> Am I missing anything?
>
> - Bhanu
>
>>
>> Manasi
>>
>>> +
>>> + /* Clean-up */
>>> + igt_plane_set_fb(data->primary, NULL);
>>> + igt_output_set_pipe(output, PIPE_NONE);
>>> + set_vrr_on_pipe(data, pipe, false);
>>> +
>>> + igt_remove_fb(data->drm_fd, &data->fb0);
>>> +}
>>> +
>>> /* Runs tests on outputs that are VRR capable. */
>>> static void
>>> run_vrr_test(data_t *data, test_t test, uint32_t flags)
>>> @@ -439,8 +494,14 @@ run_vrr_test(data_t *data, test_t test, uint32_t
>>> flags)
>>> for_each_connected_output(&data->display, output) {
>>> enum pipe pipe;
>>> - if (!has_vrr(output))
>>> - continue;
>>> + /* For Negative tests, panel should be non-vrr. */
>>> + if (flags & TEST_NEGATIVE) {
>>> + if (has_vrr(output))
>>> + continue;
>>> + } else {
>>> + if (!has_vrr(output))
>>> + continue;
>>> + }
>>> for_each_pipe(&data->display, pipe) {
>>> if (igt_pipe_connector_valid(pipe, output)) {
>>> @@ -486,6 +547,10 @@ igt_main
>>> igt_subtest_with_dynamic("flipline")
>>> run_vrr_test(&data, test_basic, TEST_FLIPLINE);
>>> + igt_describe("Make sure that VRR should not be enabled on the
>>> Non-VRR panel.");
>>> + igt_subtest_with_dynamic("negative-basic")
>>> + run_vrr_test(&data, test_negative_basic, TEST_NEGATIVE);
>>> +
>>> igt_fixture {
>>> igt_display_fini(&data.display);
>>> }
>>> --
>>> 2.35.0
>>>
>
next prev parent reply other threads:[~2022-03-07 4:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 5:16 [igt-dev] [i-g-t 0/5] Add Negative tests to VRR Bhanuprakash Modem
2022-02-24 5:16 ` [igt-dev] [i-g-t 1/5] tests/kms_vrr: Create dynamic subtests Bhanuprakash Modem
2022-03-04 1:01 ` Navare, Manasi
2022-02-24 5:16 ` [igt-dev] [i-g-t 2/5] lib/igt_edid: Helper to read monitor range from EDID Bhanuprakash Modem
2022-02-24 8:32 ` [igt-dev] [v2 i-g-t " Bhanuprakash Modem
2022-03-04 1:07 ` [igt-dev] [i-g-t " Navare, Manasi
2022-03-04 3:12 ` Modem, Bhanuprakash
2022-02-24 5:16 ` [igt-dev] [i-g-t 3/5] tests/kms_vrr: Add Negative tests to validate VRR Bhanuprakash Modem
2022-03-04 1:20 ` Navare, Manasi
2022-03-04 4:02 ` Modem, Bhanuprakash
2022-03-07 4:57 ` Modem, Bhanuprakash [this message]
2022-03-07 20:06 ` Navare, Manasi
2022-03-08 4:13 ` Modem, Bhanuprakash
2022-02-24 5:16 ` [igt-dev] [i-g-t 4/5] tests/kms_vrr: Add a test for VRR range capability Bhanuprakash Modem
2022-02-24 5:16 ` [igt-dev] [i-g-t 5/5] HAX: Add VRR negative tests to BAT Bhanuprakash Modem
2022-02-24 6:53 ` [igt-dev] ✓ Fi.CI.BAT: success for Add Negative tests to VRR (rev3) Patchwork
2022-02-24 8:59 ` [igt-dev] ✗ GitLab.Pipeline: warning for Add Negative tests to VRR (rev4) Patchwork
2022-02-24 9:27 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2022-02-24 18:53 ` [igt-dev] ✓ Fi.CI.IGT: success for Add Negative tests to VRR (rev3) Patchwork
2022-02-24 22:01 ` [igt-dev] ✗ Fi.CI.IGT: failure for Add Negative tests to VRR (rev4) 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=5d5bd74b-1cbd-29d2-0cfe-dee50e870442@intel.com \
--to=bhanuprakash.modem@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=manasi.d.navare@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.