From: "Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>
To: "juhapekka.heikkila@gmail.com" <juhapekka.heikkila@gmail.com>,
"igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
"bhanuprakash.modem@gmail.com" <bhanuprakash.modem@gmail.com>,
"karthik.b.s@intel.com" <karthik.b.s@intel.com>,
"swati2.sharma@intel.com" <swati2.sharma@intel.com>,
"kamil.konieczny@linux.intel.com"
<kamil.konieczny@linux.intel.com>,
"fshao@chromium.org" <fshao@chromium.org>
Cc: "markyacoub@chromium.org" <markyacoub@chromium.org>,
"jani.nikula@intel.com" <jani.nikula@intel.com>,
"Paul-pl Chen (陳柏霖)" <Paul-pl.Chen@mediatek.com>,
"Nancy Lin (林欣螢)" <Nancy.Lin@mediatek.com>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@mediatek.com>,
"Singo Chang (張興國)" <Singo.Chang@mediatek.com>,
"gildekel@google.com" <gildekel@google.com>
Subject: Re: [PATCH i-g-t v3] tests/kms_content_protection: Optimize framebuffer management
Date: Thu, 26 Mar 2026 16:25:06 +0000 [thread overview]
Message-ID: <9d080b0677d12cdc5c088a4ffaaee8c2226228d5.camel@mediatek.com> (raw)
In-Reply-To: <30fc7420-6ccc-447a-bc56-cb106b587b10@intel.com>
[snip]
> > @@ -869,6 +893,7 @@ test_content_protection_mst(int content_type)
> > igt_crtc_t *crtc;
> > bool pipe_found;
> > igt_output_t *hdcp_mst_output[IGT_MAX_PIPES];
> > + drmModeModeInfo *mode;
> >
> > for_each_crtc(display, crtc)
> > max_pipe++;
> > @@ -889,7 +914,34 @@ test_content_protection_mst(int content_type)
> > igt_assert_f(pipe_found, "No valid pipe found for
> > %s\n", output->name);
> >
> > igt_output_set_crtc(output, crtc);
> > - prepare_modeset_on_mst_output(output, false);
> > +
> > + mode = igt_output_get_mode(output);
> > +
> > + /*
> > + * Check if framebuffers already exist for this
> > crtc from create_fbs().
> > + * Since non-MST tests run first and share the
> > same data.fbs[] array,
> > + * the existing FB may have a different resolution
> > than this MST output
> > + * requires. If so, properly detach planes, remove
> > old FBs, and recreate
> > + * with the correct dimensions for this MST
> > output.
> > + */
> > + if (data.fbs[crtc->crtc_index].red.fb_id) {
> > + igt_plane_t *primary =
> > igt_output_get_plane_type(output,
> > +
> > DRM_PLANE_TYPE_PRIMARY);
> > +
> > + igt_plane_set_fb(primary, NULL);
> > + igt_display_commit2(display,
> > COMMIT_ATOMIC);
> > + igt_remove_fb(data.drm_fd, &data.fbs[crtc-
> > >crtc_index].red);
> > + igt_remove_fb(data.drm_fd, &data.fbs[crtc-
> > >crtc_index].green);
> > + }
> > +
> > + igt_create_color_fb(data.drm_fd, mode->hdisplay,
> > mode->vdisplay,
> > + DRM_FORMAT_XRGB8888,
> > DRM_FORMAT_MOD_LINEAR,
> > + 1.f, 0.f, 0.f, &data.fbs[crtc-
> > >crtc_index].red);
> > + igt_create_color_fb(data.drm_fd, mode->hdisplay,
> > mode->vdisplay,
> > + DRM_FORMAT_XRGB8888,
> > DRM_FORMAT_MOD_LINEAR,
> > + 0.f, 1.f, 0.f, &data.fbs[crtc-
> > >crtc_index].green);
> > +
>
> Do we really need this recreation here before we even tried
> 'igt_override_all_active_output_modes_to_fit_bw'? Because I'm
> thinking
> that the mode we get here should be the same as we got earlier in the
> create_fbs?
>
Hi Karthik,
Thank you for the review! You're absolutely correct.
The framebuffer recreation here is unnecessary since the FB created in
create_fbs() already has the correct dimensions for this output/CRTC
combination. Although we will test non-MST before MST test case, the
physical output connection and CRTC relationship won't change until
here.
I will fix this in the next version by removing this and directly using
the existing framebuffers.
Regards,
Jason-JH Lin
> Regards,
> Karthik.B.S
prev parent reply other threads:[~2026-03-26 16:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 16:01 [PATCH i-g-t v3] tests/kms_content_protection: Optimize framebuffer management Jason-JH Lin
2026-03-17 23:47 ` ✓ Xe.CI.BAT: success for tests/kms_content_protection: Optimize framebuffer management (rev2) Patchwork
2026-03-18 0:02 ` ✓ i915.CI.BAT: " Patchwork
2026-03-18 7:02 ` [PATCH i-g-t v3] tests/kms_content_protection: Optimize framebuffer management Fei Shao
2026-03-19 11:55 ` ✗ Xe.CI.FULL: failure for tests/kms_content_protection: Optimize framebuffer management (rev2) Patchwork
2026-03-26 3:26 ` [PATCH i-g-t v3] tests/kms_content_protection: Optimize framebuffer management Karthik B S
2026-03-26 16:25 ` Jason-JH Lin (林睿祥) [this message]
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=9d080b0677d12cdc5c088a4ffaaee8c2226228d5.camel@mediatek.com \
--to=jason-jh.lin@mediatek.com \
--cc=Nancy.Lin@mediatek.com \
--cc=Paul-pl.Chen@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=Singo.Chang@mediatek.com \
--cc=bhanuprakash.modem@gmail.com \
--cc=fshao@chromium.org \
--cc=gildekel@google.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=juhapekka.heikkila@gmail.com \
--cc=kamil.konieczny@linux.intel.com \
--cc=karthik.b.s@intel.com \
--cc=markyacoub@chromium.org \
--cc=swati2.sharma@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