[PATCH 0/2] drm/amd/display: don't overwrite regamma LUT with empty data

[PATCH 0/2] drm/amd/display: don't overwrite regamma LUT with empty data

[Melissa Wen]

Hey,


KDE/Plasma users reported some flickering when applying the regamma CRTC
LUT to an AMD display hardware set using an external or integrated
screen. There is some instability in how the driver stores and updates
color blocks based on color management changes or full update request.
It uses update_flag bits for surface and stream and forces some color
blocks to update without considering the previous settings.

This two-patch series avoids this issue by
(1) not calling set_output_transfer_func when the output TF has not
changed;
(2) preserve the previous out_tf value in the case of a full
update, which was unconditionally setting all update_flag bits to true
regardless of previous values.

This modifies DC and may affect behavior on other platforms. On the
other hand, it avoids unnecessary reprogramming of MPC output gamma.

Melissa

Melissa Wen (2):
  Revert "drm/amd/display: program output tf when required"
  drm/amd/display: don't update out gamma if out_tf didn't change

 drivers/gpu/drm/amd/display/dc/core/dc.c                | 5 +++++
 drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 5 +----
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.47.2

[PATCH 1/2] Revert "drm/amd/display: program output tf when required"

[Melissa Wen]

This reverts commit bb622e0c004404b6131633faa6bd8c4939b1df42.

There are two issues in this commit:

1. Since commit a4056c2a6344, the output_tf_change bit of the stream
   update flags is not handled anywhere in the driver and only changes
   values in case of an UPDATE_TYPE_FULL, which sets
   update_flags.raw = 0xFFFFFFFF.  However, this bit still conditions
   `.set_output_transfer_func` calls in the DCN2+ and DCN3+ hardware
   sequence.

2. Every time the plane state changes, the driver updates the output
   gamma LUT from empty data, since the color management has not changed
   and no new gamma LUT data has been passed, but the plane_changed bit
   calls set_output_transfer_func using only the initial/default value of
   the output TF, regardless of the user space request.

Due to these unexpected calls to set output TF with empty data, regamma
settings are lost even if color management has not been changed, as
reported by Linux KDE/Plasma users.

Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4444
Reported-by: Xaver Hugl <xaver.hugl@gmail.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
---
 drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
index 7d24fa1517bf..226424ffcb08 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
@@ -1982,10 +1982,7 @@ static void dcn20_program_pipe(
 	 * updating on slave planes
 	 */
 	if (pipe_ctx->update_flags.bits.enable ||
-		pipe_ctx->update_flags.bits.plane_changed ||
-		pipe_ctx->stream->update_flags.bits.out_tf ||
-		(pipe_ctx->plane_state &&
-			pipe_ctx->plane_state->update_flags.bits.output_tf_change))
+	    pipe_ctx->stream->update_flags.bits.out_tf)
 		hws->funcs.set_output_transfer_func(dc, pipe_ctx, pipe_ctx->stream);
 
 	/* If the pipe has been enabled or has a different opp, we
-- 
2.47.2

[PATCH 2/2] drm/amd/display: don't update out gamma if out_tf didn't change

[Melissa Wen]

Whenever a full update is requested, the DC sets out_tf to true, forcing
the output transfer function to be reprogrammed, but without transfer
function settings (neither new nor previous). This unsolicited update of
the output transfer function causes the previous setting, made when user
space modified color management properties, to be lost. To avoid this,
make the out_tf bit state persist through a full update and prevent
reprogramming the output gamma LUT from empty/default data.

Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4444
Reported-by: Xaver Hugl <xaver.hugl@gmail.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
index c30d9ee51c83..92775deea650 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2195,9 +2195,11 @@ static enum dc_status dc_commit_state_no_check(struct dc *dc, struct dc_state *c
 	/* Full update should unconditionally be triggered when dc_commit_state_no_check is called */
 	for (i = 0; i < context->stream_count; i++) {
 		uint32_t prev_dsc_changed = context->streams[i]->update_flags.bits.dsc_changed;
+		uint32_t prev_out_tf = context->streams[i]->update_flags.bits.out_tf;
 
 		context->streams[i]->update_flags.raw = 0xFFFFFFFF;
 		context->streams[i]->update_flags.bits.dsc_changed = prev_dsc_changed;
+		context->streams[i]->update_flags.bits.out_tf = prev_out_tf;
 	}
 
 	determine_pipe_unlock_order(dc, context);
