kernel/git/stable/linux-stable.git/drivers/gpu, branch master

Merge tag 'amd-drm-fixes-7.3-2026-10-01' of https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes

2026-10-02T23:32:49Z

amd-drm-fixes-7.3-2026-10-01: amdgpu: - dc_state_create_copy() fix - HDMI RGB limited range fix - eDP ASSR fix - DCE 6 fixes - DCE 8.1 fix - SI DPM fixes - Reset fixes - Workaround for multiple SDMA entities with DCC - PWM backlight fix - GPUVM fixes - Switcheroo fix - Error handling leak fixes - GC 6 unload FW leak fix - SDMA 7.1 fix - DML frame size limit fix - RGB vs YCbCr 4:4:4 fix - DP MST fix - DC Power module fixes - MacBookPro14,3 fix amdkfd: - SVM fix radeon: - Sparc64 fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20261001230115.1319089-1-alexander.deucher@amd.com

Merge tag 'mediatek-drm-fixes-20261002' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes

2026-10-02T23:30:15Z

Mediatek DRM Fixes - 20261002 1. Add missing IS_ERR check for ovl_adaptor platform device 2. Fix VID_DOWNSAMPLE_CONFIG register offset 3. Fix pdev reference leak in mtk_drm_bind() 4. Fix runtime PM leak in mtk_hdmi_ddc_v2_probe() 5. Fix ovl adaptor platform device leak Signed-off-by: Dave Airlie From: Chun-Kuang Hu Link: https://patch.msgid.link/20261001234906.14940-1-chunkuang.hu@kernel.org

Merge tag 'drm-intel-fixes-2026-10-01' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes

2026-10-02T01:26:47Z

drm/i915 fixes for v7.3-rc6: - Disable VRR DC balance by default to fix timing issues Signed-off-by: Dave Airlie From: Jani Nikula Link: https://patch.msgid.link/5a9a11777f605b59550783923add4568e974a6ea@intel.com

drm/mediatek: Fix ovl adaptor platform device leak

2026-10-01T23:06:43Z

mtk_drm_probe() creates an OVL adaptor platform device with platform_device_register_data() when the display pipeline requires the OVL adaptor. If a later initialization step fails, the probe error path releases the DRM resources without unregistering the already registered OVL adaptor device. The normal remove path likewise leaves the device registered after the DRM driver is unbound. Keep track of whether the OVL adaptor was successfully registered and unregister it on probe failure. Also recover the platform device from the stored DDP component device and unregister it during normal removal. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260921131156.403652-1-lgs201920130244@gmail.com/ Signed-off-by: Chun-Kuang Hu

drm/mediatek: Fix runtime PM leak in mtk_hdmi_ddc_v2_probe()

2026-10-01T22:52:44Z

pm_runtime_get_sync() unconditionally bumps the usage counter, but nothing puts it back when devm_i2c_add_adapter() fails, leaving the DDC runtime-resumed after a failed probe. Drop the reference on that error path. Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188") Signed-off-by: Wentao Liang Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260916174229.2088824-1-vulab@iscas.ac.cn/ Signed-off-by: Chun-Kuang Hu

drm/mediatek: Fix pdev reference leak in mtk_drm_bind()

2026-10-01T22:40:43Z

When the device is not the mmsys master, mtk_drm_bind() returns early after taking a reference on the disp-mutex device via of_find_device_by_node(), without ever dropping it: mtk_drm_unbind() only puts mutex_dev for the master. Drop the reference before returning from the non-master path. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260916174058.2088709-1-vulab@iscas.ac.cn/ Signed-off-by: Chun-Kuang Hu

drm/amdgpu: reset VI ASIC on MacBookPro14,3

2026-10-01T21:18:34Z

