From: "Navare, Manasi" <manasi.d.navare@intel.com>
To: "Modem, Bhanuprakash" <bhanuprakash.modem@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 12:06:41 -0800 [thread overview]
Message-ID: <20220307200641.GA23952@labuser-Z97X-UD5H> (raw)
In-Reply-To: <9296e826-a323-9038-f7c6-17803cecd2e1@intel.com>
On Fri, Mar 04, 2022 at 09:32:29AM +0530, 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.
>
> Am I missing anything?
Yes so in case of VRR, its an enhancement to improve the visual quality.
But if userspace requests VRR but the panel doesnt support it, the kernel will
not reject the mode since having some screen output without VRR is better than no output with a black screen.
So it will succeed with the modeset.
However like the VRR enable register will not be set for example, so if we absolutely want to add a negative test
we can probe the VRR enable register through debugfs that reads the VRR enable i915 register which in this case
will just be 0.
Manasi
>
> - 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 20:05 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
2022-03-07 20:06 ` Navare, Manasi [this message]
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=20220307200641.GA23952@labuser-Z97X-UD5H \
--to=manasi.d.navare@intel.com \
--cc=bhanuprakash.modem@intel.com \
--cc=igt-dev@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