@@ -3034,8 +3036,11 @@ enum surface_update_type dc_check_update_surfaces_for_stream(
 	if (type == UPDATE_TYPE_FULL) {
 		if (stream_update) {
 			uint32_t dsc_changed = stream_update->stream->update_flags.bits.dsc_changed;
+			uint32_t out_tf = stream_update->stream->update_flags.bits.out_tf;
+
 			stream_update->stream->update_flags.raw = 0xFFFFFFFF;
 			stream_update->stream->update_flags.bits.dsc_changed = dsc_changed;
+			stream_update->stream->update_flags.bits.out_tf = out_tf;
 		}
 		for (i = 0; i < surface_count; i++)
 			updates[i].surface->update_flags.raw = 0xFFFFFFFF;
-- 
2.47.2

Re: [PATCH 0/2] drm/amd/display: don't overwrite regamma LUT with empty data

[Melissa Wen]

On 22/08/2025 18:14, Melissa Wen wrote:
> Hey,
>
>
> KDE/Plasma users reported some flickering when applying the regamma CRTC
> LUT to an AMD display hardware set using an external or integrated
> screen. There is some instability in how the driver stores and updates
> color blocks based on color management changes or full update request.
> It uses update_flag bits for surface and stream and forces some color
> blocks to update without considering the previous settings.
>
> This two-patch series avoids this issue by
> (1) not calling set_output_transfer_func when the output TF has not
> changed;
> (2) preserve the previous out_tf value in the case of a full
> update, which was unconditionally setting all update_flag bits to true
> regardless of previous values.
>
> This modifies DC and may affect behavior on other platforms. On the
> other hand, it avoids unnecessary reprogramming of MPC output gamma.
I linked in each patch but better refer the AMD issue here too:
- https://gitlab.freedesktop.org/drm/amd/-/issues/4444
>
> Melissa
>
> Melissa Wen (2):
>    Revert "drm/amd/display: program output tf when required"
>    drm/amd/display: don't update out gamma if out_tf didn't change
>
>   drivers/gpu/drm/amd/display/dc/core/dc.c                | 5 +++++
>   drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 5 +----
>   2 files changed, 6 insertions(+), 4 deletions(-)
>

Re: [PATCH 0/2] drm/amd/display: don't overwrite regamma LUT with empty data

[Melissa Wen]

On 22/08/2025 18:14, Melissa Wen wrote:
> Hey,
>
>
> KDE/Plasma users reported some flickering when applying the regamma CRTC
> LUT to an AMD display hardware set using an external or integrated
> screen. There is some instability in how the driver stores and updates
> color blocks based on color management changes or full update request.
> It uses update_flag bits for surface and stream and forces some color
> blocks to update without considering the previous settings.
>
> This two-patch series avoids this issue by
> (1) not calling set_output_transfer_func when the output TF has not
> changed;
> (2) preserve the previous out_tf value in the case of a full
> update, which was unconditionally setting all update_flag bits to true
> regardless of previous values.
>
> This modifies DC and may affect behavior on other platforms. On the
> other hand, it avoids unnecessary reprogramming of MPC output gamma.
FWIW, I just sent a v2 with a completely different approach that solves 
all Gamma LUT issues on DM (without touching DC).

https://lore.kernel.org/amd-gfx/20250901214413.12675-1-mwen@igalia.com/

Melissa

>
> Melissa
>
> Melissa Wen (2):
>    Revert "drm/amd/display: program output tf when required"
>    drm/amd/display: don't update out gamma if out_tf didn't change
>
>   drivers/gpu/drm/amd/display/dc/core/dc.c                | 5 +++++
>   drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 5 +----
>   2 files changed, 6 insertions(+), 4 deletions(-)
>