All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Wentland <harry.wentland@amd.com>
To: Melissa Wen <mwen@igalia.com>,
	Petri Latvala <adrinael@adrinael.net>,
	Arkadiusz Hiler <arek@hiler.eu>,
	Kamil Konieczny <kamil.konieczny@linux.intel.com>,
	Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>,
	Bhanuprakash Modem <bhanuprakash.modem@gmail.com>,
	Ashutosh Dixit <ashutosh.dixit@intel.com>,
	Karthik B S <karthik.b.s@intel.com>
Cc: igt-dev@lists.freedesktop.org, kernel-dev@igalia.com,
	Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>,
	Alex Hung <alex.hung@amd.com>,
	Swati Sharma <swati2.sharma@intel.com>,
	John Harrison <John.Harrison@Igalia.com>,
	Rodrigo Siqueira <siqueira@igalia.com>,
	Simon Ser <contact@emersion.fr>, Xaver Hugl <xaver.hugl@kde.org>,
	Uma Shankar <uma.shankar@intel.com>
Subject: Re: [PATCH i-g-t v5 4/8] tests/kms_properties: give non-primary planes their own fb
Date: Wed, 30 Sep 2026 12:06:55 -0400	[thread overview]
Message-ID: <a68bfa15-1a1b-4ba8-aab6-7a8089d13b3f@amd.com> (raw)
In-Reply-To: <20260902180016.303482-5-mwen@igalia.com>



On 2026-09-02 13:58, Melissa Wen wrote:
> On AMD drivers, a CRTC remains active only while its primary plane is
> enabled; therefore, handing the primary's fb over to a non-primary plane
> would take the CRTC down with it. Create a dedicated fb for each
> non-primary plane before testing its colorops and discard it again
> afterward, leaving the primary plane and its prepare_crtc() fb intact.
> This is groundwork for the next commit, which checks colorop properties
> on an active color pipeline.
> 

This patch confuses me a bit. You mention that amdgpu needs an
FB on primary planes for a crtc to be active, which makes sense.
But this patch then only deals with non-primary planes. Does
amdgpu have a need for (non-primary) planes to have an attached
FB before allowing a COLOR_PIPELINE?

Harry

