* [git pull] drm fixes for 7.0-rc1
@ 2026-02-20 20:53 Dave Airlie
2026-02-21 1:20 ` pr-tracker-bot
2026-02-23 12:52 ` Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1) Thorsten Leemhuis
0 siblings, 2 replies; 8+ messages in thread
From: Dave Airlie @ 2026-02-20 20:53 UTC (permalink / raw)
To: Linus Torvalds, Simona Vetter; +Cc: dri-devel, LKML
Hi Linus,
This is the fixes and cleanups for the end of the merge window, it's
nearly all amdgpu, with some amdkfd, then a pagemap core fix, i915/xe
display fixes, and some xe driver fixes. Nothing seems out of the
ordinary, except amdgpu is a little more volume than usual.
Let me know if there are any issues,
Dave.
drm-next-2026-02-21:
drm next fixes for 7.0-rc1
pagemap:
- drm/pagemap: pass pagemap_addr by reference
amdgpu:
- DML 2.1 fixes
- Panel replay fixes
- Display writeback fixes
- MES 11 old firmware compat fix
- DC CRC improvements
- DPIA fixes
- XGMI fixes
- ASPM fix
- SMU feature bit handling fixes
- DC LUT fixes
- RAS fixes
- Misc memory leak in error path fixes
- SDMA queue reset fixes
- PG handling fixes
- 5 level GPUVM page table fix
- SR-IOV fix
- Queue reset fix
- SMU 13.x fixes
- DC resume lag fix
- MPO fixes
- DCN 3.6 fix
- VSDB fixes
- HWSS clean up
- Replay fixes
- DCE cursor fixes
- DCN 3.5 SR DDR5 latency fixes
- HPD fixes
- Error path unwind fixes
- SMU13/14 mode1 reset fixes
- PSP 15 updates
- SMU 15 updates
- Sync fix in amdgpu_dma_buf_move_notify()
- HAINAN fix
- PSP 13.x fix
- GPUVM locking fix
- Fixes for DC analog support
- DC FAMS fixes
- DML 2.1 fixes
- eDP fixes
- Misc DC fixes
- Fastboot fix
- 3DLUT fixes
- GPUVM fixes
- 64bpp format fix
- Fix for MacBooks with switchable gfx
amdkfd:
- Fix possible double deletion of validate list
- Event setup fix
- Device disconnect regression fix
- APU GTT as VRAM fix
- Fix piority inversion with MQDs
- NULL check fix
radeon:
- HAINAN fix
i915/xe display:
- Regresion fix for HDR 4k displays (#15503)
- Fixup for Dell XPS 13 7390 eDP rate limit
- Memory leak fix on ACPI _DSM handling
- Add missing slice count check during DP mode validation
xe:
- drm/xe: Prevent VFs from exposing the CCS mode sysfs file
- SRIOV related fixes
- PAT cache fix
- MMIO read fix
- W/a fixes
- Adjust type of xe_modparam.force_vram_bar_size
- Wedge mode fix
- HWMon fix
The following changes since commit 2f5db9b4002470ea19380326c5a390647c56e780:
Merge tag 'drm-xe-next-fixes-2026-02-05' of
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next (2026-02-06
13:02:44 +1000)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2026-02-21
for you to fetch changes up to ae9e8654579709c2f10b8c86a8467e1710d4599f:
Merge tag 'drm-xe-next-fixes-2026-02-19' of
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next (2026-02-21
06:30:54 +1000)
----------------------------------------------------------------
drm next fixes for 7.0-rc1
pagemap:
- drm/pagemap: pass pagemap_addr by reference
amdgpu:
- DML 2.1 fixes
- Panel replay fixes
- Display writeback fixes
- MES 11 old firmware compat fix
- DC CRC improvements
- DPIA fixes
- XGMI fixes
- ASPM fix
- SMU feature bit handling fixes
- DC LUT fixes
- RAS fixes
- Misc memory leak in error path fixes
- SDMA queue reset fixes
- PG handling fixes
- 5 level GPUVM page table fix
- SR-IOV fix
- Queue reset fix
- SMU 13.x fixes
- DC resume lag fix
- MPO fixes
- DCN 3.6 fix
- VSDB fixes
- HWSS clean up
- Replay fixes
- DCE cursor fixes
- DCN 3.5 SR DDR5 latency fixes
- HPD fixes
- Error path unwind fixes
- SMU13/14 mode1 reset fixes
- PSP 15 updates
- SMU 15 updates
- Sync fix in amdgpu_dma_buf_move_notify()
- HAINAN fix
- PSP 13.x fix
- GPUVM locking fix
- Fixes for DC analog support
- DC FAMS fixes
- DML 2.1 fixes
- eDP fixes
- Misc DC fixes
- Fastboot fix
- 3DLUT fixes
- GPUVM fixes
- 64bpp format fix
- Fix for MacBooks with switchable gfx
amdkfd:
- Fix possible double deletion of validate list
- Event setup fix
- Device disconnect regression fix
- APU GTT as VRAM fix
- Fix piority inversion with MQDs
- NULL check fix
radeon:
- HAINAN fix
i915/xe display:
- Regresion fix for HDR 4k displays (#15503)
- Fixup for Dell XPS 13 7390 eDP rate limit
- Memory leak fix on ACPI _DSM handling
- Add missing slice count check during DP mode validation
xe:
- drm/xe: Prevent VFs from exposing the CCS mode sysfs file
- SRIOV related fixes
- PAT cache fix
- MMIO read fix
- W/a fixes
- Adjust type of xe_modparam.force_vram_bar_size
- Wedge mode fix
- HWMon fix
----------------------------------------------------------------
Alex Deucher (6):
drm/amdgpu/sdma5: enable queue resets unconditionally
drm/amdgpu/sdma5.2: enable queue resets unconditionally
drm/amdgpu/sdma6: enable queue resets unconditionally
drm/amdgpu: re-add the bad job to the pending list for ring resets
drm/amdgpu: set family for GC 11.5.4
drm/amdgpu: keep vga memory on MacBooks with switchable graphics
Alex Hung (4):
drm/amd/display: Fix writeback on DCN 3.2+
drm/amd/display: Fix the incorrect type in dml_print
drm/amd/display: Check return of shaper curve to HW format
drm/amd/display: Remove conditional for shaper 3DLUT power-on
Andrew Martin (3):
drm/amdgpu: Ignored various return code
drm/amdkfd: Disable MQD queue priority
drm/amdkfd: Check for NULL return values
Ankit Nautiyal (1):
drm/i915/quirks: Fix device id for QUIRK_EDP_LIMIT_RATE_HBR2 entry
Arnd Bergmann (1):
drm/pagemap: pass pagemap_addr by reference
Asad Kamal (2):
drm/amd/pm: Add acc counter & fw timestamp to xcp metrics
drm/amd/pm: Use U64 for accumulation counter
Bert Karwatzki (1):
Revert "drm/amd: Check if ASPM is enabled from PCIe subsystem"
Bhuvanachandra Pinninti (5):
drm/amd/display: Migrate DCCG register access from hwseq to dccg
component.
drm/amd/display: Migrate DIO registers access from hwseq to dio component.
drm/amd/display: DIO memory leak fix.
drm/amd/display: Refactor virtual directory reorganize encoder
and hwss files.
drm/amd/display: Migrate DCCG registers access from hwseq to
dccg component.
Ce Sun (1):
drm/amdgpu: Adjust usleep_range in fence wait
Charlene Liu (2):
drm/amd/display: Disable SR feature on eDP1 by default
drm/amd/display: Correct logic check error for fastboot
Chenyu Chen (1):
drm/amd/display: Add CRC 32-bit mode support for DCN3.6+
Christian König (2):
drm/amdgpu: lock both VM and BO in amdgpu_gem_object_open
drm/amdgpu: fix 4-level paging if GMC supports 57-bit VA v2
Clay King (1):
drm/amd/display: bypass post csc for additional color spaces in dal
Dave Airlie (6):
Merge tag 'amd-drm-next-6.20-2026-02-06' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next
Merge tag 'drm-intel-next-fixes-2026-02-13' of
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
Merge tag 'amd-drm-next-6.20-2026-02-13' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next
Merge tag 'amd-drm-next-6.20-2026-02-19' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next
Merge tag 'drm-intel-next-fixes-2026-02-20' of
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
Merge tag 'drm-xe-next-fixes-2026-02-19' of
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next
Dmytro Laktyushkin (2):
drm/amd/display: Add lpddr5 handling to dml2.1
drm/amd/display: Expose functions of other dcn use
Fangzhi Zuo (1):
drm/amd/display: Init DMUB DPIA Only for APU
Gangliang Xie (1):
drm/amdgpu: return when ras table checksum is error
Harish Kasiviswanathan (3):
drm/amdgpu: Fix double deletion of validate_list
drm/amdgpu: Set vmid0 PAGE_TABLE_DEPTH for GFX12.1
drm/amdgpu: Set atomics to true for xgmi
Ian Chen (1):
drm/amd/display: Add oem panel config for new features
Imre Deak (2):
drm/i915/dp: Fix pipe BPP clamping due to HDR
drm/i915/dp: Add missing slice count check during mode validation
Jia Yao (1):
drm/xe: Add bounds check on pat_index to prevent OOB kernel read
in madvise
Jinzhou Su (1):
drm/amdgpu/psp_v15_0_8: Add get ras capability
Karthik Poosa (1):
drm/xe/hwmon: Prevent unintended VRAM channel creation
Kaushlendra Kumar (1):
drm/i915/acpi: free _DSM package when no connectors
Kenneth Feng (2):
drm/amd/pm: use debug port for mode1 reset request on smu 13&14
drm/amd/pm: send unload command to smu during modprobe -r amdgpu
Kent Russell (1):
drm/amdgpu: Send applicable RMA CPERs at end of RAS init
Leo Li (1):
drm/amd/display: Increase DCN35 SR enter/exit latency
Leon Huang (1):
drm/amd/display: Check frame skip capability in Sink side
Lijo Lazar (6):
drm/amd/pm: Use feature bits data structure
drm/amd/pm: Change get_enabled_mask signature
drm/amd/pm: Add default feature number definition
drm/amdgpu: Skip vcn poison irq release on VF
drm/amd/pm: Remove buffer allocation in SMUv13.0.6
drm/amdgpu: Move xgmi status to interface header
Mangesh Gadre (1):
drm/amdgpu:Add psp v13_0_15 ip block
Mario Kleiner (1):
drm/amd/display: Use same max plane scaling limits for all 64 bpp formats
Mario Limonciello (2):
drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52
drm/amd: Fix hang on amdgpu unload by using pci_dev_is_disconnected()
Matt Roper (1):
drm/xe/xe2_hpg: Fix handling of Wa_14019988906 & Wa_14019877138
Melissa Wen (4):
drm/amd/display: fix wrong color value mapping on MCM shaper LUT
drm/amd/display: extend delta clamping logic to CM3 LUT helper
drm/amd/display: remove assert around dpp_base replacement
drm/amd/display: expose plane blend LUT in HW with MCM
Michal Wajdeczko (2):
drm/xe/pf: Fix sysfs initialization
drm/xe/configfs: Fix 'parameter name omitted' errors
Muaaz Nisar (2):
Revert "drm/amd/display: mouse event trigger to boost RR when idle"
drm/amd/display: Implementing ramless idle mouse trigger
Nareshkumar Gollakoti (1):
drm/xe: Prevent VFs from exposing the CCS mode sysfs file
Nicholas Carbones (7):
drm/amd/display: Add Gfx Base Case For Linear Tiling Handling
drm/amd/display: Add Handling for gfxversion DcGfxBase
drm/amd/display: Correct hubp GfxVersion verification
drm/amd/display: Revert "Migrate DCCG register access from hwseq
to dccg component."
Revert "drm/amd/display: Add Handling for gfxversion DcGfxBase"
Revert "drm/amd/display: Correct hubp GfxVersion verification"
Revert "drm/amd/display: Add Gfx Base Case For Linear Tiling Handling"
Nicholas Kazlauskas (3):
drm/amd/display: Make DCN35 OTG disable w/a reusable
drm/amd/display: Make DSC FGCG a DSC block level function
drm/amd/display: Make some DCN35 DCCG symbols non-static
Peichen Huang (2):
drm/amd/display: External panel replay fsm control
drm/amd/display: use enum value for panel replay setting
Perry Yuan (1):
drm/amdgpu: ensure no_hw_access is visible before MMIO
Philip Yang (1):
drm/amdgpu: Use 5-level paging if gmc support 57-bit VA
Pierre-Eric Pelloux-Prayer (1):
drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify
Piotr Piórkowski (1):
drm/xe/vf: Avoid reading media version when media GT is disabled
Pratik Vishwakarma (12):
drm/amdgpu: Load TA ucode for PSP 15_0_0
drm/amd/swsmu: Add new param regs for SMU15
drm/amdgpu: Add support for update_table for SMU15
drm/admgpu: Update metrics_table for SMU15
drm/amdgpu: Fix set_default_dpm_tables
drm/amdgpu: Fix is_dpm_running
drm/amdgpu: Drop unsupported function
drm/amd: Drop MALL
drm/amdgpu: enable mode2 reset for SMU IP v15.0.0
drm/amd: Add CG/PG flags for GC 11.5.4
drm/amd/smu: Fix User mode stable P-states SMU15
drm/amd/swsmu: Move IP specific functions
Raag Jadav (1):
drm/xe/bo: Redirect faults to dummy page for wedged device
Ray Wu (3):
drm/amd/display: Fix IGT link training failure on Replay panel
drm/amd/display: Fix IGT ILR link training failure on Replay panel
drm/amd/display: Parse all extension blocks for VSDB
Roman Li (1):
drm/amd/display: Make GPIO HPD path conditional
Saidireddy Yenugu (1):
drm/amd/display: Skip eDP detection when no sink
Samson Tam (1):
drm/amd/display: Add static keyword for sharpness tables
Shuicheng Lin (2):
drm/xe/mmio: Avoid double-adjust in 64-bit reads
drm/xe: Make xe_modparam.force_vram_bar_size signed
Siwei He (1):
drm/amdkfd: Fix APU to use GTT, not VRAM for MQD
Srinivasan Shanmugam (4):
drm/amd/display: Fix dc_link NULL handling in HPD init
drm/amdgpu: Fix missing unwind in amdgpu_ib_schedule() error path
drm/amdkfd: Fix watch_id bounds checking in debug address watch v2
drm/amd/display: Fix out-of-bounds stream encoder index v3
Stanley.Yang (2):
drm/amdgpu: statistic xgmi training error count
drm/amd/ras: statistic xgmi training error count
Sunday Clement (1):
drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set()
Sunil Khatri (1):
drm/amdgpu: clean up the amdgpu_cs_parser_bos
Taimur Hassan (4):
drm/amd/display: [FW Promotion] Release 0.1.45.0
drm/amd/display: Promote DC to 3.2.368
drm/amd/display: [FW Promotion] Release 0.1.46.0
drm/amd/display: Promote DC to 3.2.369
Timur Kristóf (10):
drm/amd/display: Reject cursor plane on DCE when scaled
differently than primary
drm/amd/display: Use DCE 6 link encoder for DCE 6 analog connectors
drm/amd/display: Only use analog link encoder with analog engine
drm/amd/display: Only use analog stream encoder with analog engine
drm/amd/display: Don't call find_analog_engine() twice
drm/amd/display: Turn off DAC in DCE link encoder using VBIOS
drm/amd/display: Initialize DAC in DCE link encoder using VBIOS
drm/amd/display: Set CRTC source for DAC using registers
drm/amd/display: Enable DAC in DCE link encoder
drm/amd/display: Remove unneeded DAC link encoder register
Tom Chung (1):
drm/amd/display: Fix system resume lag issue
Victor Zhao (1):
drm/amdgpu: avoid sdma ring reset in sriov
Vitaly Prosyak (1):
drm/amd/display: guard NULL manual-trigger callback in cursor programming
Wayne Lin (1):
drm/amd/display: Avoid updating surface with the same surface under MPO
Wenjing Liu (1):
drm/amd/display: Fix a NULL pointer dereference in dcn20_hwseq.c
Yang Wang (1):
drm/amd/pm: use sysfs_streq for string matching in amdgpu_pm
YiLing Chen (1):
drm/amd/display: set enable_legacy_fast_update to false for DCN36
Yifan Zhang (1):
drm/amdgpu: Protect GPU register accesses in powergated state in
some paths
Zheng Austin (1):
drm/amd/display: Match expected data types
Zilin Guan (3):
drm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc()
drm/amdgpu: Use kvfree instead of kfree in amdgpu_gmc_get_nps_memranges()
drm/amdgpu: Fix memory leak in amdgpu_ras_init()
decce6 (2):
drm/radeon: Add HAINAN clock adjustment
drm/amdgpu: Add HAINAN clock adjustment
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 37 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 9 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 22 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 12 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 9 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 7 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 31 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.h | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 4 -
drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 3 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 8 +-
drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/mmhub_v4_2_0.c | 5 +-
drivers/gpu/drm/amd/amdgpu/psp_v13_0.c | 15 +-
drivers/gpu/drm/amd/amdgpu/psp_v15_0.c | 4 +
drivers/gpu/drm/amd/amdgpu/psp_v15_0_8.c | 21 +++
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 15 +-
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 22 +--
drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 15 +-
drivers/gpu/drm/amd/amdgpu/soc15.c | 3 +-
drivers/gpu/drm/amd/amdgpu/soc21.c | 24 ++-
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 8 +-
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_debug.c | 44 +++--
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 6 +
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v12.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v12_1.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 5 +-
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 3 -
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 71 +++++---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 15 +-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 70 +++++++-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 12 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 9 +-
.../amd/display/amdgpu_dm/amdgpu_dm_irq_params.h | 1 +
.../drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 7 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 8 +
drivers/gpu/drm/amd/display/dc/Makefile | 2 +-
.../gpu/drm/amd/display/dc/bios/command_table.c | 3 +-
.../amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c | 18 +-
.../amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.h | 6 +
drivers/gpu/drm/amd/display/dc/core/dc.c | 29 ++-
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4 +-
drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 18 +-
drivers/gpu/drm/amd/display/dc/dc.h | 4 +-
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 15 +-
drivers/gpu/drm/amd/display/dc/dc_stream.h | 12 +-
drivers/gpu/drm/amd/display/dc/dc_types.h | 27 ++-
.../gpu/drm/amd/display/dc/dccg/dcn20/dcn20_dccg.c | 54 +++++-
.../gpu/drm/amd/display/dc/dccg/dcn20/dcn20_dccg.h | 14 +-
.../drm/amd/display/dc/dccg/dcn201/dcn201_dccg.c | 7 +-
.../gpu/drm/amd/display/dc/dccg/dcn21/dcn21_dccg.c | 6 +-
.../gpu/drm/amd/display/dc/dccg/dcn30/dcn30_dccg.c | 6 +-
.../drm/amd/display/dc/dccg/dcn301/dcn301_dccg.c | 6 +-
.../gpu/drm/amd/display/dc/dccg/dcn31/dcn31_dccg.c | 5 +
.../drm/amd/display/dc/dccg/dcn314/dcn314_dccg.c | 7 +-
.../gpu/drm/amd/display/dc/dccg/dcn32/dcn32_dccg.c | 5 +
.../gpu/drm/amd/display/dc/dccg/dcn35/dcn35_dccg.c | 41 +++--
.../gpu/drm/amd/display/dc/dccg/dcn35/dcn35_dccg.h | 17 ++
.../drm/amd/display/dc/dccg/dcn401/dcn401_dccg.c | 17 +-
.../gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 58 ++++--
.../gpu/drm/amd/display/dc/dce/dce_link_encoder.h | 8 +-
.../drm/amd/display/dc/dce/dce_stream_encoder.c | 23 ++-
.../drm/amd/display/dc/dce/dce_stream_encoder.h | 12 +-
.../gpu/drm/amd/display/dc/dcn30/dcn30_cm_common.c | 37 +++-
drivers/gpu/drm/amd/display/dc/dio/Makefile | 11 +-
.../gpu/drm/amd/display/dc/dio/dcn10/dcn10_dio.c | 47 +++++
.../gpu/drm/amd/display/dc/dio/dcn10/dcn10_dio.h | 42 +++++
.../dc/{ => dio}/virtual/virtual_link_encoder.c | 2 -
.../dc/{ => dio}/virtual/virtual_link_encoder.h | 0
.../dc/{ => dio}/virtual/virtual_stream_encoder.c | 1 -
.../dc/{ => dio}/virtual/virtual_stream_encoder.h | 0
drivers/gpu/drm/amd/display/dc/dm_helpers.h | 2 +-
.../gpu/drm/amd/display/dc/dml/dcn35/dcn35_fpu.c | 4 +-
.../drm/amd/display/dc/dml2_0/display_mode_util.c | 2 +-
.../dml2_0/dml21/inc/dml_top_soc_parameter_types.h | 3 +
.../dml21/src/dml2_core/dml2_core_dcn4_calcs.c | 26 ++-
.../dc/dml2_0/dml21/src/dml2_dpmm/dml2_dpmm_dcn4.c | 59 +++---
.../dml21/src/inc/dml2_internal_shared_types.h | 1 +
.../gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c | 21 ++-
.../gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.h | 4 +
.../gpu/drm/amd/display/dc/dpp/dcn401/dcn401_dpp.c | 6 +-
drivers/gpu/drm/amd/display/dc/dsc/dsc.h | 1 +
.../drm/amd/display/dc/dwb/dcn30/dcn30_cm_common.h | 2 +-
.../amd/display/dc/hubbub/dcn401/dcn401_hubbub.c | 10 +-
.../amd/display/dc/hubbub/dcn401/dcn401_hubbub.h | 10 ++
.../drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 59 ++----
.../drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c | 9 +-
.../drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 30 +---
.../drm/amd/display/dc/hwss/dcn201/dcn201_hwseq.c | 10 +-
.../drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c | 9 +-
.../drm/amd/display/dc/hwss/dcn30/dcn30_hwseq.c | 18 +-
.../drm/amd/display/dc/hwss/dcn31/dcn31_hwseq.c | 15 +-
.../drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c | 31 ++--
.../drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c | 13 +-
.../drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 25 +--
drivers/gpu/drm/amd/display/dc/hwss/hw_sequencer.h | 2 +
drivers/gpu/drm/amd/display/dc/inc/core_types.h | 2 +
drivers/gpu/drm/amd/display/dc/inc/hw/dccg.h | 4 +
drivers/gpu/drm/amd/display/dc/inc/hw/dio.h | 22 +++
.../gpu/drm/amd/display/dc/inc/hw/link_encoder.h | 2 +
.../drm/amd/display/dc/inc/hw/timing_generator.h | 7 +
drivers/gpu/drm/amd/display/dc/link/Makefile | 3 +-
.../hwss/link_hwss_virtual.c} | 2 +-
.../hwss/link_hwss_virtual.h} | 6 +-
.../gpu/drm/amd/display/dc/link/link_detection.c | 2 +-
drivers/gpu/drm/amd/display/dc/link/link_dpms.c | 14 +-
drivers/gpu/drm/amd/display/dc/link/link_factory.c | 9 +-
.../dc/link/protocols/link_dp_panel_replay.c | 62 +++++++
.../drm/amd/display/dc/link/protocols/link_hpd.c | 9 +-
.../gpu/drm/amd/display/dc/mpc/dcn32/dcn32_mpc.c | 3 +-
.../gpu/drm/amd/display/dc/optc/dcn10/dcn10_optc.h | 19 +-
.../gpu/drm/amd/display/dc/optc/dcn35/dcn35_optc.c | 102 ++++++++++-
.../gpu/drm/amd/display/dc/optc/dcn35/dcn35_optc.h | 19 ++
.../display/dc/resource/dce100/dce100_resource.c | 18 +-
.../display/dc/resource/dce120/dce120_resource.c | 2 +-
.../amd/display/dc/resource/dce60/dce60_resource.c | 14 +-
.../amd/display/dc/resource/dce80/dce80_resource.c | 11 +-
.../amd/display/dc/resource/dcn10/dcn10_resource.c | 2 +-
.../amd/display/dc/resource/dcn20/dcn20_resource.c | 2 +-
.../display/dc/resource/dcn201/dcn201_resource.c | 2 +-
.../amd/display/dc/resource/dcn21/dcn21_resource.c | 2 +-
.../amd/display/dc/resource/dcn30/dcn30_resource.c | 2 +-
.../display/dc/resource/dcn301/dcn301_resource.c | 2 +-
.../amd/display/dc/resource/dcn31/dcn31_resource.c | 2 +-
.../display/dc/resource/dcn314/dcn314_resource.c | 2 +-
.../display/dc/resource/dcn315/dcn315_resource.c | 10 +-
.../display/dc/resource/dcn316/dcn316_resource.c | 10 +-
.../amd/display/dc/resource/dcn32/dcn32_resource.c | 10 +-
.../display/dc/resource/dcn321/dcn321_resource.c | 10 +-
.../amd/display/dc/resource/dcn35/dcn35_resource.c | 10 +-
.../display/dc/resource/dcn351/dcn351_resource.c | 10 +-
.../amd/display/dc/resource/dcn36/dcn36_resource.c | 16 +-
.../display/dc/resource/dcn401/dcn401_resource.c | 48 ++++-
.../amd/display/dc/sspl/dc_spl_isharp_filters.c | 4 +-
drivers/gpu/drm/amd/display/dc/virtual/Makefile | 30 ----
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 25 +++
drivers/gpu/drm/amd/include/kgd_pp_interface.h | 5 +
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 29 ++-
drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 5 +
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 26 ++-
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 30 +++-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v15_0.h | 2 -
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 22 +--
.../drm/amd/pm/swsmu/smu11/cyan_skillfish_ppt.c | 24 +--
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 27 +--
.../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 27 +--
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 2 +-
drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 29 +--
drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c | 4 +-
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 26 +--
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 2 +-
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 46 ++---
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_12_ppt.c | 23 ++-
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 34 ++--
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c | 29 +--
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 56 +++---
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.h | 8 +-
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 68 +++++--
.../gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c | 29 +--
drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0.c | 2 +-
.../gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_0_ppt.c | 33 ++--
.../gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c | 19 +-
drivers/gpu/drm/amd/pm/swsmu/smu15/smu_v15_0.c | 10 +-
.../gpu/drm/amd/pm/swsmu/smu15/smu_v15_0_0_ppt.c | 198 ++++++++++++++++-----
drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 76 ++++----
drivers/gpu/drm/amd/pm/swsmu/smu_cmn.h | 2 +-
drivers/gpu/drm/amd/ras/rascore/ras_aca_v1_0.c | 2 +-
drivers/gpu/drm/drm_gpusvm.c | 2 +-
drivers/gpu/drm/drm_pagemap.c | 2 +-
drivers/gpu/drm/i915/display/intel_acpi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 23 ++-
drivers/gpu/drm/i915/display/intel_quirks.c | 2 +-
drivers/gpu/drm/radeon/si_dpm.c | 5 +
drivers/gpu/drm/xe/xe_bo.c | 2 +-
drivers/gpu/drm/xe/xe_configfs.h | 12 +-
drivers/gpu/drm/xe/xe_gt_ccs_mode.c | 2 +-
drivers/gpu/drm/xe/xe_hwmon.c | 6 +-
drivers/gpu/drm/xe/xe_mmio.c | 10 +-
drivers/gpu/drm/xe/xe_module.h | 2 +-
drivers/gpu/drm/xe/xe_pci.c | 6 +
drivers/gpu/drm/xe/xe_sriov_pf_sysfs.c | 54 +++---
drivers/gpu/drm/xe/xe_svm.c | 8 +-
drivers/gpu/drm/xe/xe_vm_madvise.c | 7 +-
drivers/gpu/drm/xe/xe_wa.c | 18 +-
include/drm/drm_pagemap.h | 2 +-
include/uapi/drm/amdgpu_drm.h | 1 +
205 files changed, 2183 insertions(+), 990 deletions(-)
create mode 100644 drivers/gpu/drm/amd/display/dc/dio/dcn10/dcn10_dio.c
create mode 100644 drivers/gpu/drm/amd/display/dc/dio/dcn10/dcn10_dio.h
rename drivers/gpu/drm/amd/display/dc/{ =>
dio}/virtual/virtual_link_encoder.c (99%)
rename drivers/gpu/drm/amd/display/dc/{ =>
dio}/virtual/virtual_link_encoder.h (100%)
rename drivers/gpu/drm/amd/display/dc/{ =>
dio}/virtual/virtual_stream_encoder.c (99%)
rename drivers/gpu/drm/amd/display/dc/{ =>
dio}/virtual/virtual_stream_encoder.h (100%)
create mode 100644 drivers/gpu/drm/amd/display/dc/inc/hw/dio.h
rename drivers/gpu/drm/amd/display/dc/{virtual/virtual_link_hwss.c =>
link/hwss/link_hwss_virtual.c} (98%)
rename drivers/gpu/drm/amd/display/dc/{virtual/virtual_link_hwss.h =>
link/hwss/link_hwss_virtual.h} (92%)
delete mode 100644 drivers/gpu/drm/amd/display/dc/virtual/Makefile
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [git pull] drm fixes for 7.0-rc1
2026-02-20 20:53 [git pull] drm fixes for 7.0-rc1 Dave Airlie
@ 2026-02-21 1:20 ` pr-tracker-bot
2026-02-23 12:52 ` Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1) Thorsten Leemhuis
1 sibling, 0 replies; 8+ messages in thread
From: pr-tracker-bot @ 2026-02-21 1:20 UTC (permalink / raw)
To: Dave Airlie; +Cc: Linus Torvalds, Simona Vetter, dri-devel, LKML
The pull request you sent on Sat, 21 Feb 2026 06:53:39 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2026-02-21
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d4a292c5f8e65d2784b703c67179f4f7d0c7846c
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1)
2026-02-20 20:53 [git pull] drm fixes for 7.0-rc1 Dave Airlie
2026-02-21 1:20 ` pr-tracker-bot
@ 2026-02-23 12:52 ` Thorsten Leemhuis
2026-02-24 6:50 ` Dave Airlie
1 sibling, 1 reply; 8+ messages in thread
From: Thorsten Leemhuis @ 2026-02-23 12:52 UTC (permalink / raw)
To: Dave Airlie, Linus Torvalds, Simona Vetter
Cc: dri-devel, LKML, Alex Deucher, Linux kernel regressions list
Lo!
On 2/20/26 21:53, Dave Airlie wrote:
>
> This is the fixes and cleanups for the end of the merge window, it's
> nearly all amdgpu, with some amdkfd, then a pagemap core fix, i915/xe
> display fixes, and some xe driver fixes. Nothing seems out of the
> ordinary, except amdgpu is a little more volume than usual.
>
> Let me know if there are any issues,
Well, there were two fixes in here that made me wonder if our processes
need some optimization to get regressions fixed at least somewhat as
fast as Linus wants them to be fixed[1]:
* One fix in here was for a amdgpu regression introduced in v6.19-rc6
(and also affecting many stable series due to backports). The fix was
ready within ~2 days and could even have made v6.19 -- but it only
reached mainline through this PR on Friday. IOW: After two weeks. Which
got me wondering, "Should we do something to merge fixes like that
faster"? And yes, it's the merge window – but that's also when Arch
Linux and openSUSE Tumbleweed usually jump to the latest mainline series
and thus expose regressions like this to many users, so I guess it would
be good to get them fixed at least as fast as outside of merge windows.
* One fix in here was for a i915/xe regression introduced in v6.18-rc1.
Once reported, it took about six weeks to get fixed – and then nearly 10
days for the fix to reach mainline. Looking at this, I once more
wondered if this could have been merged faster. But even more I wondered
why the culprit wasn't reverted, as that's what Linus afaics wants when
it takes this long.
Note, these are examples of problems that happen in other subsystems as
well; I chose to bring it up here just because they were good examples,
as both regressions were also reported at least three times, so those
are not really corner cases. See below for all the details.
[1] "But if it's a regression with a known commit that caused it, I
think the rule of thumb [to fix it] should generally be "within a week",
preferably before the next rc."
https://lore.kernel.org/all/CAHk-%3Dwi86AosXs66-yi54%2BmpQjPu0upxB8ZAfG%2BLsMyJmcuMSA@mail.gmail.com/
> Mario Limonciello (2):
> [...]
> drm/amd: Fix hang on amdgpu unload by using pci_dev_is_disconnected()
This is f7afda7fcd169a ("drm/amd: Fix hang on amdgpu unload by using
pci_dev_is_disconnected()") [authored: 2026-02-05 17:42:54 GMT+1;
committed: 2026-02-05 23:25:57 GMT+1 by Alex; next arrival:
next-20260209; merged: 2026-02-21 00:36:38 GMT+1; v6.19-post].
It fixes a regression that has been reported at least three times:
* On Tue, 3 Feb 2026 17:27:00 -0500 (EST):
https://lore.kernel.org/all/b0c22deb-c0fa-3343-33cf-fd9a77d7db99@absolutedigital.net/
* On February 5, 2026 at 1:30:12 PM GMT+1:
https://gitlab.freedesktop.org/drm/amd/-/issues/4944
* February 18, 2026 at 9:30:39 PM GMT+1:
https://gitlab.freedesktop.org/drm/amd/-/issues/4984
And likely a fourth time on February 7, 2026 at 7:25:40 PM GMT+1:
https://gitlab.freedesktop.org/drm/amd/-/issues/4953
The culprit is 28695ca09d3264 ("drm/amd: Clean up kfd node on surprise
disconnect") [also known as 6a23e7b4332c10; authored: 2026-01-07
22:37:28; committed: 2026-01-14 20:51:36; next arrival: next-20260119;
merged: 2026-01-16 22:48:18; v6.19-rc6 (2026-01-19 00:42:45), v6.18.7
(2026-01-23 11:21:37), v6.12.67 (2026-01-23 11:18:52), v6.6.122
(2026-01-30 10:27:43)]
Mario and Alex thus had a fix ready and committed within about two days
after it was first reported. It thus is an "immediate fix" (yeah!), just
how Linus wants it (see [1] above).
But then it took two weeks to get it mainlined -- and will now take a
few days more to reach all those stable trees where it is needed, too.
Give the dates above it could have reached 6.19 (released 2026-02-08
22:03:27 GMT+1) if we really had wanted to.
That fix could also have made the main drm PR this merge window (send
Wed, 11 Feb 2026 17:26:03 +1000:), as Alex already asked for merging on
Fri, 6 Feb 2026 14:27:06 -0500:
https://lore.kernel.org/all/CAPM=9tzgmO1PWeuxjAxqOmS5PTsOe8jHP9Poy23q6tvY66B1KQ@mail.gmail.com/
https://lore.kernel.org/all/20260206192706.59396-1-alexander.deucher@amd.com/
If it made that pull, the fix could be in stable already by now. Maybe
Alex PR just fell through the cracks. Happens, but overall this still
made me wonder:
(1) Should there maybe have been an additional PR this merge window to
speed things up? Or some fast track for regressions?
(2) Or should the fix (or a revert of the culprit) maybe even have been
sent to Linus for 6.19? That would have saved at least one user from
bisecting and reporting the regression (and likely a few others that
never reported it).
From Linus' mail I linked above, I'd assume he would have preferred the
second option here, even if it would have been a last minute fix. If so:
how could we make that happen more often in the future?
Side note: yes, unbinding a module is likely something only a few users
do -- but given those three or four reports, it seems it's not that
unusual. And I don't care too much about this specific fix anyway, as
it's just an example for the "time it takes fixes for recent regressions
to reach mainline" aspect that I see all the time in many subsystems. To
elaborate on that, let me give another example:
> Imre Deak (2):
> drm/i915/dp: Fix pipe BPP clamping due to HDR
This is now fe26ae6ac8b88f ("drm/i915/dp: Fix pipe BPP clamping due to
HDR") [authored: 2026-02-09 14:38:16 GMT+1; committed: 2026-02-12
07:03:08 GMT+1; next arrival: next-20260212; merged: 2026-02-21 00:36:38
GMT+1; v6.19-post].
That commit fixes a regressions that has been reported at least three times:
* On December 30, 2025 at 5:07:48 PM GMT+1
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15503
* On January 13, 2026 at 11:51:11 PM GMT+1
https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7052
* On February 15, 2026 at 10:13:48 PM GMT+1
https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7269
That regression is caused by ba49a4643cf53c ("drm/i915/dp: Set min_bpp
limit to 30 in HDR mode") [authored: 2025-07-30 07:55:23 GMT+;
committed: 2025-08-19 08:32:40 GMT+; next arrival: next-20250820;
merged: 2025-10-02 21:47:25 GMT+; v6.18-rc1 (2025-10-12 22:42:36 GMT+)].
The regression took way longer to get resolved than the first example,
which makes me wonder:
(1) Should the culprit have been reverted weeks ago to get closer to the
"immediate fix" target that Linus wants?
(2) This fix also took nine days from being committed to reaching
mainline. It came a bit too late for the first drm PR this cycle. So
again: Would more frequent PRs help here? Or some fast-track path for
regression fixes?
Ciao, Thorsten
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1)
2026-02-23 12:52 ` Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1) Thorsten Leemhuis
@ 2026-02-24 6:50 ` Dave Airlie
2026-02-24 7:05 ` Dave Airlie
0 siblings, 1 reply; 8+ messages in thread
From: Dave Airlie @ 2026-02-24 6:50 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Linus Torvalds, Simona Vetter, dri-devel, LKML, Alex Deucher,
Linux kernel regressions list, Rodrigo Vivi,
Ville Syrjälä,
Jani Nikula, Imre Deak
On Mon, 23 Feb 2026 at 22:52, Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> Lo!
>
> On 2/20/26 21:53, Dave Airlie wrote:
> >
> > This is the fixes and cleanups for the end of the merge window, it's
> > nearly all amdgpu, with some amdkfd, then a pagemap core fix, i915/xe
> > display fixes, and some xe driver fixes. Nothing seems out of the
> > ordinary, except amdgpu is a little more volume than usual.
> >
> > Let me know if there are any issues,
>
> Well, there were two fixes in here that made me wonder if our processes
> need some optimization to get regressions fixed at least somewhat as
> fast as Linus wants them to be fixed[1]:
>
> * One fix in here was for a amdgpu regression introduced in v6.19-rc6
> (and also affecting many stable series due to backports). The fix was
> ready within ~2 days and could even have made v6.19 -- but it only
> reached mainline through this PR on Friday. IOW: After two weeks. Which
> got me wondering, "Should we do something to merge fixes like that
> faster"? And yes, it's the merge window – but that's also when Arch
> Linux and openSUSE Tumbleweed usually jump to the latest mainline series
> and thus expose regressions like this to many users, so I guess it would
> be good to get them fixed at least as fast as outside of merge windows.
>
> * One fix in here was for a i915/xe regression introduced in v6.18-rc1.
> Once reported, it took about six weeks to get fixed – and then nearly 10
> days for the fix to reach mainline. Looking at this, I once more
> wondered if this could have been merged faster. But even more I wondered
> why the culprit wasn't reverted, as that's what Linus afaics wants when
> it takes this long.
>
> Note, these are examples of problems that happen in other subsystems as
> well; I chose to bring it up here just because they were good examples,
> as both regressions were also reported at least three times, so those
> are not really corner cases. See below for all the details.
>
> [1] "But if it's a regression with a known commit that caused it, I
> think the rule of thumb [to fix it] should generally be "within a week",
> preferably before the next rc."
> https://lore.kernel.org/all/CAHk-%3Dwi86AosXs66-yi54%2BmpQjPu0upxB8ZAfG%2BLsMyJmcuMSA@mail.gmail.com/
>
>
> > Mario Limonciello (2):
> > [...]
> > drm/amd: Fix hang on amdgpu unload by using pci_dev_is_disconnected()
>
> This is f7afda7fcd169a ("drm/amd: Fix hang on amdgpu unload by using
> pci_dev_is_disconnected()") [authored: 2026-02-05 17:42:54 GMT+1;
> committed: 2026-02-05 23:25:57 GMT+1 by Alex; next arrival:
> next-20260209; merged: 2026-02-21 00:36:38 GMT+1; v6.19-post].
>
> It fixes a regression that has been reported at least three times:
>
> * On Tue, 3 Feb 2026 17:27:00 -0500 (EST):
> https://lore.kernel.org/all/b0c22deb-c0fa-3343-33cf-fd9a77d7db99@absolutedigital.net/
>
> * On February 5, 2026 at 1:30:12 PM GMT+1:
> https://gitlab.freedesktop.org/drm/amd/-/issues/4944
>
> * February 18, 2026 at 9:30:39 PM GMT+1:
> https://gitlab.freedesktop.org/drm/amd/-/issues/4984
>
> And likely a fourth time on February 7, 2026 at 7:25:40 PM GMT+1:
> https://gitlab.freedesktop.org/drm/amd/-/issues/4953
>
> The culprit is 28695ca09d3264 ("drm/amd: Clean up kfd node on surprise
> disconnect") [also known as 6a23e7b4332c10; authored: 2026-01-07
> 22:37:28; committed: 2026-01-14 20:51:36; next arrival: next-20260119;
> merged: 2026-01-16 22:48:18; v6.19-rc6 (2026-01-19 00:42:45), v6.18.7
> (2026-01-23 11:21:37), v6.12.67 (2026-01-23 11:18:52), v6.6.122
> (2026-01-30 10:27:43)]
>
> Mario and Alex thus had a fix ready and committed within about two days
> after it was first reported. It thus is an "immediate fix" (yeah!), just
> how Linus wants it (see [1] above).
>
> But then it took two weeks to get it mainlined -- and will now take a
> few days more to reach all those stable trees where it is needed, too.
>
> Give the dates above it could have reached 6.19 (released 2026-02-08
> 22:03:27 GMT+1) if we really had wanted to.
>
> That fix could also have made the main drm PR this merge window (send
> Wed, 11 Feb 2026 17:26:03 +1000:), as Alex already asked for merging on
> Fri, 6 Feb 2026 14:27:06 -0500:
> https://lore.kernel.org/all/CAPM=9tzgmO1PWeuxjAxqOmS5PTsOe8jHP9Poy23q6tvY66B1KQ@mail.gmail.com/
> https://lore.kernel.org/all/20260206192706.59396-1-alexander.deucher@amd.com/
>
> If it made that pull, the fix could be in stable already by now. Maybe
> Alex PR just fell through the cracks. Happens, but overall this still
> made me wonder:
>
> (1) Should there maybe have been an additional PR this merge window to
> speed things up? Or some fast track for regressions?
>
> (2) Or should the fix (or a revert of the culprit) maybe even have been
> sent to Linus for 6.19? That would have saved at least one user from
> bisecting and reporting the regression (and likely a few others that
> never reported it).
>
> From Linus' mail I linked above, I'd assume he would have preferred the
> second option here, even if it would have been a last minute fix. If so:
> how could we make that happen more often in the future?
>
> Side note: yes, unbinding a module is likely something only a few users
> do -- but given those three or four reports, it seems it's not that
> unusual. And I don't care too much about this specific fix anyway, as
> it's just an example for the "time it takes fixes for recent regressions
> to reach mainline" aspect that I see all the time in many subsystems. To
> elaborate on that, let me give another example:
>
> > Imre Deak (2):
> > drm/i915/dp: Fix pipe BPP clamping due to HDR
>
> This is now fe26ae6ac8b88f ("drm/i915/dp: Fix pipe BPP clamping due to
> HDR") [authored: 2026-02-09 14:38:16 GMT+1; committed: 2026-02-12
> 07:03:08 GMT+1; next arrival: next-20260212; merged: 2026-02-21 00:36:38
> GMT+1; v6.19-post].
>
> That commit fixes a regressions that has been reported at least three times:
>
> * On December 30, 2025 at 5:07:48 PM GMT+1
> https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15503
>
> * On January 13, 2026 at 11:51:11 PM GMT+1
> https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7052
>
> * On February 15, 2026 at 10:13:48 PM GMT+1
> https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7269
>
> That regression is caused by ba49a4643cf53c ("drm/i915/dp: Set min_bpp
> limit to 30 in HDR mode") [authored: 2025-07-30 07:55:23 GMT+;
> committed: 2025-08-19 08:32:40 GMT+; next arrival: next-20250820;
> merged: 2025-10-02 21:47:25 GMT+; v6.18-rc1 (2025-10-12 22:42:36 GMT+)].
>
> The regression took way longer to get resolved than the first example,
> which makes me wonder:
>
> (1) Should the culprit have been reverted weeks ago to get closer to the
> "immediate fix" target that Linus wants?
>
> (2) This fix also took nine days from being committed to reaching
> mainline. It came a bit too late for the first drm PR this cycle. So
> again: Would more frequent PRs help here? Or some fast-track path for
> regression fixes?
>
> Ciao, Thorsten
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1)
2026-02-24 6:50 ` Dave Airlie
@ 2026-02-24 7:05 ` Dave Airlie
2026-02-24 10:30 ` Jani Nikula
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Dave Airlie @ 2026-02-24 7:05 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Linus Torvalds, Simona Vetter, dri-devel, LKML, Alex Deucher,
Linux kernel regressions list, Rodrigo Vivi,
Ville Syrjälä,
Jani Nikula, Imre Deak
On Tue, 24 Feb 2026 at 16:50, Dave Airlie <airlied@gmail.com> wrote:
>
> On Mon, 23 Feb 2026 at 22:52, Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
> >
> > Lo!
> >
> > On 2/20/26 21:53, Dave Airlie wrote:
> > >
> > > This is the fixes and cleanups for the end of the merge window, it's
> > > nearly all amdgpu, with some amdkfd, then a pagemap core fix, i915/xe
> > > display fixes, and some xe driver fixes. Nothing seems out of the
> > > ordinary, except amdgpu is a little more volume than usual.
> > >
> > > Let me know if there are any issues,
> >
> > Well, there were two fixes in here that made me wonder if our processes
> > need some optimization to get regressions fixed at least somewhat as
> > fast as Linus wants them to be fixed[1]:
> >
> > * One fix in here was for a amdgpu regression introduced in v6.19-rc6
> > (and also affecting many stable series due to backports). The fix was
> > ready within ~2 days and could even have made v6.19 -- but it only
> > reached mainline through this PR on Friday. IOW: After two weeks. Which
> > got me wondering, "Should we do something to merge fixes like that
> > faster"? And yes, it's the merge window – but that's also when Arch
> > Linux and openSUSE Tumbleweed usually jump to the latest mainline series
> > and thus expose regressions like this to many users, so I guess it would
> > be good to get them fixed at least as fast as outside of merge windows.
I think due to the patch pipeline depth and volume that amdgpu and
i915/xe are dealing with we may need to consider some better
regression revert pipelines,
The problem is most patches get fed into the start of their -next
pipelines, where CI etc picks up on them, but there isn't enough
urgency to create separate trees or pulls outside the regular fixes
ones.
The amdgpu one definitely should have been fixed in 6.19, Alex any
idea how we can alleviate that sort of problem, esp if a bug has
multiple regression reports.
> >
> > * One fix in here was for a i915/xe regression introduced in v6.18-rc1.
> > Once reported, it took about six weeks to get fixed – and then nearly 10
> > days for the fix to reach mainline. Looking at this, I once more
> > wondered if this could have been merged faster. But even more I wondered
> > why the culprit wasn't reverted, as that's what Linus afaics wants when
> > it takes this long.
I think for the i915 one the problem patch should have been reverted
asap, but I just don't think there was a responsible person to do it,
maintainers need to be in the loop for these sort of problems, but if
they aren't in the loop and the regression sits in the bug tracker
without them being looped on it, we rely on the reporter or developer
to find it and do the right thing. Esp when developers are head down
on fixing it, but then it doesn't get flagged as urgent once it goes
into the -next pipeline and so on. We don't usually break the weekly
fixes cycles for drm, because CI backlogs and other things it just
fits nicely, if we do have regressions like this it might be that we
need to start having urgent PRs out of cycle, which I don't object to,
it's just a matter of whether maintainers can have this sort of
insight into patches in the pipeline when there is quite a long
backlog.
Thanks for the detailed analysis, I've cc'ed some more Intel people.
Dave.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1)
2026-02-24 7:05 ` Dave Airlie
@ 2026-02-24 10:30 ` Jani Nikula
2026-02-24 10:38 ` Thorsten Leemhuis
2026-02-24 14:13 ` Alex Deucher
2 siblings, 0 replies; 8+ messages in thread
From: Jani Nikula @ 2026-02-24 10:30 UTC (permalink / raw)
To: Dave Airlie, Thorsten Leemhuis
Cc: Linus Torvalds, Simona Vetter, dri-devel, LKML, Alex Deucher,
Linux kernel regressions list, Rodrigo Vivi,
Ville Syrjälä,
Imre Deak
On Tue, 24 Feb 2026, Dave Airlie <airlied@gmail.com> wrote:
> On Tue, 24 Feb 2026 at 16:50, Dave Airlie <airlied@gmail.com> wrote:
>>
>> On Mon, 23 Feb 2026 at 22:52, Thorsten Leemhuis
>> <regressions@leemhuis.info> wrote:
>> > * One fix in here was for a i915/xe regression introduced in v6.18-rc1.
>> > Once reported, it took about six weeks to get fixed – and then nearly 10
>> > days for the fix to reach mainline. Looking at this, I once more
>> > wondered if this could have been merged faster. But even more I wondered
>> > why the culprit wasn't reverted, as that's what Linus afaics wants when
>> > it takes this long.
>
> I think for the i915 one the problem patch should have been reverted
> asap, but I just don't think there was a responsible person to do it,
> maintainers need to be in the loop for these sort of problems, but if
> they aren't in the loop and the regression sits in the bug tracker
> without them being looped on it, we rely on the reporter or developer
> to find it and do the right thing. Esp when developers are head down
> on fixing it, but then it doesn't get flagged as urgent once it goes
> into the -next pipeline and so on. We don't usually break the weekly
> fixes cycles for drm, because CI backlogs and other things it just
> fits nicely, if we do have regressions like this it might be that we
> need to start having urgent PRs out of cycle, which I don't object to,
> it's just a matter of whether maintainers can have this sort of
> insight into patches in the pipeline when there is quite a long
> backlog.
I think it's pretty natural for developers to err on the side of trying
to fix things instead of reverting, and the responsibility to make the
call to revert usually lands on maintainers.
I'll remind people about considering reverts earlier if the fix isn't
obvious, and looping in maintainers when in doubt.
As to the 10 days from fix to mainline, it's down to unfortunate
timing. The fix landed right after the v6.19 release during the merge
window. It was part of the drm pull request for v7.0-rc1. There's no
faster path at that time.
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1)
2026-02-24 7:05 ` Dave Airlie
2026-02-24 10:30 ` Jani Nikula
@ 2026-02-24 10:38 ` Thorsten Leemhuis
2026-02-24 14:13 ` Alex Deucher
2 siblings, 0 replies; 8+ messages in thread
From: Thorsten Leemhuis @ 2026-02-24 10:38 UTC (permalink / raw)
To: Dave Airlie
Cc: Linus Torvalds, Simona Vetter, dri-devel, LKML, Alex Deucher,
Linux kernel regressions list, Rodrigo Vivi,
Ville Syrjälä,
Jani Nikula, Imre Deak
On 2/24/26 08:05, Dave Airlie wrote:
> On Tue, 24 Feb 2026 at 16:50, Dave Airlie <airlied@gmail.com> wrote:
>> On Mon, 23 Feb 2026 at 22:52, Thorsten Leemhuis
>> <regressions@leemhuis.info> wrote:
>>> On 2/20/26 21:53, Dave Airlie wrote:
>>>
>>> * One fix in here was for a amdgpu regression introduced in v6.19-rc6
>>> (and also affecting many stable series due to backports). The fix was
>>> ready within ~2 days and could even have made v6.19 -- but it only
>>> reached mainline through this PR on Friday. IOW: After two weeks. Which
>>> got me wondering, "Should we do something to merge fixes like that
>>> faster"? And yes, it's the merge window – but that's also when Arch
>>> Linux and openSUSE Tumbleweed usually jump to the latest mainline series
>>> and thus expose regressions like this to many users, so I guess it would
>>> be good to get them fixed at least as fast as outside of merge windows.
>
> I think due to the patch pipeline depth and volume that amdgpu and
> i915/xe are dealing with we may need to consider some better
> regression revert pipelines,
Thx for your reply. And also for considering adjustments.
> The amdgpu one definitely should have been fixed in 6.19, Alex any
> idea how we can alleviate that sort of problem,
FWIW, I see situations like these in various subsystems, and I think
there are two important factors at play here:
* The more important one: Some maintainers refrain from quickly picking
up and sending fixes upwards during merge windows, as they fear getting
yelled at by higher-level maintainers or Linus if those cause problems.
And I can understand that, as Linus for good reasons has gotten quite
unhappy in the past when a big merge window PR contained late changes,
especially if those then caused things like build errors -- except when
the PR had stated explicitly that those were last-minute regression fixes.
In fact, one lower-level maintainer in the arm64 dts space just told
me in private that this was one reason why he only picked up a revert
fixing a 6.18-rc1 regression yesterday after it sat on the list for
nearly two weeks.
* Some maintainers refrain from sending regression fixes upwards right
before a new mainline release, as they fear breaking something
important. Considering that outcome, of course, is something that must
be done, but it feels to me like many are a way more careful there then
Linus would like -- and forget that they could just send the last-minute
fixes to him to make him decide, as he is in the best position to do so,
as he when needed then could even delay the release.
Not sure how to improve all of this. Maybe some announcement from Linus
along the following lines would help:
"An open merge window should not delay picking up and upstreaming
regression fixes in any way; if needed, keep your fixes branch running
as before the release and send separate PRs for them. And as usual,
don't worry about conflicts unless they are complex. Ohh, and if you
have regression fixes where you are unsure if it is worth merging them
right before a new release, send them to me and let me decide".
Ciao, Thorsten
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1)
2026-02-24 7:05 ` Dave Airlie
2026-02-24 10:30 ` Jani Nikula
2026-02-24 10:38 ` Thorsten Leemhuis
@ 2026-02-24 14:13 ` Alex Deucher
2 siblings, 0 replies; 8+ messages in thread
From: Alex Deucher @ 2026-02-24 14:13 UTC (permalink / raw)
To: Dave Airlie
Cc: Thorsten Leemhuis, Linus Torvalds, Simona Vetter, dri-devel,
LKML, Alex Deucher, Linux kernel regressions list, Rodrigo Vivi,
Ville Syrjälä,
Jani Nikula, Imre Deak
On Tue, Feb 24, 2026 at 2:24 AM Dave Airlie <airlied@gmail.com> wrote:
>
> On Tue, 24 Feb 2026 at 16:50, Dave Airlie <airlied@gmail.com> wrote:
> >
> > On Mon, 23 Feb 2026 at 22:52, Thorsten Leemhuis
> > <regressions@leemhuis.info> wrote:
> > >
> > > Lo!
> > >
> > > On 2/20/26 21:53, Dave Airlie wrote:
> > > >
> > > > This is the fixes and cleanups for the end of the merge window, it's
> > > > nearly all amdgpu, with some amdkfd, then a pagemap core fix, i915/xe
> > > > display fixes, and some xe driver fixes. Nothing seems out of the
> > > > ordinary, except amdgpu is a little more volume than usual.
> > > >
> > > > Let me know if there are any issues,
> > >
> > > Well, there were two fixes in here that made me wonder if our processes
> > > need some optimization to get regressions fixed at least somewhat as
> > > fast as Linus wants them to be fixed[1]:
> > >
> > > * One fix in here was for a amdgpu regression introduced in v6.19-rc6
> > > (and also affecting many stable series due to backports). The fix was
> > > ready within ~2 days and could even have made v6.19 -- but it only
> > > reached mainline through this PR on Friday. IOW: After two weeks. Which
> > > got me wondering, "Should we do something to merge fixes like that
> > > faster"? And yes, it's the merge window – but that's also when Arch
> > > Linux and openSUSE Tumbleweed usually jump to the latest mainline series
> > > and thus expose regressions like this to many users, so I guess it would
> > > be good to get them fixed at least as fast as outside of merge windows.
>
> I think due to the patch pipeline depth and volume that amdgpu and
> i915/xe are dealing with we may need to consider some better
> regression revert pipelines,
>
> The problem is most patches get fed into the start of their -next
> pipelines, where CI etc picks up on them, but there isn't enough
> urgency to create separate trees or pulls outside the regular fixes
> ones.
>
> The amdgpu one definitely should have been fixed in 6.19, Alex any
> idea how we can alleviate that sort of problem, esp if a bug has
> multiple regression reports.
I guess I should have done an additional -fixes PR that week.
Normally I would have been sure to include in the following weeks
-fixes PR, but this was the last one of the cycle.
Alex
>
> > >
> > > * One fix in here was for a i915/xe regression introduced in v6.18-rc1.
> > > Once reported, it took about six weeks to get fixed – and then nearly 10
> > > days for the fix to reach mainline. Looking at this, I once more
> > > wondered if this could have been merged faster. But even more I wondered
> > > why the culprit wasn't reverted, as that's what Linus afaics wants when
> > > it takes this long.
>
> I think for the i915 one the problem patch should have been reverted
> asap, but I just don't think there was a responsible person to do it,
> maintainers need to be in the loop for these sort of problems, but if
> they aren't in the loop and the regression sits in the bug tracker
> without them being looped on it, we rely on the reporter or developer
> to find it and do the right thing. Esp when developers are head down
> on fixing it, but then it doesn't get flagged as urgent once it goes
> into the -next pipeline and so on. We don't usually break the weekly
> fixes cycles for drm, because CI backlogs and other things it just
> fits nicely, if we do have regressions like this it might be that we
> need to start having urgent PRs out of cycle, which I don't object to,
> it's just a matter of whether maintainers can have this sort of
> insight into patches in the pipeline when there is quite a long
> backlog.
>
> Thanks for the detailed analysis, I've cc'ed some more Intel people.
>
> Dave.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2026-02-24 14:14 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-20 20:53 [git pull] drm fixes for 7.0-rc1 Dave Airlie
2026-02-21 1:20 ` pr-tracker-bot
2026-02-23 12:52 ` Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1) Thorsten Leemhuis
2026-02-24 6:50 ` Dave Airlie
2026-02-24 7:05 ` Dave Airlie
2026-02-24 10:30 ` Jani Nikula
2026-02-24 10:38 ` Thorsten Leemhuis
2026-02-24 14:13 ` Alex Deucher
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®