wireguard-linux/drivers/gpu/drm/amd/display/amdgpu_dm, branch davem/net

drm/amd/display: Fix dc stream excess put in dm_update_crtc_state()

2026-09-23T19:51:09Z

In dm_update_crtc_state(), when a modeset is required the newly created stream is stored in dm_new_crtc_state->stream and an extra reference is taken with dc_stream_retain(). The reference returned by create_validate_stream_for_sink() is released as an extra reference at the skip_modeset label, leaving the stream owned by the new CRTC state. If amdgpu_dm_check_crtc_color_mgmt() fails afterwards, the code jumps to the fail label which releases new_stream again. Since the extra reference was already released at skip_modeset, this drops the reference owned by dm_new_crtc_state->stream and the stream is released while the atomic state still points to it, leading to a premature free of the dc stream. Set new_stream to NULL after releasing the extra reference at the skip_modeset label so that a later goto fail cannot release the reference owned by the new CRTC state. Fixes: 7cd4b70091a5 ("drm/amd/display: Rework CRTC color management") Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher (cherry picked from commit 102a47065a62dc8f6bbbb47cf082a2934282eb08) Cc: stable@vger.kernel.org

drm/amd/display: Atomize IRQ register read/modify/write ops

2026-09-17T15:52:06Z

[Why] The OTG_GLOBAL_SYNC_STATUS register controls various HW IRQ sources for the output timing generator (OTG). VUPDATE_NO_LOCK is one of them. To enable the IRQ, driver sets the VUPDATE_NO_LOCK_EN bit in the GLOBAL_SYNC_STATUS register. To ack the IRQ after it fires, the driver sets the VUPDATE_NO_LOCK_CLEAR bit in the same GLOBAL_SYNC_STATUS register. The bit sets are done through read/modify/write operations, which are not atomic. Thus, the following race is possible: Thread A: IRQ handler: *HW IRQ fires* # IRQ disable val = read(GLOBAL_SYNC_STATUS) unset(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # ACK reads VUPDATE_NO_LOCK_EN unset val1 = read(GLOBAL_SYNC_STATUS) set(val1, VUPDATE_NO_LOCK_CLEAR) # IRQ enable val = read(GLOBAL_SYNC_STATUS) set(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # BAD! clears VUPDATE_NO_LOCK_EN write(val1, GLOBAL_SYNC_STATUS) Regarding the tagged Fixes: change, it appears the change made this race more likely to occur. Since VUPDATE_NO_LOCK is now the sole IRQ source for vblank handling, a single race on high refresh panels can lead to a time out. [How] The GLOBAL_SYNC_STATUS register is only one example, other IRQ control registers also share the same scheme. On top of GLOBAL_SYNC_STATUS, let's clean up those as well. To keep things simple, Let's atomize the IRQ rmw ops via a single driver-wide spinlock. Due to the small scope of this lock, it is unlikely to cause noticeable overhead on top of all the existing locking within the IRQ set/handle paths. Since DM is responsible for locking, wrap dc_interrupt_set/ack with the spinlock in the new amdgpu_dm_irq_set/ack functions. Migrate/drop all references in DM to dc_interrupt_set/ack to use amdgpu_dm_irq_set/ack instead. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5616 Fixes: c87e6635d2db ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Reviewed-by: Mario Limonciello Signed-off-by: Leo Li Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 70de0a0216583a53c946155f8c8adedfdca6b4e7) Cc: stable@vger.kernel.org

drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output

2026-09-10T16:55:28Z

amdgpu_dm_get_output_color_space() applies the Broadcast RGB connector property to default RGB output, but always selects full-range output for BT.2020 RGB. Consequently, explicitly selecting Limited has no effect on the output CSC or AVI InfoFrame when HDR uses BT.2020 RGB. Select COLOR_SPACE_2020_RGB_LIMITEDRANGE when the output encoding is RGB and Broadcast RGB is Limited. Keep Automatic and Full at full range, and leave YCbCr output unchanged. Add KUnit coverage for limited-range RGB output through both BT.2020 connector colorspace values. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 022236eaa63bbf65761aa8aec43f661451a94654) Cc: stable@vger.kernel.org

drm/amd/display: Propagate HDMI RGB quantization selectability

2026-09-10T16:55:08Z

DC uses dc_edid_caps.qs_bit when constructing the HDMI AVI InfoFrame quantization-range field. Although DRM parses the sink capability into drm_display_info, DM never copies it into the DC EDID capabilities. The field therefore remains zero and the AVI quantization range stays at its default value. Copy rgb_quant_range_selectable for HDMI sinks and extend the existing EDID-capability KUnit test to cover it. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 892659399f64642e33072562a11ec1b2e7bd2263) Cc: stable@vger.kernel.org

drm/amd/display: Fix HF-VSDB DSC bpc detection to be cumulative

2026-09-10T16:54:31Z

