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 00/11] drm/atomic: don't allow changes to inactive colorops & other fixes
Date: Tue, 11 Aug 2026 18:45:49 +0200 [thread overview]
Message-ID: <20260811171011.184964-1-mwen@igalia.com> (raw)
This series is a follow-up of what was discussed in [1] and on #wayland
IRC channel regarding policy and userspace expectations on changes in
colorop properties and the current status of the color pipeline in which
the colorop is part of. In short, we agreed that userspace can change
properties of colorops that are currently part of an active color
pipeline or when the pipeline is switching status in the same commit.
However, userspace cannot change colorop properties of inactive color
pipeline in the expactation that it will be activated at some point in
the future.
Userspace also expects persistence of color pipeline already set, even
if it becomes inactive for a while, when activated, colorop settings
previouly set should be preserved.
In addition, I found some bugs on IGT tests when this policy is applied.
So I sent bug fixes to kms_colorop and kms_properties to behave
according to this contract (new version) [2]. The rest of the series in
[1] was detached in [3] and already applied. However, after a bad merge
conflict resolution the colorop-update track was removed from AMD and
this series needs it back to make the AMD part work correctly. I've
already resubmitted it [4].
I also tried to address some Sashiko's complaints on pre-existent issues
that affects the stability of this series, but not all since I want to
keep a healthy scope for reviews. AMD fixes are in this series because
of their scope, but they can be detached and applied whenever it's
convenient.
[v1] https://lore.kernel.org/dri-devel/20260526142940.504911-1-mwen@igalia.com/
Changes:
- define a macro to walk in the color pipeline (Alex H.)
- fix checkpatch warning (Alex H.)
[v2] https://lore.kernel.org/dri-devel/20260604180457.1110110-1-mwen@igalia.com/
Changes:
- [Drop] drm/atomic: duplicate state of all colorops
If inactive colorops state are duplicated on resume, the commit will be
rejected.
- [New] Four new patches to make AMD driver match the policy of colorop
updates only for colorops in active color pipelines plus individual
colorop updates. It also tries to untangle COLOR_PIPELINE = Bypass from
colorop BYPASS prop = true. I think patches 3-5 can be cherry-picked and
applied if it looks correct for AMD, I just included them here for
context (for example, Sashiko reported an issue in the previous version
of this series).
[v3] https://lore.kernel.org/dri-devel/20260609121230.1358786-1-mwen@igalia.com/
Changes:
- make drm_atomic_add_affected_colorops static and move to
drm_atomic_helper.c (John H.)
- skip check when just duplicating state for suspend/resume persistence.
- [re-add] drm/atomic: duplicate state of all colorops to preserve all
colorop status in a suspend/resume
- rewite commit message and better explain what's considered an active
colorop (John H.)
- [new] drm/atomic: check if an active colorop has a blob if its type
requires one
- drop the ternary and add just a warn_on since both current callers
iterate planes already in the atomic state in AMD's active pipeline
check (John H.)
- explain the reason to use commited colorop in AMD's active pipeline
check (John H.)
- [new] drm/amd/display: don't ignore failure on blend colorop setup
- [new] drm/amd/display: distinguish colorop setup error from no colorop support
[1] https://lore.kernel.org/dri-devel/20260519211111.228303-1-mwen@igalia.com/
[2] https://lore.kernel.org/igt-dev/20260811143558.141813-1-mwen@igalia.com
[3] https://lore.kernel.org/dri-devel/20260609110420.1298352-1-mwen@igalia.com/
[4] https://lore.kernel.org/dri-devel/20260807115712.22423-1-mwen@igalia.com/
Melissa Wen (11):
drm/atomic: only add states of active or transient active colorops
drm/atomic: reject colorop update from inactive color pipeline
drm/atomic: duplicate state of all colorops
drm/atomic: check if an active colorop has a blob if its type requires one
drm/amd/display: only check colorops of an active color pipeline
drm/amd/display: truly bypass plane colorop 3x4 matrix and hdr mult
drm/amd/display: make shaper bypass mode cleaner
drm/amd/display: make blnd bypass mode clearer
drm/amd/display: don't ignore failure on blend colorop setup
drm/amd/display: allow individual colorop changes
drm/amd/display: distinguish colorop setup error from no colorop support
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 ++-
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 206 +++++++-----------
drivers/gpu/drm/drm_atomic.c | 199 ++++++++++++-----
drivers/gpu/drm/drm_atomic_helper.c | 52 ++++-
include/drm/drm_atomic.h | 3 -
include/drm/drm_colorop.h | 3 +
6 files changed, 304 insertions(+), 192 deletions(-)
--
2.53.0
next reply other threads:[~2026-08-11 17:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 16:45 Melissa Wen [this message]
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 ` [PATCH v4 02/11] drm/atomic: reject colorop update from inactive color pipeline Melissa Wen
2026-09-30 19:18 ` 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
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-1-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