> Signed-off-by: Melissa Wen <mwen@igalia.com>
> ---
> 
> v2:
> - detach different changes from a single commit (Chaitanya)
> v3:
> - move hunk from next patch to fix mem leak (Alex H/Chaitanya)
> ---
>   tests/kms_properties.c | 20 +++++++++++++++++++-
>   1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/kms_properties.c b/tests/kms_properties.c
> index 2b4cb152b..c55a271da 100644
> --- a/tests/kms_properties.c
> +++ b/tests/kms_properties.c
> @@ -237,7 +237,7 @@ static void run_colorop_property_tests(igt_display_t *display,
>   				       igt_crtc_t *crtc, igt_output_t *output,
>   				       bool atomic)
>   {
> -	struct igt_fb fb;
> +	struct igt_fb fb, afb;
>   	igt_plane_t *plane;
>   	igt_colorop_t *colorop;
>   	int i;
> @@ -255,6 +255,18 @@ static void run_colorop_property_tests(igt_display_t *display,
>   			 igt_crtc_name(crtc), plane->index,
>   			 kmstest_plane_type_name(plane->type), output->name);
>   
> +		/* A non-primary plane needs an fb of its own: AMD keeps the
> +		 * CRTC active only while the primary plane is enabled.
> +		 */
> +		if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
> +			drmModeModeInfo *mode = igt_output_get_mode(output);
> +
> +			igt_create_pattern_fb(display->drm_fd, mode->hdisplay, mode->vdisplay,
> +					      DRM_FORMAT_XRGB8888, DRM_FORMAT_MOD_LINEAR, &afb);
> +
> +			igt_plane_set_fb(plane, &afb);
> +		}
> +
>   		/* iterate over all color pipelines on plane */
>   		for (i = 0; i < plane->num_color_pipelines; ++i) {
>   			/* iterate over all colorops in pipeline*/
> @@ -272,6 +284,12 @@ static void run_colorop_property_tests(igt_display_t *display,
>   				colorop = igt_find_colorop(display, colorop_id);
>   			}
>   		}
> +
> +		/* only the fb created above needs to go away here */
> +		if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
> +			igt_plane_set_fb(plane, NULL);
> +			igt_remove_fb(display->drm_fd, &afb);
> +		}
>   	}
>   
>   	cleanup_crtc(display, crtc, output,


  reply	other threads:[~2026-09-30 16:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 17:58 [PATCH i-g-t v5 0/8] test/kms_colorop_helper: don't request colorop updates indefinitely Melissa Wen
2026-09-02 17:58 ` [PATCH i-g-t v5 1/8] lib/igt_kms: clear colorop-changed flag after commit Melissa Wen
2026-09-02 17:58 ` [PATCH i-g-t v5 2/8] tests/kms_colorop_helper: only check if a given enum value exists Melissa Wen
2026-09-02 17:58 ` [PATCH i-g-t v5 3/8] tests/kms_properties: don't check colorop if no plane color pipeline prop Melissa Wen
2026-09-02 17:58 ` [PATCH i-g-t v5 4/8] tests/kms_properties: give non-primary planes their own fb Melissa Wen
2026-09-30 16:06   ` Harry Wentland [this message]
2026-09-30 19:37     ` Melissa Wen
2026-09-30 21:02       ` Harry Wentland
2026-09-02 17:58 ` [PATCH i-g-t v5 5/8] lib/igt_kms: extend igt_plane_set_color_pipeline to accept Bypass Melissa Wen
2026-09-09  7:54   ` Borah, Chaitanya Kumar
2026-09-30 15:43   ` Harry Wentland
2026-09-02 17:58 ` [PATCH i-g-t v5 6/8] tests/kms_properties: check colorop properties on active color pipelines Melissa Wen
2026-09-09  7:55   ` Borah, Chaitanya Kumar
2026-09-30 15:44   ` Harry Wentland
2026-09-02 17:58 ` [PATCH i-g-t v5 7/8] tests/intel/kms_color_pipeline: move driver-specific test to intel's folder Melissa Wen
2026-09-08 19:17   ` Sharma, Swati2
2026-09-09  7:56   ` Borah, Chaitanya Kumar
2026-09-30 15:45   ` Harry Wentland
2026-09-02 17:58 ` [PATCH i-g-t v5 8/8] lib/igt_kms: add macros to iterate color pipelines and colorops Melissa Wen
2026-09-03 10:44   ` Jani Nikula
2026-09-09  8:31     ` Jani Nikula
2026-09-09  7:56   ` Borah, Chaitanya Kumar
2026-09-02 23:19 ` ✓ Xe.CI.BAT: success for test/kms_colorop_helper: don't request colorop updates indefinitely (rev3) Patchwork
2026-09-02 23:22 ` ✗ i915.CI.BAT: failure " Patchwork
2026-09-03 15:30 ` ✗ Xe.CI.FULL: " 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=a68bfa15-1a1b-4ba8-aab6-7a8089d13b3f@amd.com \
    --to=harry.wentland@amd.com \
    --cc=John.Harrison@Igalia.com \
    --cc=adrinael@adrinael.net \
    --cc=alex.hung@amd.com \
    --cc=arek@hiler.eu \
    --cc=ashutosh.dixit@intel.com \
    --cc=bhanuprakash.modem@gmail.com \
    --cc=chaitanya.kumar.borah@intel.com \
    --cc=contact@emersion.fr \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=juhapekka.heikkila@gmail.com \
    --cc=kamil.konieczny@linux.intel.com \
    --cc=karthik.b.s@intel.com \
    --cc=kernel-dev@igalia.com \
    --cc=mwen@igalia.com \
    --cc=siqueira@igalia.com \
    --cc=swati2.sharma@intel.com \
    --cc=uma.shankar@intel.com \
    --cc=xaver.hugl@kde.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 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.