On a MacBookPro14,3 with a Radeon Pro 555 (Polaris11), the framebuffer is at MC address 0 when amdgpu loads after a cold boot, as the firmware leaves it (MC_VM_FB_LOCATION = 0x007f0000), while the VBIOS ASIC_Init table places it at 0xF4_0000_0000 (0xf47ff400). amdgpu reads the location once, at init, so after a re-POST (S3 resume or GPU reset) the framebuffer has moved and the driver keeps programming the old one: the SMU is handed a table that was never written and the GPU does not come back, which leaves the internal panel black. Resetting the ASIC on load makes ASIC_Init run before the driver reads the location, so the driver uses the VBIOS placement from the start and every later re-POST puts the framebuffer back where it already is. Add the Radeon Pro 555 used in this machine to the existing VI reset quirk table. Tested on a MacBookPro14,3 on 6.18.49 with the quirk table backported (the kernel also carries unrelated local PCI and ACPI patches for this machine). The framebuffer is at 0x000000F400000000 after both cold and warm boot, and the GPU survived 9 S3 cycles (lid close and rtcwake, one of them with the lid closed for about 7.5 minutes and a USB-C disk attached), each followed by a few minutes of 3D load; no ring timeouts or VM faults were reported. The reset adds about 0.23 s to amdgpu init. Suggested-by: Christian König Suggested-by: Alex Deucher Link: https://lore.kernel.org/all/20260924132952.25054-1-fbeltranmillalen@gmail.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Francisco Beltrán Millalén Signed-off-by: Alex Deucher (cherry picked from commit b6b1d97218518003107d4446fac278fa3e0a19a0) Cc: stable@vger.kernel.org

drm/amd/pm/si: Fix updating clock limits on AC/DC

2026-10-01T21:18:14Z

Assume that the AC limits are the maximum of all power states, and the DC limits are the maximum of battery power states. This shouldn't make any difference in practice, but is cleaner and more robust against bogus information in the VBIOS. Fixes: e6c5d36756e7 ("drm/amd/pm/si: Fix updating clock limits from power states") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923120354.1027996-2-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit ef8cb9dcc7db7b7abcbdbe870a080cc81e4f0bf3) Cc: stable@vger.kernel.org

drm/amd/display: Fix stale replay_events after mod_power stream removal

2026-10-01T21:18:05Z

[Why] mod_power_remove_stream() shifts the remaining power_entity slots down but does not move replay_events, and mod_power_add_stream() does not initialize it. replay_events therefore stay bound to the map slot instead of the stream. When several streams are disabled in one atomic commit, amdgpu_dm_mod_power_update_streams() removes them one after another. The eDP stream can then be looked up in a slot whose stale replay_events already have replay_event_hw_programming set, so amdgpu_dm_replay_set_event() returns early ("already in desired state") without calling mod_power_set_replay_event(). Replay is not disabled before the eDP panel is powered off. After DPMS on, the sink reports neither replay state nor frame lock (DPCD 0x378 = 0x00, no error bits), so the HPD IRQ recovery does not trigger and the panel stays black until a full modeset. Seen with an eDP panel using FreeSync Replay plus two DP-MST displays: DPMS off/on of all outputs leaves eDP black, while DPMS of eDP alone works. Doing an eDP-only DPMS first makes the next all-output DPMS fail reliably. [How] Shift replay_events together with the PSR cached fields in mod_power_remove_stream() and initialize it to replay_event_vsync in mod_power_add_stream(), matching the psr_event_vsync initial value used for PSR (both vsync events are driven together by amdgpu_dm_crtc_set_static_screen_optimze()). Tested on 7.3.0-rc3 (238650ef6c7c): the reproducer above now recovers reliably, and Replay still engages when the screen is idle. The issue was debugged with help from an AI assistant (Claude), which analysed ftrace/kprobe traces and the driver source, pointed to the missing replay_events handling and suggested this change. I collected the traces and built and tested the fix on the affected hardware. Fixes: 4cef2ac4c795 ("drm/amd/display: Introduce power module on Linux") Assisted-by: Claude:claude-opus-5 Signed-off-by: Simon Polack Reviewed-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 3d47e38e271195435e125527b224d11cfdb777b1) Cc: stable@vger.kernel.org

drm/radeon: Read the VRAM VBIOS signature with readb()

2026-10-01T21:18:05Z

igp_read_bios_from_vram() checked bios[0]/bios[1] with a plain __iomem load, which faults on sparc64 before the copy runs at all. radeon_read_bios() already reads its two signature bytes with readb() ahead of its own copy; use the same accessor here, keeping the check before the allocation. Fixes: b442962a9e82 ("drm/radeon/kms: add support for "Surround View"") Signed-off-by: Imre Kaloz Signed-off-by: Alex Deucher (cherry picked from commit 09155b8932e5013dbce0f5cdff7d75264a279ee5) Cc: stable@vger.kernel.org