linux.git/drivers/gpu/drm/amd/display/dc/core, branch master Linux kernel source tree drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async 2026-05-19T16:13:56+00:00 Harry Wentland harry.wentland@amd.com 2026-05-07T20:26:31+00:00 6c92f6d9600efa3ef0d9e560a2b52776d9803c29 [Why&How] dc_process_dmub_aux_transfer_async() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy. Additionally, link_index is used to dereference dc->links[] without bounds checking against dc->link_count, risking an out-of-bounds access. Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for link_index before it is used. Assisted-by: GitHub Copilot:Claude claude-4-opus Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881) Cc: stable@vger.kernel.org 
[Why&How]
dc_process_dmub_aux_transfer_async() copies payload->length bytes into a
16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which
is a no-op in release builds. If a caller ever passes length > 16 this
results in a stack buffer overflow via memcpy.

Additionally, link_index is used to dereference dc->links[] without
bounds checking against dc->link_count, risking an out-of-bounds access.

Replace the ASSERT with a hard runtime check that returns false when
payload->length exceeds the destination buffer size, and add a bounds
check for link_index before it is used.

Assisted-by: GitHub Copilot:Claude claude-4-opus
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)
Cc: stable@vger.kernel.org
drm/amd/display: Disable 10-bit truncation and dithering on DCE 6.x 2026-04-21T21:03:33+00:00 Timur Kristóf timur.kristof@gmail.com 2026-04-20T23:55:04+00:00 11b31549b6d6ccf9861787de5606d1b9384a8a58 DCE 6.x doesn't support 10-bit truncation and 10-bit dithering because the following fields are 1-bit only: FMT_TEMPORAL_DITHER_DEPTH FMT_SPATIAL_DITHER_DEPTH FMT_TRUNCATE_DEPTH Programming these fields to "2" will program them as if the dithering option was 6-bit, resulting in sub-par picture quality and an ugly "color banding" effect. Note that a recent commit changed the default 10-bit dithering option to DITHER_OPTION_SPATIAL10 which improves the picture quality because it happens to look better, but is still not actually supported by DCE 6.x versions. When the color depth is 10-bit or more, just disable any kind of dithering options on DCE 6.x. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5151 Fixes: 529cad0f945c ("drm/amd/display: Add function to set dither option") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6be8ced880dfe29ce38c2d5e74489822da5c250e) 
DCE 6.x doesn't support 10-bit truncation and 10-bit dithering
because the following fields are 1-bit only:
FMT_TEMPORAL_DITHER_DEPTH
FMT_SPATIAL_DITHER_DEPTH
FMT_TRUNCATE_DEPTH
Programming these fields to "2" will program them as if the
dithering option was 6-bit, resulting in sub-par picture
quality and an ugly "color banding" effect.

Note that a recent commit changed the default 10-bit dithering
option to DITHER_OPTION_SPATIAL10 which improves the picture
quality because it happens to look better, but is still not
actually supported by DCE 6.x versions.

When the color depth is 10-bit or more, just disable
any kind of dithering options on DCE 6.x.

Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5151
Fixes: 529cad0f945c ("drm/amd/display: Add function to set dither option")
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 6be8ced880dfe29ce38c2d5e74489822da5c250e)
drm/amd/display: Remove redundant includes from DC 2026-04-17T19:21:52+00:00 Roman Li Roman.Li@amd.com 2026-04-09T17:37:36+00:00 1fd0c5c91e1c735edd6714e2269a7c734ab895b7 [Why] The explicit include of linux/array_size.h in Display Core (DC) is redundant. The ARRAY_SIZE macro is already provided by dm_services.h (via os_types.h) which DC includes. [How] Remove the unnecessary #include <linux/array_size.h> from dc_hw_sequencer.c and dce_clock_source.c. Fixes: 2d2366176445 ("drm/amd/display: Replace inline NUM_ELEMENTS macro with ARRAY_SIZE") CC: Linus Probert <linus.probert@gmail.com> Signed-off-by: Roman Li <Roman.Li@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
The explicit include of linux/array_size.h in Display Core (DC) is
redundant. The ARRAY_SIZE macro is already provided by dm_services.h
(via os_types.h) which DC includes.

