linux/drivers/gpu/drm/amd/display, branch v6.19

drm/amd/display: remove assert around dpp_base replacement

2026-02-03T22:21:58Z

There is nothing wrong if in_shaper_func type is DISTRIBUTED POINTS. Remove the assert placed for a TODO to avoid misinterpretations. Signed-off-by: Melissa Wen Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 1714dcc4c2c53e41190896eba263ed6328bcf415)

drm/amd/display: extend delta clamping logic to CM3 LUT helper

2026-02-03T22:21:50Z

Commit 27fc10d1095f ("drm/amd/display: Fix the delta clamping for shaper LUT") fixed banding when using plane shaper LUT in DCN10 CM helper. The problem is also present in DCN30 CM helper, fix banding by extending the same bug delta clamping fix to CM3. Signed-off-by: Melissa Wen Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher (cherry picked from commit 0274a54897f356f9c78767c4a2a5863f7dde90c6)

drm/amd/display: fix wrong color value mapping on MCM shaper LUT

2026-02-03T22:21:43Z

Some shimmer/colorful points appears when using the steamOS color pipeline for HDR on gaming with DCN32. These points look like black values being wrongly mapped to red/blue/green values. It was caused because the number of hw points in regular LUTs and in a shaper LUT was treated as the same. DCN3+ regular LUTs have 257 bases and implicit deltas (i.e. HW calculates them), but shaper LUT is a special case: it has 256 bases and 256 deltas, as in DCN1-2 regular LUTs, and outputs 14-bit values. Fix that by setting by decreasing in 1 the number of HW points computed in the LUT segmentation so that shaper LUT (i.e. fixpoint == true) keeps the same DCN10 CM logic and regular LUTs go with `hw_points + 1`. CC: Krunoslav Kovac Fixes: 4d5fd3d08ea9 ("drm/amd/display: PQ tail accuracy") Signed-off-by: Melissa Wen Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 5006505b19a2119e71c008044d59f6d753c858b9)

drm/amd/display: Clear HDMI HPD pending work only if it is enabled

2026-01-28T20:16:34Z

[Why&How] On amdgpu_dm_connector_destroy(), the driver attempts to cancel pending HDMI HPD work without checking if the HDMI HPD is enabled. Added a check that it is enabled before clearing it. Fixes: 6a681cd90345 ("drm/amd/display: Add an hdmi_hpd_debounce_delay_ms module") Signed-off-by: Ivan Lipski Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Alex Deucher (cherry picked from commit 17b2c526fd8026d8e0f4c0e7f94fc517e3901589)

Merge tag 'amd-drm-fixes-6.19-2026-01-22' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes

2026-01-22T22:12:39Z

amd-drm-fixes-6.19-2026-01-22: amdgpu: - GC 12 fix - Misc error path fixes - DC analog fix - SMU 6 fixes - TLB flush fix - DC idle optimization fix amdkfd: - GC 11 cooperative launch fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20260122204308.946339-1-alexander.deucher@amd.com

Revert "drm/amd/display: pause the workload setting in dm"

2026-01-22T17:10:44Z

This reverts commit bc6d54ac7e7436721a19443265f971f890c13cc5. The workload profile needs to be in the default state when the dc idle optimizaion state is entered. However, when jobs come in for video or GFX or compute, the profile may be set to a non-default profile resulting in the dc idle optimizations not taking affect and resulting in higher power usage. As such we need to pause the workload profile changes during this transition. When this patch was originally committed, it caused a regression with a Dell U3224KB display, but no other problems were reported at the time. When it was reapplied (this patch) to address increased power usage, it seems to have caused additional regressions. This change seems to have a number of side affects (audio issues, stuttering, etc.). I suspect the pause should only happen when all displays are off or in static screen mode, but I think this call site gets called more often than that which results in idle state entry more often than intended. For now revert. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4894 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4717 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4725 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4517 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4806 Cc: Yang Wang Cc: Kenneth Feng Cc: Roman Li Reviewed-by: Yang Wang Signed-off-by: Alex Deucher (cherry picked from commit 1412482b714358ffa30d38fd3dd0b05795163648)

drm/amd/display: Fix color pipeline enum name leak

2026-01-22T09:24:55Z

dm_plane_init_colorops() allocates enum names for color pipelines. These are eventually passed to drm_property_create_enum() which create its own copies of the string. Free the strings after initialization is done. Also, allocate color pipeline enum names only after successfully creating color pipeline. Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block") Signed-off-by: Chaitanya Kumar Borah Reviewed-by: Uma Shankar Reviewed-by: Alex Hung Signed-off-by: Maarten Lankhorst Acked-by: Alex Deucher #irc Link: https://patch.msgid.link/20260113102303.724205-3-chaitanya.kumar.borah@intel.com

drm/amd/display: Only poll analog connectors

2026-01-21T02:53:34Z

Analog connectors may be hot-plugged unlike other connector types that don't support HPD. Stop DRM from polling other connector types that don't support HPD, such as eDP, LVDS, etc. These were wrongly polled when analog connector support was added, causing issues with the seamless boot process. Fixes: c4f3f114e73c ("drm/amd/display: Poll analog connectors (v3)") Signed-off-by: Timur Kristóf Reported-by: Matthew Schwartz Reviewed-by: Mario Limonciello (AMD) Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher (cherry picked from commit e924c7004b08e4e173782bad60b27841d889e371)

drm/amd/display: Add an hdmi_hpd_debounce_delay_ms module

2026-01-14T20:07:43Z

[Why&How] Right now, the HDMI HPD filter is enabled by default at 1500ms. We want to disable it by default, as most modern displays with HDMI do not require it for DPMS mode. The HPD can instead be enabled as a driver parameter with a custom delay value in ms (up to 5000ms). Fixes: c918e75e1ed9 ("drm/amd/display: Add an HPD filter for HDMI") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4859 Signed-off-by: Ivan Lipski Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Alex Deucher (cherry picked from commit 6a681cd9034587fe3550868bacfbd639d1c6891f)

drm/amd/display: Initialise backlight level values from hw

2026-01-14T20:04:42Z

Internal backlight levels are initialised from ACPI but the values are sometimes out of sync with the levels in effect until there has been a read from hardware (eg triggered by reading from sysfs). This means that the first drm_commit can cause the levels to be set to a different value than the actual starting one, which results in a sudden change in brightness. This path shows the problem (when the values are out of sync): amdgpu_dm_atomic_commit_tail() -> amdgpu_dm_commit_streams() -> amdgpu_dm_backlight_set_level(..., dm->brightness[n]) This patch calls the backlight ops get_brightness explicitly at the end of backlight registration to make sure dm->brightness[n] is in sync with the actual hardware levels. Fixes: 2fe87f54abdc ("drm/amd/display: Set default brightness according to ACPI") Signed-off-by: Vivek Das Mohapatra Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Alex Deucher (cherry picked from commit 318b1c36d82a0cd2b06a4bb43272fa6f1bc8adc1) Cc: stable@vger.kernel.org