summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-07-21drm/xe/migrate: Revamp PAT index selection for migrate PTEsSanjay Yadav
Improve PAT index selection logic in xe_migrate.c to avoid unnecessary coherency overhead when host-side memory is uncached. Previously, we defaulted to XE_CACHE_WB, which enforces 2-way coherency and may trigger cacheline pulls from CPU even when host-side memory is never dirty. This change introduces xe_migrate_pat_index() to choose the appropriate PAT index based on the actual TTM caching mode of the buffer object being mapped. For iGPUs with WC host mappings, we now prefer XE_CACHE_NONE to skip coherency snoops. For compressed PTEs on newer platforms, we select XE_CACHE_NONE_COMPRESSION. This avoids unnecessary cache traffic for uncached host mappings. v6: (sashiko) - Only apply the BO's host-side caching for system-memory PTEs. v5: (Matt A) - Simplify emit_pte() to derive caching from res->bo directly, removing the separate bo parameter - Leave changes in __xe_migrate_update_pgtables() and build_pt_update_batch_sram() - Fix comment about page-walker coherency in xe_migrate_pat_index() v4: - Keep xe_migrate_prepare_vm() on XE_CACHE_WB since page tables require page-walker coherency. - Pass BO into emit_pte() and select PAT attributes from the BO's TTM caching mode. Assisted-by: Github-Copilot:claude-opus-4.8 Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Suggested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260710083004.1546599-2-sanjay.kumar.yadav@intel.com
2026-07-21drm/i915/bw: Update bw calculation to account for 16 channelsUma Shankar
Wa_16030862157: Update Bandwidth Calculation to account for 16channel memory config. v2: Logical separation of changes (Suraj, Vinod) WA: 16030862157, 16030875223 Bspec: 69131, 68859 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patch.msgid.link/20260715143243.4141208-3-uma.shankar@intel.com
2026-07-21drm/i915/dram: Interpret 0xF populated-channel count as 16Uma Shankar
Wa_16030862157: Interpret 0xF populated-channel count as 16 The register MEM_SS_INFO_GLOBAL [Number of populated channels] field definition is updated with an encoding for 16 channels. For 16-channel configuration, program 1111b. A programmed value of 1111b must be interpreted as 16 channels for memory bandwidth calculations. The MEM_SS_INFO_GLOBAL populated-channel field is only 4 bits and cannot encode 16, so on Xe3p the BIOS programs the saturated field value (0xf) to indicate the fully-populated 16-channel config (4 memory controllers x 4 channels). Interpret it as 16 and let the bandwidth math handle the larger channel count. v2: Limit the WA only till NVL (Suraj) Logical separation of WA (Vinod) WA: 16030862157, 16030875223 Bspec: 69131, 79482 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patch.msgid.link/20260715143243.4141208-2-uma.shankar@intel.com
2026-07-21drm/gpusvm: Zero HMM PFNs before scanning rangesStanislav Kinsburskii
drm_gpusvm_scan_mm() asks HMM to report the current CPU page-table state without faulting missing entries by leaving default_flags set to zero. The HMM PFN array is still caller-owned input/output state, and the framework may preserve input bits while filling entries. It is not safe for the caller to hand HMM an uninitialized array and then treat entries without HMM_PFN_VALID as an authoritative unpopulated result. Use kvcalloc() for the temporary PFN array so entries that are not reported as valid start from the documented zero state. This prevents random stack or heap contents from being interpreted as HMM PFN flags or PFN values during the scan. Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state") Cc: stable@vger.kernel.org Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/178406967042.1113483.2116704310277917086.stgit@skinsburskii
2026-07-21drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evictMatthew Brost
If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260714170025.3487974-1-matthew.brost@intel.com
2026-07-21rust: device: make lifetime on `Core` and `CoreInternal` invariantGary Guo
Currently the lifetime on `Core` and `CoreInternal` is covariant. This means that they can be coerced into shorter living lifetimes. On `probe` function, signature has `&'bound Device<Core<'a>>`; the type's wellformness would imply `'a: 'bound` and thus the type can be coerced `&'bound Device<Core<'bound>>`, defeating the purpose of having the lifetime bound to prevent users of the `Core` type to escape the function. Fix this by making the lifetime invariant, so the coercion is impossible. The lifetime here only needs to be "branded" so it does not coerce or unify with other lifetimes, so we do not need to ensure `'bound: 'a`. This requires modifying `nova-core` which relies on this implied bound due to pre-2024 capture rule. The "use" bound can be removed if built with edition 2024. Fixes: 24799831d631 ("rust: device: make Core and CoreInternal lifetime-parameterized") Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260713201455.640151-1-gary@kernel.org [ Fixup the debugfs sample to use an explicit lifetime instead of Core<'_>. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-20drm/panel: panel-edp: Adjust T8 timing for AUO B116XAK01.6 and B140XTK02.4Dio Zhang
Screen garbage or flickering can be observed during mode changes (such as VT switches) on systems using the AUO B116XAK01.6 and B140XTK02.4 panels. This occurs because the backlight is enabled before the video signal stabilizes. Waveform measurements show that the panel signal takes around 140ms to stabilize after a mode change, meaning the previous 50ms T8 timing was insufficient. To resolve this issue, adjust the eDP panel delay entry from delay_200_500_e50 to delay_200_500_e200 (increasing T8 from 50ms to 200ms). This matches the updated panel specifications from AUO, which now formally define T8 as 200ms to mask any display abnormalities during mode changes. Signed-off-by: Dio Zhang <dioyc_zhang@compal.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260720025358.2781136-1-dioyc_zhang@compal.corp-partner.google.com
2026-07-20drm/panfrost: Remove unused scheduled_jobs listMaíra Canal
The scheduled_jobs list head was introduced in commit f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") but never used. Remove the dead field and its initialization. Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://patch.msgid.link/20260710121423.2820472-2-mcanal@igalia.com Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
2026-07-20drm/xe/madvise: Skip invalidation for purgeable state updatesArvind Yadav
Purgeable state updates only change VMA/BO metadata. They do not zap PTEs when switching between DONTNEED and WILLNEED. PTEs are zapped later if the BO is actually purged. xe_vm_invalidate_madvise_range() waits on the VM dma-resv before checking vma->skip_invalidation. Since purgeable madvise marks all affected VMAs to skip invalidation, this wait is unnecessary and can stall on unrelated in-flight work. Skip the invalidate path entirely for purgeable state updates. v2: - Replace inline 'args->type != DRM_XE_VMA_ATTR_PURGEABLE_STATE' check with a small helper madvise_range_needs_invalidation(). (Himal) Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260526135447.2973029-1-arvind.yadav@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe") Cc: <stable@vger.kernel.org> # v6.18+ (cherry picked from commit 134377098b9c14abd31c3bcac00c9653f0f0c4c3) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-20drm/hyperv: Move MODULE_DEVICE_TABLE to the device_id arraysUwe Kleine-König (The Capable Hub)
It matches the usual coding style to have the MODULE_DEVICE_TABLE macro directly after the respective arrays. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/7f9d4a239c76b6bb384048ea5591a21ed87d9b0e.1782925276.git.u.kleine-koenig@baylibre.com
2026-07-20drm/hyperv: Explicitly set subvendor and subdevice for pci match arrayUwe Kleine-König (The Capable Hub)
.subvendor and .subdevice were set to 0 implicitly, so only devices with these two values set to 0 in hardware can probe automatically. Make this requirement explicit. While touching this array item, also make use of the pci macro designed for that case. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/019450ffb519d02821364afca32b9f48bcd8d2b6.1782925276.git.u.kleine-koenig@baylibre.com
2026-07-20drm/hyperv: Unregister pci driver in error path before module unloadUwe Kleine-König (The Capable Hub)
The pci driver must not kept registered if the module is unloaded after vmbus_driver_register() fails. So check the return value of vmbus_driver_register() and unregister the pci driver on failure. Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/4b7dbf00ce4ff664b7d5dd74b2f39d8d87c1ade9.1782925276.git.u.kleine-koenig@baylibre.com
2026-07-20drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VMIcenowy Zheng
The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [<ffffffff01e989d4>] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [<ffffffff01ed3a40>] pvr_vm_unmap+0x34/0x68 [powervr] [<ffffffff01ec69da>] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [<ffffffff8080ce0a>] drm_ioctl_kernel+0x8e/0xdc [<ffffffff8080d016>] drm_ioctl+0x1be/0x3e0 [<ffffffff802bec3e>] __riscv_sys_ioctl+0xba/0xc4 [<ffffffff80d858b2>] do_trap_ecall_u+0x23e/0x3f4 [<ffffffff80d92288>] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*(). Cc: stable@vger.kernel.org Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Fixes: 4bc736f890ce ("drm/imagination: vm: make use of GPUVM's drm_exec helper") Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260714073641.1935075-1-zhengxingda@iscas.ac.cn Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-20drm/imagination: Use struct_size_t()Matt Coster
The helpers for dealing with flexible structures exist, so let's use them. Signed-off-by: Matt Coster <matt.coster@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20250709-flex-array-check-v1-2-8adeb0bf0cde@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-20drm/imagination: Add and use FLEX_ARRAY_CHECK()Matt Coster
It makes little to no sense to use SIZE_CHECK() on flexible structures, so let's validate something that actually matters instead. Signed-off-by: Matt Coster <matt.coster@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20250709-flex-array-check-v1-1-8adeb0bf0cde@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-20drm/panel: sofef00: Fix DSI transfer errors on backlight updateCédric Bellegarde
Backlight updates via bl_update_status() could be triggered before the panel was fully initialized, resulting in failed DCS commands during the atomic commit sequence. Guard bl_update_status() with a prepared flag to skip backlight updates when the panel is not yet ready. [11816.846734] disp_cc_mdss_byte0_clk status stuck at 'on' [11816.846752] WARNING: CPU: 4 PID: 26399 at drivers/clk/qcom/clk-branch.c:88 clk_branch_toggle+0x128/0x178 [11816.861715] Modules linked in: rfcomm rmnet algif_hash algif_skcipher q6asm_dai q6voice_dai q6routing q6afe_dai q6voice q6adm q6cvp q6afe q6asm q6mvm q6 cvs q6voice_common snd_q6dsp_common q6core bnep gpio_wcd934x snd_soc_wcd934x snd_soc_wcd_mbhc soundwire_qcom snd_soc_wcd_classh venus_enc venus_dec imx371 wcd9 34x regmap_slimbus imx376 lc898217xc videobuf2_dma_contig fastrpc v4l2_cci qrtr_smd rpmsg_ctrl hci_uart btqca btbcm bluetooth ecdh_generic ecc pwrseq_core snd_ soc_max98927 qcom_camss ath10k_snoc videobuf2_dma_sg snd_soc_sdm845 videobuf2_memops venus_core ath10k_core qcom_smbx leds_qcom_flash snd_soc_rt5663 leds_qcom_ lpg ath v4l2_mem2mem snd_soc_qcom_sdw videobuf2_v4l2 v4l2_fwnode videobuf2_common v4l2_async snd_soc_qcom_common bq27xxx_battery_i2c qcom_pbs bq27xxx_battery l ed_class_multicolor mac80211 snd_soc_rl6231 rtc_pm8xxx libarc4 soundwire_bus videodev qcom_stats qcom_spmi_rradc reset_qcom_pdc i2c_qcom_cci cfg80211 camcc_sdm 845 rfkill mc qcom_rng ipa qcom_q6v5_mss slim_qcom_ngd_ctrl qcom_wdt icc_bwmon qrtr [11816.861812] qcom_q6v5_pas qcom_pil_info qcom_q6v5 qcom_sysmon qcom_common qcom_glink_smem joydev zram zsmalloc uhid uinput nft_reject_inet nft_reject n f_reject_ipv6 nf_reject_ipv4 nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables fuse nfnetlink ipv6 qcom_spmi_haptics rmi_i2c rmi_core [11816.978965] CPU: 4 UID: 0 PID: 26399 Comm: (sd-bright) Tainted: G W 6.16.7-sdm845 #1000-postmarketos-qcom-sdm845 PREEMPT [11816.991580] Tainted: [W]=WARN [11816.994637] Hardware name: OnePlus 6 (DT) [11816.998735] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [11817.005844] pc : clk_branch_toggle+0x128/0x178 [11817.010384] lr : clk_branch_toggle+0x124/0x178 [11817.014956] sp : ffff8000991f3970 [11817.018358] x29: ffff8000991f3980 x28: ffff0000dad38000 x27: 0000000000000000 [11817.025634] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [11817.032887] x23: 0000000000000000 x22: ffffa63e2af42178 x21: ffffa63e2b56e128 [11817.040169] x20: ffffa63e29da5a90 x19: 0000000000000000 x18: 0000000000000003 [11817.047451] x17: 0000000000000000 x16: 000000000000000c x15: 0000000000000003 [11817.054701] x14: ffffa63e2b2f6a10 x13: 0000000000000003 x12: 0000000000000003 [11817.061982] x11: 00000000ffffefff x10: c0000000ffffefff x9 : e43cc05c4996c100 [11817.069260] x8 : e43cc05c4996c100 x7 : 7461206b63757473 x6 : 0000000000000027 [11817.076511] x5 : ffffa63e2b8726d3 x4 : ffffa63e2ae146c4 x3 : 0000000000000000 [11817.083792] x2 : 0000000000000000 x1 : ffff8000991f3710 x0 : 00000000fffffff0 [11817.091042] Call trace: [11817.093572] clk_branch_toggle+0x128/0x178 (P) [11817.098112] clk_branch2_disable+0x28/0x40 [11817.102308] clk_core_disable+0x64/0x1b8 [11817.106358] clk_core_disable_lock+0x90/0x120 [11817.110810] clk_disable+0x2c/0x40 [11817.114298] dsi_link_clk_disable_6g+0x78/0x98 [11817.118871] msm_dsi_host_xfer_restore+0xf0/0x120 [11817.123667] msm_dsi_manager_cmd_xfer+0xfc/0x178 [11817.128411] dsi_host_transfer+0x48/0x110 [11817.132509] mipi_dsi_dcs_set_display_brightness_large+0x8c/0xd0 [11817.138651] sofef00_panel_bl_update_status+0x3c/0x60 [11817.143802] backlight_device_set_brightness+0x88/0x128 [11817.149124] brightness_store+0x64/0xa8 [11817.153082] dev_attr_store+0x24/0x40 [11817.156835] sysfs_kf_write+0x8c/0xb8 [11817.160591] kernfs_fop_write_iter+0xe4/0x190 [11817.165073] do_iter_readv_writev+0x168/0x1c8 [11817.169515] vfs_writev+0x16c/0x378 [11817.173122] do_writev+0x84/0x130 [11817.176523] __arm64_sys_writev+0x2c/0x40 [11817.180618] invoke_syscall+0x48/0x100 [11817.184460] el0_svc_common+0x88/0xe8 [11817.188217] do_el0_svc+0x28/0x40 [11817.191621] el0_svc+0x38/0x88 [11817.194766] el0t_64_sync_handler+0x78/0x108 [11817.199161] el0t_64_sync+0x198/0x1a0 Signed-off-by: Cédric Bellegarde <cedric.bellegarde@adishatz.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260706051825.78752-1-cedric.bellegarde@adishatz.org
2026-07-20drm/panel: Add Novatek NT36536 panel driverPengyu Luo
Add a driver for panels using the Novatek NT36536 Display Driver IC, including support for the CSOT PP8807HB1-1, a dual-link 10-bit panel found in LENOVO Legion Y700 Gen4. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260709142846.12463-3-mitltlatltl@gmail.com
2026-07-20drm/panel: find_panel_by_fwnode() return a counted referenceAlbert Esteve
find_panel_by_fwnode() is the fwnode-based counterpart to of_drm_find_panel(), used internally by drm_panel_add_follower(). Like of_drm_find_panel(), it returned an unrefcounted pointer, leaving a window where the panel could be freed between the lookup and first use. drm_panel_add_follower() worked around the missing panel kref by calling get_device() on the panel's underlying struct device. However, get_device() only prevents the device kobject from being freed. It does not prevent the panel's kzalloc()'d container memory from being released when the kref reaches zero. Apply the same fix: call drm_panel_get() under panel_lock before returning. Since find_panel_by_fwnode() now transfers a counted reference to drm_panel_add_follower(), drm_panel_remove_follower() must balance it with a matching drm_panel_put(). Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260717-drm_refcount_wiring-v3-4-023900c32e01@redhat.com
2026-07-20drm/panel: of_drm_find_panel() return a counted referenceAlbert Esteve
Callers of of_drm_find_panel() and drm_of_find_panel_or_bridge() receive a pointer with no reference held, creating a window where the panel device can be unregistered and freed between the lookup and first use (e.g., drm_panel_prepare()). Fix the lookup function by acquiring a reference with drm_panel_get() before returning, under panel_lock. Callers are now responsible for calling drm_panel_put() when they no longer need the pointer. For bridge drivers that immediately wrap the panel in a panel_bridge (which acquires its own reference), release the lookup reference right after the bridge creation call. For analogix-anx6345, which stores the panel for direct use, release the reference in the i2c remove path. For platform drivers using analogix_dp_core with a component lifecycle (exynos_dp, rockchip analogix_dp), release the lookup reference in the platform remove() function. The panel_bridge created during bind() holds a separate reference that devm cleanup releases after remove() returns. Also fix devm_drm_of_get_bridge() and drmm_of_get_bridge() in bridge/panel.c itself, update a second batch of drivers calling of_drm_find_panel() or drm_of_find_panel_or_bridge() to release the lookup reference after wrapping the panel in a bridge, and handle the cases where a panel is found but cannot be used, dropping the reference immediately in those paths. Assisted-by: Claude:claude-opus-4-6 Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260717-drm_refcount_wiring-v3-3-023900c32e01@redhat.com
2026-07-20drm/bridge/panel: hold a reference to the wrapped panelAlbert Esteve
drm_panel_bridge_add_typed() stores a pointer to the drm_panel it wraps, but never acquires a reference to it. If the panel device goes away while a panel_bridge still exists, the dangling pointer can be dereferenced through panel_bridge->panel. Acquire a reference in drm_panel_bridge_add_typed() with drm_panel_get() and release it in each teardown path. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260717-drm_refcount_wiring-v3-2-023900c32e01@redhat.com
2026-07-20drm/panel: have drm_panel_add/remove manage a list referenceAlbert Esteve
The global panel_list holds raw pointers to drm_panel objects. Nothing prevents a panel from being freed while it is still linked in the list: if a driver's probe calls drm_panel_add() and then fails at a later step, panel->list remains in panel_list. Any subsequent call to of_drm_find_panel() that iterates the list will dereference freed memory. Have drm_panel_add() acquire a reference via drm_panel_get() before inserting the panel into the list, and have drm_panel_remove() drop it via drm_panel_put() after removing the panel from the list. The global registry now holds a counted reference for as long as the panel is listed, ensuring the object outlives any concurrent lookup. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260717-drm_refcount_wiring-v3-1-023900c32e01@redhat.com
2026-07-20drm/i915/dp_tunnel: Add UHBR tunneling supportImre Deak
Add support for UHBR link rates on Thunderbolt tunneled links. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-7-imre.deak@intel.com
2026-07-20drm/i915/dp: Disable UHBR link configs with 1/2 lanesImre Deak
Disable 1 and 2 lane link configurations on UHBR tunneled links, according to DP Standard v2.1b "3.5.2.16.3 128b/132b DPRX Lane Count Conversion Failure Indication and Corrective Action". A tunnel can indicate if it's not affected by this limitation, check for that and skip disabling the unsupported lanes for a well-behaving tunnel. The Standard in the same section also describes a workaround for 2 lanes which requires assisstance from the sink, where the sink indicates at the end of the link training sequence if the link training must be retried. This mechanism also requires quirking out some sinks - based on the sink's DPCD OUI and EDID identifications - which doesn't implement this link training feedback indication properly. This patch leaves the implementation of this workaround for a follow-up, but prepares for it already by detecting the supported number of lane counts at a place where both DPCD OUI and EDID is available for the quirk detection. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-6-imre.deak@intel.com
2026-07-20drm/i915/dp: Remove UHBR dependency from SST fallback kunit testImre Deak
After fallback between UHBR and non-UHBR link rates got enabled in a previous change, there is no need to test fallback sequences for UHBR and non-UHBR rates separately. Make the test simply start from the maximum (UHBR) rate. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-5-imre.deak@intel.com
2026-07-20drm/i915/dp: Enable SST fallback between UHBR and non-UHBR ratesImre Deak
Enable link training fallback between UHBR and non-UHBR link rates on DP SST links. This was disabled so far to preserve the fallback behavior. There isn't a known issue related to such a fallback and DP MST has been using this for a while already. Also, enabling UHBR rates over Thunderbolt tunnels in a follow-up change, which at least on some links supports only 4 lanes and not 1 or 2 lanes on UHBR, makes a UHBR->non-UHBR fallback scenario more likely. At the same time align the corresponding link training fallback kunit test, allowing a UHBR <-> non-UHBR fallback there as well. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.comd> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-4-imre.deak@intel.com
2026-07-20drm/i915/dp: End link configuration loops properlyImre Deak
Call intel_dp_link_caps_iter_end() after the link configuration loops. At the moment this call only clears the iteration object, so the lack of call didn't cause an actual issue. Cc: Luca Coelho <luciano.coelho@intel.com> Fixes: 7266df62ed0a7 ("drm/i915/dp: Iterate configurations via link_caps for SST non-DSC") Fixes: 4f104fc10a461 ("drm/i915/dp: Iterate configurations via link_caps for SST DSC") Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-3-imre.deak@intel.com
2026-07-20drm/dp_tunnel: Add UHBR tunneling supportImre Deak
Add the DPCD registers and detection required to support UHBR link rates over Thunderbolt tunnels. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-2-imre.deak@intel.com
2026-07-20drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for DPCD ↵Suraj Kandpal
backlight Turns out some panels allow only AUX based backlight by just setting the DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and not setting the DP_EDP_BACKLIGHT_AUX_ENABLE_CAP. If we make DP_EDP_BACKLIGHT_AUX_ENABLE_CAP a necessity for AUX based DPCD backlight these panels loose the ability to manipulate backlight via AUX, especially ones with no PWM controller. Remove this check from function so that panels who do not advertise DP_EDP_BACKLIGHT_AUX_ENABLE_CAP but advertise DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP are able to manipulate backlight again. Fixes: ed8be780bdbc ("drm/i915/backlight: Fix VESA backlight possible check condition") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16507 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260716030959.436430-1-suraj.kandpal@intel.com (cherry picked from commit 7d594b24c915afb4b0c5fb8875403253daef5b24) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-20drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for DPCD ↵Suraj Kandpal
backlight Turns out some panels allow only AUX based backlight by just setting the DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and not setting the DP_EDP_BACKLIGHT_AUX_ENABLE_CAP. If we make DP_EDP_BACKLIGHT_AUX_ENABLE_CAP a necessity for AUX based DPCD backlight these panels loose the ability to manipulate backlight via AUX, especially ones with no PWM controller. Remove this check from function so that panels who do not advertise DP_EDP_BACKLIGHT_AUX_ENABLE_CAP but advertise DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP are able to manipulate backlight again. Fixes: ed8be780bdbc ("drm/i915/backlight: Fix VESA backlight possible check condition") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16507 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260716030959.436430-1-suraj.kandpal@intel.com
2026-07-20drm/xe/xe_ras: Add support to query device memory errorsRiana Tauro
Add initial support to query uncorrectable device memory errors from system controller. The recovery action for memory errors depends on the error category. Firmware will set only one error category per response. Double bit ECC (Error Correcting Code) errors will be handled using Page offlining in a later patch. Poison and data parity errors are only logged. Rest of the errors require SBR (Secondary Bus Reset) to recover. Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Link: https://patch.msgid.link/20260717141650.2487761-8-riana.tauro@intel.com Signed-off-by: Riana Tauro <riana.tauro@intel.com>
2026-07-20drm/xe/xe_ras: Handle uncorrectable SoC Internal errorsRiana Tauro
Some critical errors such as CSC firmware and Punit are reported under SoC internal errors and require special handling. CSC errors are classified into hardware errors and firmware errors. Hardware errors can be recovered using a SBR (Secondary Bus Reset) whereas firmware errors are critical and require a firmware flash. On such errors, device is wedged and runtime survivability mode will be enabled to notify userspace that a firmware flash is required. PUNIT uncorrectable errors can only be recovered through a cold reset. Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Link: https://patch.msgid.link/20260717141650.2487761-7-riana.tauro@intel.com Signed-off-by: Riana Tauro <riana.tauro@intel.com>
2026-07-20drm/xe/xe_survivability: Decouple survivability info from boot survivabilityRiana Tauro
On CSC runtime firmware errors that requires firmware flash through SPI, PCODE sets the FDO mode bit in the Capability register. Currently the survivability_info group is created only for boot survivability. Create survivability_info group even for runtime survivability to allow userspace to check FDO mode sysfs. Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Link: https://patch.msgid.link/20260717141650.2487761-6-riana.tauro@intel.com Signed-off-by: Riana Tauro <riana.tauro@intel.com>
2026-07-20drm/xe/i2c: use device_create_managed_software_node()Bartosz Golaszewski
This driver intentionally uses the fine-grained approach to creating platform devices. It assigns a software node as the primary firmware node of the device it creates. Ahead of improving the reference counting of platform device software nodes, switch to using device_create_managed_software_node(). This way, we create a dynamic software node whose life-time is tied to the device to which it's assigned. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260716-swnode-remove-on-dev-unreg-v8-3-5c2b8cc38c28@oss.qualcomm.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-18drm/msm/a6xx: Add Adreno 722 supportPuranam V G Tejaswi
Add support for Adreno A722, a member of the GEN1 A7xx family. It is derived from A730 and shares the same IP-level configurations: HWCG registers, protected registers, GBIF CX registers and gmu_cgc_mode. Major differences include lower cache/core counts, 1MB GMEM, no Concurrent Binning & LPAC support. Some of the peripheral blocks like RSCC are from A740 that resulted in updates to RSC layout. Add a new entry to the catalog to describe the usual configuration and few additional fixup mainly due to missing CB/LPAC features and updated RSC layout. Signed-off-by: Puranam V G Tejaswi <puranam.tejaswi@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/740959/ Message-ID: <20260718-eliza-gpu-v2-3-64379dbebd7a@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-18drm/msm/a6xx: Rename GBIF_CX_CONFIG to a A6XX- variant registerAkhil P Oommen
The GBIF_CX_CONFIG register exists on GPUs prior to A8XX (it is used on A722, for example), so it should be tagged as an A6XX variant to match the register spec. Widen its variant range from "A8XX-" to "A6XX-" in the register XML and rename the generated macro accordingly at all existing usage sites. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/740957/ Message-ID: <20260718-eliza-gpu-v2-2-64379dbebd7a@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-18drm/msm/a6xx: Fix RBBM_CLOCK_CNTL3_TP0 value in a730_hwcgPuranam V G Tejaswi
The RBBM_CLOCK_CNTL3_TP0 entry in a730_hwcg has bits[19:16] set to 2 (clock gating enabled for that TP0 stage). As per the latest recommendation, clear this nibble to disable clock gating for this particular stage. Fixes: 9588d2f860a4 ("drm/msm/a6xx: Add A730 support") Signed-off-by: Puranam V G Tejaswi <puranam.tejaswi@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/740955/ Message-ID: <20260718-eliza-gpu-v2-1-64379dbebd7a@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-18drm/msm/adreno: Add support for A704 GPUAditya Sherawat
Adreno A704 GPU found in Shikra is an IP reuse of A702 GPU with very minimal changes. The only KMD facing difference is the chipid and the zap firmware which is specified via devicetree. Just add the new chipid to enable support for A704 GPU in Shikra. Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/738931/ Message-ID: <20260710-shikra-gpu-v6-1-b388ec5dce77@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-18Merge remote-tracking branch 'drm/drm-next' into msm-next-backmergeRob Clark
Backmerge of drm-next, mainly to pick up dt bindings docs updates to avoid conflicts. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-18drm/vc4: hdmi: take i2c adapter module referenceJohan Hovold
The i2c subsystem currently blocks during adapter deregistration whenever there are consumers holding a reference. Switch to using of_get_i2c_adapter_by_node() which also takes a reference to the adapter module so that an attempt to unload the module while in use fails gracefully instead of blocking uninterruptibly. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260716132448.1565278-1-johan@kernel.org Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-18drm/v3d: Associate BOs with every job that accesses themMaíra Canal
A submission can expand into a chain of jobs (e.g. bin + render + cache clean). Implicit synchronization in v3d_submit_lock_reservations() is gated on each job's bo[], but the BO list was only ever attached to the last job of the chain. When that last job is a trailing CACHE_CLEAN job, the job that actually consumes the BOs (that is, a RENDER or CSD job) was left with bo_count == 0 and picked up no implicit dependencies. It could therefore be dispatched to the hardware and read a BO while another context was still writing it, leading to data corruption. Attach the BOs to the job that consumes them, so (1) it acquires the correct implicit dependencies during reservation locking and (2) they are kept mapped until the end of the submission. Give it references to all consuming job's BOs through v3d_job_reference_bos() instead of looking the handles up a second time; that avoids a redundant lookup and guarantees both jobs reference the exact same objects. As the CACHE_CLEAN job now carries a BO array as well, add a per-job `has_implicit_dep` flag so that only the consuming jobs take implicit dependencies. The CACHE_CLEAN job (a global flush) and the BIN job (binning waiting on another context is not a realistic scenario) are excluded. Fixes: dffa9b7a78c4 ("drm/v3d: Add missing implicit synchronization.") Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260710114734.2731000-1-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-17drm/xe/xe3p_lpg: Program TR_PTA_MODEMatt Roper
Up until Xe3p_LPG, the PTA_MODE register controlled cacheability of accesses to the page tables for both PPGTT and TRTT. Starting with Xe3p_LPG, PTA_MODE is now only responsible for the PPGTT accesses, and a separate register, TR_PTA_MODE is used to control the TRTT accesses. The currently recommeded value for TR_PTA_MODE differs from PTA_MODE on Xe3p_LPG. Track and program this value separately in the driver. Note that even though the Xe3p_LP[G/M] IPs didn't add support for this new TR_PTA_MODE register until b-stepping, it's safe us to ignore that detail code-wise. Writes of the unrecognized registers on a-step hardware will be silently ignored, and the reads on a-step will come back as 0x0 which happens to be the value we'd be trying to program on these IP versions anyway (for both graphics and media). The new TRTT-specific register also does not exist on Xe3p_XPC platforms. v2: - Split gt_tr_pta_entry() out from gt_pta_entry(). (Gustavo) - Fix copy/paste mistake that caused us to write the PPGTT value to the TRTT register in the MCR path. (Sashiko) Bspec: 79814, 71582 Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260716-tr_pta_mode-v2-1-e4cd50da1c94@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-07-17Merge tag 'drm-fixes-2026-07-18-1' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Daie Airlie: "Weekly drm fixes, there is amdgpu, xe and i915 and then a lot of scattered fixes. Looks about the right level for the new right. ttm: - Handle NULL pages and backup handles in ttm_pool_backup() correctly gpusvm: - Improve unmap and error handling on gpusvm udmabuf: - Always synchronize for CPU in begin_cpu_udmabuf xe: - Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOCK - Hold a dma-buf reference for imported BOs - Fix writable override for CRI - Fix VF CCS attach/detach race with in-flight BO moves - Fix WOPCM size for LNL+ - Reset current_op in xe_pt_update_ops_init - Keep scheduler timeline name alive - Hold device ref until queue teardown completes - Disable display in admin only PF mode i915: - NV12 display fix for bigjoiner - clear watermark on plane disable - GT selftest fixes host1x: - Fix UAF amdxdna - Fix UAF - Reject more invalid amdxdna command submissions ivpu: - Fix wrong read - Handle invalid firmware log in ivpu panthor: - Fix error handling virtio: - Fix virtio deadlock - Fix invalid gem detach amdgpu: - DCN 4.2 fixes - NUTMEG fixes - 8K panel fix - Backlight fixes - UserQ fix - Fix bo->pin leaking in amdgpu_bo_create_reserved() - VFCT fixes - devcoredump fixes - Display fixes - SMU7 DPM fix - AC/DC fixes for SMU7 and SI - Queue reset fix - PCIe DPM fix - XHCI/GPU resume ordering fix - Pageflip timeout fix amdkfd: - Fix potential overflow in CWSR size calculation - DQM error clean up fixes * tag 'drm-fixes-2026-07-18-1' of https://gitlab.freedesktop.org/drm/kernel: (61 commits) Revert "drm/amd/display: Restore 5s vbl offdelay for NV3x+ DGPUs" drm/amd/display: check GRPH_FLIP status before sending event drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock drm/amd: Create a device link between APU display and XHCI devices drm/amd/display: wire DCN42B mcache programming callback drm/amd/display: set new_stream to NULL after release drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05 drm/amdkfd: free MQD managers on DQM init failures drm/amdgpu/ttm: Consider concurrent VM flushes for buffer entities drm/amd/pm/smu7: Fix AC/DC switch notification drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge drm/amdgpu: always emit the job vm fence drm/amd/pm/si: Fix AC/DC switch notification drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized drm/amd/display: dce100: skip non-DP stream encoders for DP MST drm/amd/display: Set native cursor mode for disabled CRTCs drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X) drm/amd/display: fix __udivdi3 link error drm/amdgpu: Reserve space for IB contents in devcoredumps drm/amdgpu: Print vmid, pasid and more task info in devcoredump ...
2026-07-18Merge tag 'amd-drm-fixes-7.2-2026-07-17' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.2-2026-07-17: amdgpu: - DCN 4.2 fixes - NUTMEG fixes - 8K panel fix - Backlight fixes - UserQ fix - Fix bo->pin leaking in amdgpu_bo_create_reserved() - VFCT fixes - devcoredump fixes - Display fixes - SMU7 DPM fix - AC/DC fixes for SMU7 and SI - Queue reset fix - PCIe DPM fix - XHCI/GPU resume ordering fix - Pageflip timeout fix amdkfd: - Fix potential overflow in CWSR size calculation - DQM error clean up fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260717215008.998399-1-alexander.deucher@amd.com
2026-07-17Revert "drm/amd/display: Restore 5s vbl offdelay for NV3x+ DGPUs"Leo Li
Now that proper fixes have been found, let's revert this workaround. This reverts commit a1fc7bf6677eb547167cb72b3bcafdc34b976692. Tested-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f64a9be5653689ff43e148cd8a6483077488c8e5) Cc: stable@vger.kernel.org # 8382cd234981: drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock Cc: stable@vger.kernel.org # 48ab86360af1: drm/amd/display: check GRPH_FLIP status before sending event Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: check GRPH_FLIP status before sending eventLeo Li
[Why] After unifying DCN interrupt sources under VUPDATE_NO_LOCK, we have two remaining issues to clean up: 1. On DCN, flip completion is now delivered from VUPDATE_NO_LOCK (dm_crtc_high_irq_handler) instead of GRPH_PFLIP. But VUPDATE_NO_LOCK fires every frame, regardless of whether a flip has latched. 2. There is a window during commit where a flip is armed (pflip_status = SUBMITTED) but not yet programmed into HW. If the VUPDATE_NO_LOCK fires in that window, its handler would deliver a flip event to userspace before HW has latched to it. If userspace then renders to what it believes is now the back buffer (but HW is still latched to it!), it will cause display corruption. This issue seemed to have been introduced by: commit 1159898a88db ("drm/amd/display: Handle commit plane with no FB.") Enabling replay or psr extended the duration of this window, and hence made corruption more likely to be observed. [How] * Move acrtc->event/pflip_status arming to after update_planes_and_stream_adapter() has programmed the flip into HW. This closes the window where pflip_status is SUBMITTED but the flip is not yet programmed. * Add dc_get_flip_pending_on_otg(), which reads the HUBP flip-pending status straight from HW for the pipe(s) bound to an OTG instance. It is keyed only by otg_inst and does not take or mutate a dc_plane_state, so it is safe to call from the OTG interrupt handler without racing a concurrent commit that may be modifying plane state. * Optimistically query for flip-pending after programming, in the event that HW latched to the new fb between programming start and arming event. If it latched, send the vblank event immediately, rather than wait for the next vblank IRQ. * In the VUPDATE_NO_LOCK handler, only deliver flip completion once dc_get_flip_pending_on_otg() reports the flip is no longer pending. Otherwise leave the flip armed and retry on the next vupdate. * For DCE, maintain the existing behavior of arming flips before programming, and relying on GRPH_FLIP to fire at HW latch. v2: * Drop flip_programmed completion object, instead move event/pflip_status arming after programming. * For DCN, optimistically query for flip pending immediately after programming, and if it latched, send event right away. v3: * Fix event timestamps on optimistic flip latch detection, where it's possible for it to run *before* the vupdate IRQ updates the timestamp. * Add more docstrings for DCN vblank handling. * Clean up if conditions in dm_arm_vblank_event(). * Code style cleanup on braces surrounding multi-line statements. Fixes: 9b47278cec98 ("drm/amd/display: temp w/a for dGPU to enter idle optimizations") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/3787 Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141 Assisted-by: Copilot:claude-opus-4.8 Tested-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f64a9be5653689ff43e148cd8a6483077488c8e5) Cc: stable@vger.kernel.org # 8382cd234981: drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lockLeo Li
[Why] On DCN, vblank events were delivered from VSTARTUP/VUPDATE (dm_crtc_high_irq/dm_vupdate_high_irq) and pageflip completion from GRPH_PFLIP (dm_pflip_high_irq). These signals can be masked by hardware by a few things: * DPG - DCN can Dynamically Power Gate parts of the display pipe when a self-refresh capable eDP is connected. DPG is engaged when there's enough static frames (detected through drm_vblank_off). Once gated, even though the OTG (output timing generator) is still enabled, VSTARTUP and GRPH_FLIP are masked. * GSL - Driver can use the Global Sync Lock to block HW from latching onto double-buffered registers during programming, to prevent HW from latching onto a partially programmed state. This will mask VSTARTUP, GRPH_FLIP, and VUPDATE. See dcn20_pipe_control_lock(). * MALL - A DCN accessible cache introduced in DCN32+ DGPUs that can store fb data to allow for longer DRAM sleep. When scanning out from MALL, VSTARTUP is masked. When masked, events are never delivered, which can show up as flip_done timeouts in the wild. However, there is an interrupt source on DCN that is never masked: VUPDATE_NO_LOCK. It's simply an unmasked variant of VUPDATE, which fires while the OTG is active, at the exact point hardware latches double-buffered registers. It is therefore the natural single signal for delivering both vblank and flip-completion events on DCN, and the correct point to timestamp both VRR and non-VRR vblanks. DCE's interrupt sources are different, it does not have an unmaskable VUPDATE_NO_LOCK. The only unmaskable DCE interrupt is VLINE0, but it can only be programmed as a vline offset from vsync_start, making it unsuitable for VRR. Thus, we keep DCE untouched and use the existing mix of interrupt sources. [How] For DCN1 and newer only: * Factor the body of dm_crtc_high_irq() into dm_crtc_high_irq_handler() and drive it from dm_vupdate_high_irq() (VUPDATE_NO_LOCK). DCE keeps using dm_crtc_high_irq() (VSTARTUP) and dm_pflip_high_irq() (GRPH_PFLIP) unchanged. * Stop registering VSTARTUP (crtc_irq) and GRPH_PFLIP (pageflip_irq) on DCN, and stop enabling them in amdgpu_dm_crtc_set_vblank() / manage_dm_interrupts(). Enable VUPDATE whenever vblank is enabled on DCN (previously only in VRR mode). The secure-display vline0 interrupt is left untouched. * VUPDATE_NO_LOCK does not early-fire on an immediate (tearing / async) flip, since HW latches the new address right away. Deliver the flip completion event immediately after programming such flips in amdgpu_dm_commit_planes(), and clear pflip_status so the next vupdate handler does not double-send. v2: Do not gate VUPDATE_NO_LOCK on DCN in dm_handle_vrr_transition() Also toggle VUPDATE_NO_LOCK on DCN in dm_gpureset_toggle_interrupts() Re-cook vblank event count and timestamp for immediate flips Fixes: 9b47278cec98 ("drm/amd/display: temp w/a for dGPU to enter idle optimizations") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/3787 Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141 Assisted-by: Copilot:claude-opus-4.8 Co-developed-by: Matthew Schwartz <matthew.schwartz@linux.dev> Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> Tested-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c87e6635d2db02c88ae8d09529362da672d34770) Cc: stable@vger.kernel.org
2026-07-17drm/amd: Create a device link between APU display and XHCI devicesMario Limonciello
Some AMD APU multi-function devices expose an integrated USB xHCI controller. In some circumstances (such as larger VRAM), the PM core can resume can fail when the xHCI controller is resuming in parallel with the GPU/display function. On affected systems, the xHCI controller can complete pci_pm_resume and start resuming USB devices while the GPU is still in its much longer resume path. This race condition leads to USB device resume failures followed by: xhci_hcd ...: xHCI host not responding to stop endpoint command xhci_hcd ...: HC died; cleaning up Create a device link from any xHCI controller sharing the same PCIe root port as the APU display function. The link uses DL_FLAG_STATELESS and DL_FLAG_PM_RUNTIME to ensure the GPU completes its resume before the xHCI controller begins resuming USB devices. This device link is done specifically in amdgpu so that if the platform firmware has been modified such that this issue doesn't happen the version can be detected and the workaround skipped. Suggested-by: Aaron Ma <aaron.ma@canonical.com> Reported-by: mrh@frame.work Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221073 Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Tested-by: Alexander F <superveridical@gmail.com> Tested-by: Francis DB <francisdb@gmail.com> Link: https://patch.msgid.link/20260713195313.1739762-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 07c93d7eeb0d990bc1b8e3b1eafa464bc9feee97) Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: wire DCN42B mcache programming callbackPengpeng Hou
DCN42B enables DML2 and DML21 by default and defines dcn42b_prepare_mcache_programming(), but the resource function table only wires the callback when CONFIG_DRM_AMD_DC_DML21 is defined. There is no in-tree Kconfig symbol named DRM_AMD_DC_DML21, so the preprocessor always removes the callback entry. Sibling DCN42 and DCN401 resource tables wire their prepare_mcache_programming callbacks unconditionally, and the core DC code already checks whether the callback pointer is present before calling it. Remove the stale guard so DCN42B exposes the callback relation that its source and DML21 build world already provide. This is an RFC patch draft from static conditional callback legality auditing. It needs AMD display maintainer review before submission as a final fix. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 85453fb4ff726e1ddb9984ee83dca260903c5353)
2026-07-17drm/amd/display: set new_stream to NULL after releaseWenTao Liang
In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. Fixes: 9b690ef3c704 ("drm/amd/display: Avoid full modeset when not required") Signed-off-by: WenTao Liang <vulab@iscas.ac.cn> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28) Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05Alessandro Rinaldi
The Lenovo Legion 5 15ARH05 (Renoir) ships a BOE 0x08DF eDP panel that advertises AUX/DPCD backlight control, so amdgpu's automatic detection (amdgpu_backlight == -1) selects AUX. On this panel the AUX backlight path has no effect: brightness writes are accepted but the panel level never changes, the display is stuck at a fixed brightness and max_brightness is reported as a bogus 511000. As a result neither the desktop brightness slider nor the brightness hotkeys do anything. Forcing PWM backlight (amdgpu.backlight=0) restores working control: max_brightness becomes 65535 and the level tracks writes. This has long been applied by users as a manual kernel-parameter workaround. Extend the generic panel backlight quirk with a force_pwm flag, add an entry for the Legion 5 15ARH05 / BOE 0x08DF panel, and have amdgpu disable AUX backlight (use PWM) when the quirk matches and the user lets the driver auto-select the backlight type. Signed-off-by: Alessandro Rinaldi <ale@alerinaldi.it> Tested-by: Alessandro Rinaldi <ale@alerinaldi.it> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 81b39f43e7e53589491e2eef6bad5389626b4b9c) Cc: stable@vger.kernel.org
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-07 23:15:02 +0000