[How]
Remove the unnecessary #include <linux/array_size.h> from
dc_hw_sequencer.c and dce_clock_source.c.

Fixes: 2d2366176445 ("drm/amd/display: Replace inline NUM_ELEMENTS macro with ARRAY_SIZE")
CC: Linus Probert <linus.probert@gmail.com>
Signed-off-by: Roman Li <Roman.Li@amd.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Replace inline NUM_ELEMENTS macro with ARRAY_SIZE 2026-04-03T18:04:43+00:00 Linus Probert linus.probert@gmail.com 2026-04-03T08:22:06+00:00 2d23661764450fc37208c2888c91fa320e830d63 Replaces the use of local NUM_ELEMENTS macro with the ARRAY_SIZE macro defined in <linux/array_size.h>. This aligns with existing coccinelle script array_size.cocci which has been applied to other sources in order to remove inline sizeof(a)/sizeof(a[0]) patterns from other source files. Suggested-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Linus Probert <linus.probert@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Replaces the use of local NUM_ELEMENTS macro with the ARRAY_SIZE macro
defined in <linux/array_size.h>.

This aligns with existing coccinelle script array_size.cocci which has
been applied to other sources in order to remove inline
sizeof(a)/sizeof(a[0]) patterns from other source files.

Suggested-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Linus Probert <linus.probert@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Change dither policy for 10 bpc output back to dithering 2026-04-03T17:57:50+00:00 Mario Kleiner mario.kleiner.de@gmail.com 2026-03-21T05:20:33+00:00 d65bfb1782304b03862c8c725fac608015dffd36 Commit d5df648ec830 ("drm/amd/display: Change dither policy for 10bpc to round") degraded display of 12 bpc color precision output to 10 bpc sinks by switching 10 bpc output from dithering to "truncate to 10 bpc". I don't find the argumentation in that commit convincing, but the consequences highly unfortunate, especially for applications that require effective > 10 bpc precision output of > 10 bpc framebuffers. The argument wasn't something strong like "there are hardware design defects or limitations which require us to work around broken dithering to 10 bpc", or "there are some special use cases which do require truncation to 10 bpc", but essentially "at some point in the past we used truncation in Polaris/Vega times and it looks like it got inadvertently changed for Navi, so let's do that again". I couldn't find evidence for that in the git commit logs for this. The commit message also acknowledges that using dithering "...makes some sense for FP16... ...but not for ARGB2101010 surfaces..." The problem with this is that it makes fp16 surfaces, and especially rgba16 fixed point surfaces, less useful. These are now well supported by Mesa 25.3 and later via OpenGL + EGL, Vulkan/WSI, and by OSS AMDVLK Vulkan/WSI/display, and also by GNOME 50 mutter under Wayland, and they used to provide more than 10 bpc effective precision at the output. Even for 8 or 10 bpc surfaces, the color pipeline behind the framebuffer, e.g., gamma tables, CTM, can be used for color correction and will benefit from an effective > 10 bpc output precision via dithering, retaining some precision that would get lost on the way through the pipeline, e.g., due to non-linear gamma functions. Scientific apps rely on this for > 10 bpc display precision. Truncating to 10 bpc, instead of dithering the pipeline internal 12 bpc precision down to 10 bpc, causes a serious loss of precision. This also creates the undesirable and slightly absurd situation that using a cheap monitor with only 8 bpc input and display panel will yield roughly 12 bpc precision via dithering from 12 -> 8 bpc, whereas investment into a more expensive monitor with 10 bpc input and native 10 bpc display will only yield 10 bpc, even if a fp16 or rgb16 framebuffer and/or a properly set up color pipeline (gamma tables, CTM's etc. with more than 10 bpc out precision) would allow effective 12 bpc precision output. Therefore this patch proposes reverting that commit and going back to dithering down to 10 bpc, consistent with the behaviour for 6 bpc or 8 bpc output. Successfully tested on AMD Polaris DCE 11.2 and Raven Ridge DCN 1.0 with a native 10 bpc capable monitor, outputting a RGBA16 unorm framebuffer and measuring resulting color precision with a photometer. No apparent visual artifacts or problems were observed, and effective precision was measured to be 12 bpc again, as expected. Fixes: d5df648ec830 ("drm/amd/display: Change dither policy for 10bpc to round") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org Cc: Aric Cyr <aric.cyr@amd.com> Cc: Anthony Koo <anthony.koo@amd.com> Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Cc: Krunoslav Kovac <krunoslav.kovac@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reported-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Commit d5df648ec830 ("drm/amd/display: Change dither policy for 10bpc to
round") degraded display of 12 bpc color precision output to 10 bpc sinks
by switching 10 bpc output from dithering to "truncate to 10 bpc".

I don't find the argumentation in that commit convincing, but the
consequences highly unfortunate, especially for applications that
require effective > 10 bpc precision output of > 10 bpc framebuffers.

The argument wasn't something strong like "there are hardware design
defects or limitations which require us to work around broken dithering
to 10 bpc", or "there are some special use cases which do require
truncation to 10 bpc", but essentially "at some point in the past we
used truncation in Polaris/Vega times and it looks like it got
inadvertently changed for Navi, so let's do that again". I couldn't find
evidence for that in the git commit logs for this. The commit message also
acknowledges that using dithering "...makes some sense for FP16...
...but not for ARGB2101010 surfaces..."

The problem with this is that it makes fp16 surfaces, and especially
rgba16 fixed point surfaces, less useful. These are now well
supported by Mesa 25.3 and later via OpenGL + EGL, Vulkan/WSI, and by
OSS AMDVLK Vulkan/WSI/display, and also by GNOME 50 mutter under Wayland,
and they used to provide more than 10 bpc effective precision at the
output.

Even for 8 or 10 bpc surfaces, the color pipeline behind the framebuffer,
e.g., gamma tables, CTM, can be used for color correction and will
benefit from an effective > 10 bpc output precision via dithering,
retaining some precision that would get lost on the way through the
pipeline, e.g., due to non-linear gamma functions.

Scientific apps rely on this for > 10 bpc display precision. Truncating
to 10 bpc, instead of dithering the pipeline internal 12 bpc precision
down to 10 bpc, causes a serious loss of precision. This also creates the
undesirable and slightly absurd situation that using a cheap monitor
with only 8 bpc input and display panel will yield roughly 12 bpc
precision via dithering from 12 -> 8 bpc, whereas investment into a
more expensive monitor with 10 bpc input and native 10 bpc display will
only yield 10 bpc, even if a fp16 or rgb16 framebuffer and/or a properly
set up color pipeline (gamma tables, CTM's etc. with more than 10 bpc out
precision) would allow effective 12 bpc precision output.

Therefore this patch proposes reverting that commit and going back to
dithering down to 10 bpc, consistent with the behaviour for 6 bpc or 8 bpc
output.

Successfully tested on AMD Polaris DCE 11.2 and Raven Ridge DCN 1.0 with
a native 10 bpc capable monitor, outputting a RGBA16 unorm framebuffer and
measuring resulting color precision with a photometer. No apparent visual
artifacts or problems were observed, and effective precision was measured
to be 12 bpc again, as expected.

Fixes: d5df648ec830 ("drm/amd/display: Change dither policy for 10bpc to round")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: stable@vger.kernel.org
Cc: Aric Cyr <aric.cyr@amd.com>
Cc: Anthony Koo <anthony.koo@amd.com>
Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Cc: Krunoslav Kovac <krunoslav.kovac@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reported-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Fixed Silence complier warnings in dc 2026-03-30T19:12:15+00:00 Gaghik Khachatrian gaghik.khachatrian@amd.com 2026-03-09T21:18:25+00:00 f82480fafedf622541276d48a3b4fed20ce5d866 [Why] Resolve compiler warnings by marking unused parameters explicitly. [How] In .c and .h function definitions, keep parameter names in signatures and add a line with `(void)param;` in function body Preserved function signatures and avoids breaking code paths that may reference the parameter under conditional compilation. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Reviewed-by: Austin Zheng <austin.zheng@amd.com> Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com> Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
Resolve compiler warnings by marking unused parameters explicitly.

[How]
In .c and .h function definitions, keep parameter names
in signatures and add a line with `(void)param;` in function body

Preserved function signatures and avoids breaking code paths that
may reference the parameter under conditional compilation.

Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Reviewed-by: Austin Zheng <austin.zheng@amd.com>
Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Move FPU Guards From DML To DC - Part 1 2026-03-30T19:06:10+00:00 Rafal Ostrowski rafal.ostrowski@amd.com 2026-02-24T14:36:09+00:00 3539437f354bd24c98928a80d4db3a23fa2a7b19 [Why] FPU guards (DC_FP_START/DC_FP_END) are required to wrap around code that can manipulates floats. To do this properly, the FPU guards must be used in a file that is not compiled as a FPU unit. If the guards are used in a file that is a FPU unit, other sections in the file that aren't guarded may be end up being compiled to use FPU operations. [How] Added DC_FP_START and DC_FP_END to DC functions that call DML functions using FPU. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Rafal Ostrowski <rafal.ostrowski@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
FPU guards (DC_FP_START/DC_FP_END) are required to wrap around code that
can manipulates floats. To do this properly, the FPU guards must be used
in a file that is not compiled as a FPU unit. If the guards are used in
a file that is a FPU unit, other sections in the file that aren't guarded
may be end up being compiled to use FPU operations.

[How]
Added DC_FP_START and DC_FP_END to DC functions that call DML functions
using FPU.

Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Rafal Ostrowski <rafal.ostrowski@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Revert "drm/amd/display: Refactor DC update checks" 2026-03-30T19:01:06+00:00 Dillon Varone Dillon.Varone@amd.com 2026-03-19T15:31:17+00:00 4e91f4322ebefc93a1f23d101595a45530d5de1f Revert commit c24bb00cc6cf ("drm/amd/display: Refactor DC update checks") [WHY] Causing issues with PSR/Replay, reverting until those can be fixed. Reviewed-by: Martin Leung <Martin.Leung@amd.com> Signed-off-by: Dillon Varone <Dillon.Varone@amd.com> Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Revert commit c24bb00cc6cf ("drm/amd/display: Refactor DC update checks")

[WHY]
Causing issues with PSR/Replay, reverting until those can be fixed.

Reviewed-by: Martin Leung <Martin.Leung@amd.com>
Signed-off-by: Dillon Varone <Dillon.Varone@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Revert "drm/amd/display: Add 3DLUT DMA broadcast support" 2026-03-30T18:58:36+00:00 Dillon Varone Dillon.Varone@amd.com 2026-03-19T15:28:19+00:00 60c741a13fd17ae2ec668442bd5a0cc9dd73e261 Revert commit 7d59465de38e ("drm/amd/display: Add 3DLUT DMA broadcast support") [WHY&HOW] Dependencies of this change are still causing issues, so reverting until those can be fixed. Reviewed-by: Martin Leung <Martin.Leung@amd.com> Signed-off-by: Dillon Varone <Dillon.Varone@amd.com> Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Revert commit 7d59465de38e ("drm/amd/display: Add 3DLUT DMA broadcast support")

[WHY&HOW]
Dependencies of this change are still causing issues, so reverting until
those can be fixed.

Reviewed-by: Martin Leung <Martin.Leung@amd.com>
Signed-off-by: Dillon Varone <Dillon.Varone@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: enable eDP DSC seamless boot support 2026-03-30T18:57:56+00:00 Mohit Bawa Mohit.Bawa@amd.com 2025-11-05T18:58:35+00:00 add9aee8d889a7ffbff9d5ddbf1f5472a7cbfb82 [Why] VBIOS supports DSC for seamless boot on newer hardware. Reading hardware state allows proper DSC validation without breaking existing boot display. [What] Remove DSC block for boot timing validation and implement hardware state reading to populate DSC configuration from VBIOS-configured state. Enhance dsc_read_state function in DCN401 to read additional DSC parameters. Reviewed-by: Yihan Zhu <yihan.zhu@amd.com> Signed-off-by: Mohit Bawa <Mohit.Bawa@amd.com> Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
[Why]
VBIOS supports DSC for seamless boot on newer hardware.
Reading hardware state allows proper DSC validation without breaking
existing boot display.

[What]
Remove DSC block for boot timing validation and implement hardware state
reading to populate DSC configuration from VBIOS-configured state.
Enhance dsc_read_state function in DCN401 to read additional
DSC parameters.

Reviewed-by: Yihan Zhu <yihan.zhu@amd.com>
Signed-off-by: Mohit Bawa <Mohit.Bawa@amd.com>
Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>