[Why & How] The HDMI Forum VSDB reports the maximum DSC color depth a sink supports. This maximum is cumulative: a sink that reports 12 bpc also supports 10 and 8 bpc. The previous code used exact "== 10" and "== 12" comparisons chained with else-if, so a 12 bpc sink only set frl_dsc_12bpc and never set frl_dsc_10bpc, incorrectly narrowing the DSC bpc range usable with that sink. Use ">= 10" and a separate ">= 12" check so a sink advertising a higher maximum also enables the lower DSC bit depths it supports. Reviewed-by: Alex Hung Signed-off-by: Fangzhi Zuo Signed-off-by: Ray Wu Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 4523adbf4dca157aea96a6f28b4e7b7ebd4d5eda)

drm/amd/display: Exit IPS before connector detection on resume

2026-09-10T16:53:44Z

[Why & How] On resume, dm_resume() walks the connector list and, for each connector, calls dc_link_detect_connection_type() at the top of the loop iteration before the per-connector dc_exit_ips_for_hw_access() that sits in the detection branch. There is no dc_exit_ips_for_hw_access() before the loop, so the very first HW access relies on an earlier connector having already taken the display out of IPS. Commit d1d51519bc3b ("drm/amd/display: Skip eDP detection when no sink") skips the eDP connector when no panel is present. On a DCN3.5 APU whose eDP link has no sink, the eDP iteration - which used to bring the HW out of IPS first - is now skipped, so a downstream DP connector becomes the first one processed. Its initial DDC/AUX access then runs while the HW is still idle, the AUX transfers time out (-ETIMEDOUT), and the EDID read fails: [drm:dm_helpers_read_local_edid [amdgpu]] *ERROR* EDID err: 2, on connector: DP-1 amdgpu: [drm] *ERROR* No EDID read. Take the display out of IPS once before the detection loop so the first connector processed no longer touches the AUX/DDC engine while the HW is still in idle power state. This keeps the eDP-skip boot/resume optimization while fixing the DP EDID read failure. Fixes: d1d51519bc3b ("drm/amd/display: Skip eDP detection when no sink") Reviewed-by: Roman Li Signed-off-by: Fangzhi Zuo Signed-off-by: Ray Wu Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 86420fe3093161971b4064e05be11ffff1df76aa) Cc: stable@vger.kernel.org

drm/amd/display: Shorten hdmi_frl_status_polling_workqueue

2026-09-10T16:53:07Z

There is a warning when creating the hdmi_frl_status_polling_wq workqueue because "hdmi_frl_status_polling_workqueue" excceds WQ_NAME_LEN: workqueue: name exceeds WQ_NAME_LEN. Truncating to: hdmi_frl_status_polling_workque Shorten the workqueue name to "hdmi_frl_status_polling_wq" like the structure member to avoid the warning. Fixes: 5c9b8b27a883 ("drm/amd/display: Tie FRL support into amdgpu_dm") Reviewed-by: Alex Hung Signed-off-by: Nathan Chancellor Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260618-amdgpu-fix-wq_name_len-warning-v2-1-ef0e2e6f5be7@kernel.org Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 767ae341b68193fda5fdbc510b2d77e3e8938039)

dm/amdgpu: fix malformed link_settings debugfs output

2026-09-10T16:52:59Z

[Why] dp_link_settings_read() passed strlen() of each format string as the size argument to snprintf() and then advanced rd_buf_ptr by that same fixed amount. The format-string length has no relation to the formatted output length, so snprintf() truncated each field at a NUL it wrote inside the buffer while the pointer was advanced past it. The result is a buffer peppered with embedded NUL bytes and fields that are silently cut short, so the data read back from the debugfs node does not reflect the actual link settings. [How] Use scnprintf() with the real remaining buffer size (rd_buf_size - (rd_buf_ptr - rd_buf)) and advance rd_buf_ptr by its return value, which is the number of characters actually written. This both bounds each write to the space left in rd_buf and keeps the output a single, properly terminated string. The now-unused str_len local is removed. Fixes: 41db5f1931ec ("drm/amd/display: set-read link rate and lane count through debugfs") Assisted-by: Copilot:claude-opus-4.8 Signed-off-by: Harry Wentland Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 43b9f0f18693c7f7b75613f3aeae25fa2b4e2f76) Cc: stable@vger.kernel.org

drm/amd/display: Consult MCCS FreeSync cap only if requested & supported

2026-09-10T16:52:39Z

When the do_mccs parameter is false, we don't call dm_helpers_read_mccs_caps, so sink->mccs_caps.freesync_supported is unlikely to be true. Fixes: 6f71d5dd3206 ("drm/amd/display: Read sink freesync support via mccs") Bug: https://gitlab.freedesktop.org/drm/amd/-/work_items/5286 Signed-off-by: Michel Dänzer Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit ac3aea794fb4156467b4b3b92c3155d95bf435c9) Cc: stable@vger.kernel.org

Merge tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2026-09-06T03:45:18Z

Pull kmalloc_obj conversions from Kees Cook: "Another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci" * tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: treewide: refresh kmalloc_obj() conversions drm/amd/display: Fix harmless type mismatch in allocation