All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Harry Wentland" <harry.wentland@amd.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 10/11] drm/amd/display: Set color_space to plane_infos
Date: Wed, 22 Jul 2026 14:13:48 +0000	[thread overview]
Message-ID: <20260722141348.854711F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260722134607.136293-11-harry.wentland@amd.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Changes to DRM plane color pipeline properties (drm_colorop) do not trigger a DC plane state reset, causing the hardware to use stale color space and colorop properties.
--

--- Patch [10]: [PATCH v4 10/11] drm/amd/display: Set color_space to plane_infos ---
commit d69c24f2afbe9ab20f934e3e3173c2c3d2c7b892
Author: Harry Wentland <harry.wentland@amd.com>

drm/amd/display: Set color_space to plane_infos

This commit assigns the color space from the dc_plane directly to the
plane_infos array in the update bundle during plane commits. This replaces
the legacy behavior that handled COLOR_ENCODING and COLOR_RANGE inside
fill_plane_color_attributes.

> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 4f07fe5688262..779f98e8d2d7d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4288,6 +4288,8 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_commit *state,
>  			&bundle->flip_addrs[planes_count].address,
>  			afb->tmz_surface);
>  
> +		bundle->plane_infos[planes_count].color_space = dc_plane->color_space;
> +
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Could this assignment use a stale color_space value?

When userspace dynamically updates a property on an active drm_colorop
pipeline, DRM core sets new_plane_state->color_mgmt_changed = true.

However, should_reset_plane() incorrectly omits checking
new_other_state->color_mgmt_changed or iterating over drm_colorop_state
property changes:

drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:should_reset_plane() {
	...
	/* Colorspace changes. */
	if (old_other_state->color_range != new_other_state->color_range ||
	    old_other_state->color_encoding != new_other_state->color_encoding)
		return true;
	...
}

Because should_reset_plane() returns false when only colorop pipeline
properties are modified, dm_update_plane_state() skips recreating the
dc_plane_state and bypasses amdgpu_dm_update_plane_color_mgmt().

As a result, stale color space parameters are passed to DC here. Should
should_reset_plane() be updated to properly check for color management changes
so the hardware color pipeline does not retain stale configuration values?

>  		drm_dbg_state(state->dev, "plane: id=%d dcc_en=%d\n",
>  				 new_plane_state->plane->index,
>  				 bundle->plane_infos[planes_count].dcc.enable);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722134607.136293-1-harry.wentland@amd.com?part=10

  reply	other threads:[~2026-07-22 14:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22 13:45 [PATCH v4 00/11] YUV conversion colorop with amdgpu and VKMS Harry Wentland
2026-07-22 13:45 ` [PATCH v4 01/11] drm/colorop: Add DRM_COLOROP_FIXED_MATRIX Harry Wentland
2026-07-22 13:55   ` sashiko-bot
2026-07-22 13:45 ` [PATCH v4 02/11] drm/vkms: Fix limited-range YCbCr to RGB conversion scaling Harry Wentland
2026-07-22 13:45 ` [PATCH v4 03/11] drm/vkms: Add KUnit test for YCbCr to RGB conversion matrices Harry Wentland
2026-07-22 14:01   ` sashiko-bot
2026-07-22 13:46 ` [PATCH v4 04/11] drm/vkms: Add fixed matrix colorop to color pipeline Harry Wentland
2026-07-22 13:46 ` [PATCH v4 05/11] drm/vkms: Add atomic check and matrix handling for fixed matrix colorop Harry Wentland
2026-07-22 13:59   ` sashiko-bot
2026-07-22 13:46 ` [PATCH v4 06/11] drm/amd/display: Add fixed matrix colorop to color pipeline Harry Wentland
2026-07-22 14:03   ` sashiko-bot
2026-07-22 13:46 ` [PATCH v4 07/11] drm/amd/display: Implement fixed matrix colorop color space mapping Harry Wentland
2026-07-22 14:14   ` sashiko-bot
2026-07-22 13:46 ` [PATCH v4 08/11] drm/amd/display: Use GAMCOR for first TF if YUV conversion is needed Harry Wentland
2026-07-22 13:46 ` [PATCH v4 09/11] drm/amd/display: Check actual state during commit_tail Harry Wentland
2026-07-22 14:08   ` sashiko-bot
2026-07-22 13:46 ` [PATCH v4 10/11] drm/amd/display: Set color_space to plane_infos Harry Wentland
2026-07-22 14:13   ` sashiko-bot [this message]
2026-07-22 13:46 ` [PATCH v4 11/11] drm/amd/display: Force GAMCOR for subsampled surfaces with PQ/Gamma22/HLG Harry Wentland

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=20260722141348.854711F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.