From: Melissa Wen <mwen@igalia.com>
To: airlied@gmail.com, alexander.deucher@amd.com, alex.hung@amd.com,
aurabindo.pillai@amd.com, christian.koenig@amd.com,
contact@emersion.fr, daniels@collabora.com,
harry.wentland@amd.com, louis.chauvet@bootlin.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
mwen@igalia.com, sebastian.wick@redhat.com, simona@ffwll.ch,
siqueira@igalia.com, sunpeng.li@amd.com, tzimmermann@suse.de
Cc: Uma Shankar <uma.shankar@intel.com>,
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>,
Xaver Hugl <xaver.hugl@kde.org>,
Pekka Paalanen <pekka.paalanen@collabora.com>,
Matthew Schwartz <matthew.schwartz@linux.dev>,
amd-gfx@lists.freedesktop.org, kernel-dev@igalia.com,
Rob Clark <robin.clark@oss.qualcomm.com>,
Dmitry Baryshkov <lumag@kernel.org>, Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org
Subject: [PATCH v4 02/11] drm/atomic: reject colorop update from inactive color pipeline
Date: Tue, 11 Aug 2026 18:45:51 +0200 [thread overview]
Message-ID: <20260811171011.184964-3-mwen@igalia.com> (raw)
In-Reply-To: <20260811171011.184964-1-mwen@igalia.com>
A colorop can only be changed while it is part of an active color
pipeline, or in the same commit that activates or deactivates that
pipeline. Enforce this contract by checking that the colorop belongs to
the color pipeline of a plane in its current, new or old state, and
rejecting the state change otherwise. Do the check in
drm_atomic_check_only() rather than when the colorop property is set, so
it doesn't depend on the order userspace sets properties within a
commit.
Link: https://lore.kernel.org/dri-devel/20260519211111.228303-1-mwen@igalia.com/
Suggested-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Acked-by: Harry Wentland <harry.wentland@amd.com> #v3
Signed-off-by: Melissa Wen <mwen@igalia.com>
---
v4:
- skip check when just duplicating state for suspend/resume persistence
- rewrite commit message and better explain the change (John H.)
---
drivers/gpu/drm/drm_atomic.c | 76 ++++++++++++++++++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f00df28e2051..86e4348cad58 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -943,6 +943,71 @@ drm_atomic_add_pipeline_colorops(struct drm_atomic_commit *state,
return 0;
}
+/*
+ * drm_atomic_colorop_check - check new colorop state
+ * @new_colorop_state: new colorop state to check
+ *
+ * Ensure that the colorop in @new_colorop_state belongs to an active color
+ * pipeline, i.e. it's in the chain of colorops set to the color_pipeline
+ * property of current, old or new plane state.
+ *
+ * Userspace is allowed to finalize colorop's settings in the same commit that
+ * deactivates its pipeline, and the changes should persist for when that
+ * pipeline is reactivated later. So changes to colorop in the old plane
+ * state's pipeline are accepted even though it won't drive hardware updates.
+ *
+ * Skip this check for duplicated state, since all colorop states must persist
+ * in suspend/resume regardless of whether it belongs to an active color
+ * pipeline or not.
+ *
+ * Returns: 0 on success, -EINVAL otherwise.
+ */
+static int drm_atomic_colorop_check(const struct drm_colorop_state *new_colorop_state)
+{
+ struct drm_atomic_commit *state = new_colorop_state->state;
+ struct drm_plane *plane = new_colorop_state->colorop->plane;
+ struct drm_plane_state *new_plane_state, *old_plane_state;
+ struct drm_colorop *colorop;
+
+ if (state->duplicated)
+ return 0;
+
+ /* Not a plane colorop */
+ if (!plane)
+ return 0;
+
+ new_plane_state = drm_atomic_get_new_plane_state(state, plane);
+ old_plane_state = drm_atomic_get_old_plane_state(state, plane);
+
+ /* No changes in the plane state. Check current-committed plane state */
+ if (!new_plane_state) {
+ drm_for_each_colorop_in_pipeline(colorop, plane->state->color_pipeline)
+ if (colorop == new_colorop_state->colorop)
+ return 0;
+ return -EINVAL;
+ }
+
+ if (WARN_ON(!old_plane_state))
+ return -EINVAL;
+
+ /* Check if the colorop is active in the new plane state */
+ drm_for_each_colorop_in_pipeline(colorop, new_plane_state->color_pipeline)
+ if (colorop == new_colorop_state->colorop)
+ return 0;
+
+ /* Same color pipeline as new; no point walking old. Colorop isn't active */
+ if (new_plane_state->color_pipeline == old_plane_state->color_pipeline)
+ return -EINVAL;
+
+ /* Check if the colorop was active in the old plane state */
+ drm_for_each_colorop_in_pipeline(colorop, old_plane_state->color_pipeline)
+ if (colorop == new_colorop_state->colorop)
+ return 0;
+
+ /* Colorop is not part of an active color pipeline. */
+ return -EINVAL;
+}
+
static void drm_atomic_colorop_print_state(struct drm_printer *p,
const struct drm_colorop_state *state)
{
@@ -1748,6 +1813,8 @@ int drm_atomic_check_only(struct drm_atomic_commit *state)
struct drm_plane *plane;
struct drm_plane_state *old_plane_state;
struct drm_plane_state *new_plane_state;
+ struct drm_colorop *colorop;
+ struct drm_colorop_state *new_colorop_state;
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
struct drm_crtc_state *new_crtc_state;
@@ -1764,6 +1831,15 @@ int drm_atomic_check_only(struct drm_atomic_commit *state)
requested_crtc |= drm_crtc_mask(crtc);
}
+ for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+ ret = drm_atomic_colorop_check(new_colorop_state);
+ if (ret) {
+ drm_dbg_atomic(dev, "[COLOROP:%d:%d] isn't in an active color pipeline.\n",
+ colorop->base.id, colorop->type);
+ return ret;
+ }
+ }
+
for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) {
ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
if (ret) {
--
2.53.0
next prev parent reply other threads:[~2026-08-11 17:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 16:45 [PATCH v4 00/11] drm/atomic: don't allow changes to inactive colorops & other fixes Melissa Wen
2026-08-11 16:45 ` [PATCH v4 01/11] drm/atomic: only add states of active or transient active colorops Melissa Wen
2026-09-30 19:11 ` Harry Wentland
2026-08-11 16:45 ` Melissa Wen [this message]
2026-09-30 19:18 ` [PATCH v4 02/11] drm/atomic: reject colorop update from inactive color pipeline Harry Wentland
2026-08-11 16:45 ` [PATCH v4 03/11] drm/atomic: duplicate state of all colorops Melissa Wen
2026-09-30 19:20 ` Harry Wentland
2026-08-11 16:45 ` [PATCH v4 04/11] drm/atomic: check if an active colorop has a blob if its type requires one Melissa Wen
2026-09-30 19:25 ` Harry Wentland
2026-08-11 16:45 ` [PATCH v4 05/11] drm/amd/display: only check colorops of an active color pipeline Melissa Wen
2026-09-30 19:32 ` Harry Wentland
2026-08-11 16:45 ` [PATCH v4 06/11] drm/amd/display: truly bypass plane colorop 3x4 matrix and hdr mult Melissa Wen
2026-09-30 19:34 ` Harry Wentland
2026-08-11 16:45 ` [PATCH v4 07/11] drm/amd/display: make shaper bypass mode cleaner Melissa Wen
2026-09-30 19:35 ` Harry Wentland
2026-08-11 16:45 ` [PATCH v4 08/11] drm/amd/display: make blnd bypass mode clearer Melissa Wen
2026-09-30 19:36 ` Harry Wentland
2026-08-11 16:45 ` [PATCH v4 09/11] drm/amd/display: don't ignore failure on blend colorop setup Melissa Wen
2026-09-30 19:38 ` Harry Wentland
2026-08-11 16:45 ` [PATCH v4 10/11] drm/amd/display: allow individual colorop changes Melissa Wen
2026-09-30 20:57 ` Harry Wentland
2026-08-11 16:46 ` [PATCH v4 11/11] drm/amd/display: distinguish colorop setup error from no colorop support Melissa Wen
2026-09-30 20:23 ` Harry Wentland
2026-08-11 18:19 ` ✗ Fi.CI.BUILD: failure for drm/atomic: don't allow changes to inactive colorops & other fixes 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=20260811171011.184964-3-mwen@igalia.com \
--to=mwen@igalia.com \
--cc=airlied@gmail.com \
--cc=alex.hung@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=aurabindo.pillai@amd.com \
--cc=chaitanya.kumar.borah@intel.com \
--cc=christian.koenig@amd.com \
--cc=contact@emersion.fr \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=kernel-dev@igalia.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=louis.chauvet@bootlin.com \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=matthew.schwartz@linux.dev \
--cc=mripard@kernel.org \
--cc=pekka.paalanen@collabora.com \
--cc=robin.clark@oss.qualcomm.com \
--cc=sean@poorly.run \
--cc=sebastian.wick@redhat.com \
--cc=simona@ffwll.ch \
--cc=siqueira@igalia.com \
--cc=sunpeng.li@amd.com \
--cc=tzimmermann@suse.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox