summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-07-14drm/amd/display: Generalize DMUB memory flushes from hostDillon Varone
[WHY&HOW] Add DMUB service context to aid in platform abstraction when flushing memory from the host. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Dillon Varone <Dillon.Varone@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amd/display: Fix KUnit backlight tests for CACPAlex Hung
[WHY] A change was added in amdgpu_dm_should_create_sysfs() to check link->panel_type instead of caps->aux_support, and removed the OLED exclusion from the ABM property attach path in amdgpu_dm_setup_backlight_device(). This broke three KUnit tests: - dm_test_should_create_sysfs_no_backlight_index and dm_test_should_create_sysfs_pwm_backlight returned false because kzalloc zeroes panel_type but PANEL_TYPE_LCD is 1. - dm_test_setup_backlight_device_oled_success crashed with a NULL pointer dereference in drm_object_attach_property since abm_level_property was NULL. [WHY] Set panel_type to PANEL_TYPE_LCD in the two sysfs tests and skip the ABM property attach path in the OLED setup test by setting amdgpu_dm_abm_level to 0. Cc: Chenyu Chen <chen-yu.chen@amd.com> Assisted-by: Copilot:Claude-Opus-4.6 Reviewed-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amdgpu/discovery: Fix device family for DCN42Roman Li
GC 11.7.0 and 11.7.1 should map to AMDGPU_FAMILY_GC_11_5_4 for DCN42. Fixes: cf591e67c095 ("drm/amdgpu: add support for GC IP version 11.7.0") Fixes: a928d8d81ec5 ("drm/amdgpu: add support for GC IP version 11.7.1") Signed-off-by: Roman Li <Roman.Li@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amdgpu: update mmhub 4.2.0 client listAlex Deucher
Update to the proper client list for mmhub 4.2.0. v2: fix typo (Alex) Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm: ensure blend mode supported if pixel format with alpha exposedLeandro Ribeiro
Before "drm/drm_blend: allow blend mode property without PREMULTI", userspace would have to assume that only PREMULTI was supported by drivers that didn't expose the blend mode property. But now userspace shouldn't rely on that, as they can't count with drivers always supporting PREMULTI. Warn if a driver exposes pixel formats with alpha but doesn't expose the blend mode property. This way userspace doesn't have to guess. Drivers triggering this warning must be fixed. Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260526181700.25310-3-leandro.ribeiro@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-07-14drm/drm_blend: allow blend mode property without PREMULTILeandro Ribeiro
Some hardware only supports the COVERAGE blend mode and lacks PREMULTI support entirely. DRM currently requires that PREMULTI is present when creating a blend mode property, which prevents such drivers from being properly upstreamed. Remove this restriction and allow drivers to create a blend mode property without PREMULTI, enabling support for hardware that implements only COVERAGE blend mode. This does not introduce a regression, as no existing upstream drivers expose only COVERAGE. However, userspace that wants to support such kind of hardware in the future will have to check the supported blend modes instead of assuming PREMULTI is always supported. Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260526181700.25310-2-leandro.ribeiro@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-07-14drm/bridge: sii9234: use dev_err_probe where applicableHenrik Grimler
In case of error during resource acquisition the driver should print an error message only if it is not deferred probe. Use dev_err_probe helper to handle this, which will also record defer probe reason for debugging. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Henrik Grimler <henrik@grimler.se> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260602-exynos4-sii9234-driver-v4-2-9b2fc38e104a@grimler.se Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm/bridge: sii9234: fix some typos in comments and messagesHenrik Grimler
Fix spelling and formatting so that the code is easier to follow, and so that it is more searchable. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Henrik Grimler <henrik@grimler.se> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260602-exynos4-sii9234-driver-v4-1-9b2fc38e104a@grimler.se Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm/gpusvm: publish dpagemap early to avoid device mapping leak on errorHonglei Huang
drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review. Fixes: f70da6f99d4f ("drm/gpusvm: pull out drm_gpusvm_pages substructure") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260701062800.409248-4-honghuan@amd.com
2026-07-14drm/gpusvm: do not route system pages to device_unmap() on IOVA unmapHonglei Huang
In a mixed range: ctx->allow_mixed dpagemap is not NULL while some entries are system pages. The unmap loop used: dma_unmap_page(...); else if (dpagemap && dpagemap->ops->device_unmap) dpagemap->ops->device_unmap(...); When use_iova is true the first condition is false for system pages, so they fall through to device_unmap() and a system DMA address is handed to the device specific unmap callback, risking invalid accesses or state corruption. Key the branch off addr->proto instead: system pages only need an explicit dma_unmap_page() in the non IOVA case, IOVA system pages are already torn down by the single dma_iova_destroy(), and only genuine device pages reach device_unmap(). This issue was found by Sashiko AI review. Fixes: 37ad039fb367 ("drm/gpusvm: Use dma-map IOVA alloc, link, and sync API in GPU SVM") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260701062800.409248-3-honghuan@amd.com
2026-07-14drm/gpusvm: free the whole IOVA reservation on unmapHonglei Huang
dma_iova_try_alloc() reserves IOVA for the entire range, but in a mixed range only the system pages are linked (their total size is state_offset) while device pages never touch the IOVA state. dma_iova_destroy() with state_offset only frees the linked part, permanently leaking the IOVA reserved for the device pages and eventually exhausting the IOVA space. Unlink the linked system-page portion and free the whole reserved IOVA instead. On the get_pages() error path state_offset is 0 (no page linked, dma_addr[0] unpopulated), so skip the unlink and just free the reservation; this also avoids reading the uninitialized dma_addr[0].dir there. Allocate the dma_addr array with the zeroing kvzalloc_objs() so every entry has a well-defined value. This issue was found by Sashiko AI review. Fixes: 37ad039fb367 ("drm/gpusvm: Use dma-map IOVA alloc, link, and sync API in GPU SVM") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260701062800.409248-2-honghuan@amd.com
2026-07-14drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO movesMatthew Brost
xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Assisted-by: GitHub_Copilot:claude-sonnet-5 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260714062440.3421225-1-matthew.brost@intel.com
2026-07-14drm/bridge: rename drm_for_each_bridge_in_chain_scoped() to ↵Luca Ceresoli
drm_for_each_bridge_in_chain() drm_for_each_bridge_in_chain_scoped() was added in commit e46efc6a7d28 ("drm/bridge: add drm_for_each_bridge_in_chain_scoped()") to provide a safer alternative to drm_for_each_bridge_in_chain(). Following commits converted all users to the _scoped variant. Finally commit 2f08387a444c ("drm/bridge: remove drm_for_each_bridge_in_chain()") removed the old drm_for_each_bridge_in_chain() macro. It's time to rename drm_for_each_bridge_in_chain_scoped() back to the original name. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260630-drm-bridge-alloc-getput-for_each_bridge-2-v2-1-e0a1094cd1eb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm/xe/nvm: fix writable override for CRIAlexander Usyskin
The witable override should be set when FDO_MODE bit is enabled. Fix the comparison to distingush this case from legacy systems where bit should be disabled to have override. Cc: stable@vger.kernel.org Fixes: 9dde74fd9e65 ("drm/xe/nvm: enable cri platform") Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260714-cri_nvm_fdo_flip-v2-1-14580e71b58e@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-14drm/i915/display: Fix too few bits in transcoder mask variablesJohn Harrison
New transcoder enum values (for CMTG) were recently added which pushed the maximum transcoder mask beyond 8bits. The patch in question updated the info structure's u8 to u16 but not any of the functions that process transcoder masks. So fix those as well. v2: Fix more instances (found by Sashiko) Signed-off-by: John Harrison <John.Harrison@Igalia.com> Fixes: 789dda6429e0 ("drm/i915/cmtg: Add CMTG transcoder offset in struct _device_info") Cc: Uma Shankar <uma.shankar@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260713234138.3861243-1-John.Harrison@Igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-14drm/bridge: fix wording in commentLuca Ceresoli
Fix a comment according to English grammar. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260701-drm-fix-graph-wording-v1-3-295605c5777b@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm/bridge: samsung-dsim: fix wording in commentLuca Ceresoli
Fix a comment according to English grammar. Link: https://lore.kernel.org/all/DI9ZFQUNMSBU.214AU8467OK76@bootlin.com/ Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260701-drm-fix-graph-wording-v1-2-295605c5777b@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm: of: fix wording in commentLuca Ceresoli
Fix a comment according to English grammar. Link: https://lore.kernel.org/all/DI9ZFQUNMSBU.214AU8467OK76@bootlin.com/ Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260701-drm-fix-graph-wording-v1-1-295605c5777b@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm/xe/pf: Disable display in admin only PF modeSatyanarayana K V P
Admin-only PF mode does not expose media or 3D execution capabilities to userspace, so display pipelines cannot receive rendered content. Fixes: d88c4bac8c2a ("drm/xe/pf: Restrict device query responses in admin-only PF mode") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260714053259.504308-2-satyanarayana.k.v.p@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-14Merge drm/drm-next into drm-xe-nextRodrigo Vivi
Sync some i915/display changes Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-14drm/xe/display: Do not allocate into stolen for new framebuffers.Maarten Lankhorst
Prefer to use system memory for global framebuffers, and reserve the space for FBC use only. Now that multiple CRTC's can use FBC's, the simple heuristic of using less than half of stolen is no longer sufficient. Additionally, there are reports of system hangs when using stolen memory, and there are also various workarounds that are avoided by using system memory instead. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513 Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260630135523.1775379-4-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/i915/display: Fix NV12 ceiling division for bigjoiner caseVidya Srinivas
Commit 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation") computes the UV (chroma) surface start/size as ceiling(half of Y plane start/size) directly from the U16.16 fixed-point source rectangle: x = fp_16_16_to_int_ceil(fp_16_16_div2(src.x1)); For a single pipe the source coordinates are integers, so this is correct. (UV start = ceiling(half of Y plane start)). With bigjoiner + a plane scaler the picture changes. The pipe boundary is a fixed integer destination pixel, but the plane's position and the scaler ratio are arbitrary, so drm_rect_clip_scaled() maps the seam back to a *fractional* per-pipe source. For a 1280->2407 upscaled NV12 plane crossing the seam: master src: width = 1204 * 1280/2407 = 640.265899, x1 = 0 joiner src: width = 1203 * 1280/2407 = 639.734115, x1 = 640.265884 The luma path floors this to an integer (src.x1 >> 16 = 640), but the UV path takes ceiling(640.265884 / 2) = ceil(320.13) = 321. The Y plane then starts at column 640 while the UV plane starts at 321*2 = 642, pushing the chroma read one column past the 640-wide chroma surface on the joiner secondary: [CRTC:382:pipe C] PLANE ATS fault [CRTC:382:pipe C][PLANE:267:plane 1C] fault (CTL=0x81009400, ...) The spec "Y plane start" is the integer pixel the luma surface actually programs (640), not the pre-floor fixed-point value (640.27). Convert the Y plane start/size to integer first - matching skl_check_main_surface() - and then apply the ceiling. This is a no-op for the integer (non-joiner) case and yields the correct, in-bounds chroma offset for the fractional joiner seam: before fix after fix master 1B: x=0 w=321 x=0 w=320 -> [0, 320) slave 1C: x=321 w=320 x=320 w=320 -> [320, 640) The two halves now tile the 640-wide chroma plane exactly and the ATS fault is gone. Assisted-by: GitHub-Copilot:Claude-Opus-4.8 Fixes: 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation") Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260618181837.687302-1-vidya.srinivas@intel.com (cherry picked from commit 0c59cc78241c10e5f02d92b28d811b0435e706a7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-14drm/xe: Fix DPT allocation paths.Maarten Lankhorst
Remove the fallback for VRAM to system memory, I tested it and that doesn't work at all, only a black screen with pipe fault errors were observed. On systems with media GT, extra latency is added when accessing stolen memory when the GT is in MC6. Since we additionally aren't counting how much memory is used for stolen and we could in theory fill up the entire stolen area with DPT's, avoid using stolen and only use the default memory region. Using stolen may also result in random system hangs under load. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513 Fixes: 775d0adc01a5 ("drm/xe/fbdev: Limit the usage of stolen for LNL+") Cc: <stable@vger.kernel.org> # v6.12+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260630135523.1775379-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/i915: Print the phys_base in addition to the dma_addr for the BIOS FBVille Syrjälä
Print the dma_addr, phys_base and memory region name for the BIOS FB. Should make it a bit easier to see whether everything looks correct or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260511214122.8468-15-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14drm/i915: Fix BIOS FB memory region name debug printsVille Syrjälä
Apparently we never initialize the name of the struct resource underlying the memory region. Instead we need to look at the name stored directly in the memory region itself. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260511214122.8468-14-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14drm/xe: s/bar2/lmembar/Ville Syrjälä
The local memory BAR has a name (LMEMBAR). Use that instead of referring to it by its BAR register index. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-12-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/xe: Check the PTE local memory bit for initial FB in stolenVille Syrjälä
Do the PTE local memory bit check also for the case when the initial FB lives in stolen. We have two cases to worry about here: MTL+ with LMEMBAR, and pre-MTL with stolen being just (slightly special) physical memory. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260511214122.8468-11-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/xe: Abstract the initial FB PTE checks a bitVille Syrjälä
Add a few helpers that allow us to abstract the xe initial FB PTE check a bit. Still very ad-hoc compared to the nicely abstracted i915 counterpart, but whatever. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-10-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/xe: Print a debug message if we have no stolen for the initial FBVille Syrjälä
Inform the poor sop reading the logs why the initial FB was rejected if there is no stolen memory. Technically this should perhaps be an error since the plane is known to be enabled at this point, and if there is no stolen then it clearly can't be scanning out from anywhere. But maybe there are some virtualization passthrough cases and whatnot where we might not be able to get access to stolen, so keep it as debug (same as i915). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-9-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/xe: Do the initial FB size alignment earlierVille Syrjälä
For some reason we've split the alignment of 'base' vs. 'size' to live on separate sides of the xe initial plane PTE readout. There's no reason for this split, so make things less confusing by aligning both at the same time. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260511214122.8468-7-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/i915: Use drm_dbg_kms() for initial FB debugsVille Syrjälä
The initial FB stuff is ultimately about display stuff, so use the proper display specific debug level for it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-6-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14drm/i915: Throw away the BIOS fb if has the wrong depth/bppVille Syrjälä
Respect the user's choice of depth/bpp for the fbdev framebuffer and throw out the fb we inherited from the BIOS if it doesn't match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-4-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14drm/i915/fbdev: Extract bios_fb_ok()Ville Syrjälä
Pull the "is the BIOS FB OK?" checks to a helper function. We'll add other relevant checks there later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-3-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14drm/i915: Disable the plane if initial plane config readout failedVille Syrjälä
Properly turn off the plane if it is enabled but .get_initial_plane_config() failed for whatever reason. The hardware does (or at least did) perform some kind of automagic plane disable when the pipe gets disabled, but we don't rely on that anywhere else either. Also the GGTT/actual memory may get clobbered afterwards, so leaving the plane enabled here could result in visual corruption/GTT faults/etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-2-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14drm/xe: Hold a dma-buf reference for imported BOsNitin Gote
An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8023 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Cc: Christian Konig <christian.koenig@amd.com> Cc: Matthew Auld <matthew.auld@intel.com> Suggested-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260710191027.260160-2-nitin.r.gote@intel.com
2026-07-14drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOCHimal Prasad Ghimiray
When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: c1bb69a2e8e2 ("drm/xe/svm: Consult madvise preferred location in prefetch") Cc: Matthew Brost <matthew.brost@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260624174943.2808767-2-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2026-07-14drm/i915/display: Fix NV12 ceiling division for bigjoiner caseVidya Srinivas
Commit 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation") computes the UV (chroma) surface start/size as ceiling(half of Y plane start/size) directly from the U16.16 fixed-point source rectangle: x = fp_16_16_to_int_ceil(fp_16_16_div2(src.x1)); For a single pipe the source coordinates are integers, so this is correct. (UV start = ceiling(half of Y plane start)). With bigjoiner + a plane scaler the picture changes. The pipe boundary is a fixed integer destination pixel, but the plane's position and the scaler ratio are arbitrary, so drm_rect_clip_scaled() maps the seam back to a *fractional* per-pipe source. For a 1280->2407 upscaled NV12 plane crossing the seam: master src: width = 1204 * 1280/2407 = 640.265899, x1 = 0 joiner src: width = 1203 * 1280/2407 = 639.734115, x1 = 640.265884 The luma path floors this to an integer (src.x1 >> 16 = 640), but the UV path takes ceiling(640.265884 / 2) = ceil(320.13) = 321. The Y plane then starts at column 640 while the UV plane starts at 321*2 = 642, pushing the chroma read one column past the 640-wide chroma surface on the joiner secondary: [CRTC:382:pipe C] PLANE ATS fault [CRTC:382:pipe C][PLANE:267:plane 1C] fault (CTL=0x81009400, ...) The spec "Y plane start" is the integer pixel the luma surface actually programs (640), not the pre-floor fixed-point value (640.27). Convert the Y plane start/size to integer first - matching skl_check_main_surface() - and then apply the ceiling. This is a no-op for the integer (non-joiner) case and yields the correct, in-bounds chroma offset for the fractional joiner seam: before fix after fix master 1B: x=0 w=321 x=0 w=320 -> [0, 320) slave 1C: x=321 w=320 x=320 w=320 -> [320, 640) The two halves now tile the 640-wide chroma plane exactly and the ATS fault is gone. Assisted-by: GitHub-Copilot:Claude-Opus-4.8 Fixes: 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation") Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260618181837.687302-1-vidya.srinivas@intel.com
2026-07-14Merge tag 'rust-io-7.3-rc1' of ↵Danilo Krummrich
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core into drm-rust-next I/O type generalization and projection This series presents a major rework of I/O types, as a summary: - Make I/O regions typed. The existing untyped region still exists with a dynamically sized `Region` type. - Create I/O view types to represent subregion of a full I/O region mapped. A projection macro is added to allow safely create such subviews. - Split I/O traits, make I/O views play a central role, avoid duplicate monomorphization and less `unsafe` code. - Add a `SysMem` backend, and make `Coherent` implement `Io`. - Add copying methods (memcpy_{from,to}io and friends). This series generalize `Mmio` type from just an untyped region to typed representations (so `MmioRaw<T>` is `__iomem *T`). This allows us to remove the `IoKnownSize` trait; the information is sourced from just the pointer from the `KnownSize` trait instead. Building on top of that, `Mmio` and `ConfigSpace` have been converted to typed views of I/O regions rather than just a big chunk of untyped I/O memory. These changes made it possible to implement `Io` trait for `Coherent<T>`. Shared system memory, `SysMem` is also added to the series, given it similarity in implementation compared to `Coherent`. In fact, the series use `SysMem` to implement `Coherent`'s I/O methods. Built on these generalization, this series add `io_project!()`. `io_project!()` performs a safe way to project a bigger view to a small subviews, and some Nova code has been converted in this series to demonstrate cleanups possible with this addition. New `io_read!()`, `io_write!()` has been added that supersedes `dma_read!()`, `dma_write!()` macro. Although, they work for primitives only (to be exact, types that the backend is `IoCapable` of). One feature that was lost from the old `dma_read!()` and `dma_write!()` series was the ability to read/write a large structs. However, the semantics was unclear to begin with, as there was no guarantee about their atomicity even for structs that were small enough to fit in u32. Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/near/571198078 This is a stable tag for other trees to merge. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-13Merge patch series "rust: I/O type generalization and projection"Danilo Krummrich
Gary Guo <gary@garyguo.net> says: This series presents a major rework of I/O types, as a summary: - Make I/O regions typed. The existing untyped region still exists with a dynamically sized `Region` type. - Create I/O view types to represent subregion of a full I/O region mapped. A projection macro is added to allow safely create such subviews. - Split I/O traits, make I/O views play a central role, avoid duplicate monomorphization and less `unsafe` code. - Add a `SysMem` backend, and make `Coherent` implement `Io`. - Add copying methods (memcpy_{from,to}io and friends). This series generalize `Mmio` type from just an untyped region to typed representations (so `MmioRaw<T>` is `__iomem *T`). This allows us to remove the `IoKnownSize` trait; the information is sourced from just the pointer from the `KnownSize` trait instead. Building on top of that, `Mmio` and `ConfigSpace` have been converted to typed views of I/O regions rather than just a big chunk of untyped I/O memory. These changes made it possible to implement `Io` trait for `Coherent<T>`. Shared system memory, `SysMem` is also added to the series, given it similarity in implementation compared to `Coherent`. In fact, the series use `SysMem` to implement `Coherent`'s I/O methods. Built on these generalization, this series add `io_project!()`. `io_project!()` performs a safe way to project a bigger view to a small subviews, and some Nova code has been converted in this series to demonstrate cleanups possible with this addition. New `io_read!()`, `io_write!()` has been added that supersedes `dma_read!()`, `dma_write!()` macro. Although, they work for primitives only (to be exact, types that the backend is `IoCapable` of). One feature that was lost from the old `dma_read!()` and `dma_write!()` series was the ability to read/write a large structs. However, the semantics was unclear to begin with, as there was no guarantee about their atomicity even for structs that were small enough to fit in u32. Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/near/571198078 Link: https://patch.msgid.link/20260706-io_projection-v6-0-72cd5d055d54@garyguo.net Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-13Merge patch series "ForLt/CovariantForLt split, auxiliary closure API and ↵Danilo Krummrich
DevresLt" Danilo Krummrich <dakr@kernel.org> says: The ForLt trait currently guarantees covariance, which allows safe lifetime shortening via cast_ref(). However, some types (e.g. those containing Mutex<&'bound T>) are invariant over their lifetime parameter and cannot safely use cast_ref(). This series splits ForLt into two traits: - ForLt: base trait for all lifetime-parameterized types, providing only the Of<'a> GAT. - CovariantForLt: unsafe subtrait that guarantees covariance, providing a safe cast_ref() method. For invariant types, a closure-based API (registration_data_with()) is added to the auxiliary subsystem. The closure's HRTB prevents the caller from choosing a concrete lifetime, which would be unsound for invariant types. On top of that, this series adds DevresLt<F: ForLt>, a thin wrapper around Devres<F::Of<'static>> that shortens the stored 'static lifetime back to the caller's borrow scope. DevresLt provides both closure-based access (access_with/try_access_with for ForLt types) and direct reference access (access/try_access for CovariantForLt types). Also implement ForLt and CovariantForLt for Bar, IoMem and ExclusiveIoMem, and update their into_devres() methods to return DevresLt. Provide convenience type aliases DevresBar, DevresIoMem and DevresExclusiveIoMem. Link: https://patch.msgid.link/20260626183630.2585057-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-13drm/xe/multi_queue: preempt primary on queue group suspendNiranjana Vishwanathapura
In a multi-queue group only the group's primary queue interfaces with GuC for scheduling; suspend/resume of secondary queues is handled internally and is not forwarded to GuC. As a result, suspending a secondary queue alone (e.g. on its preempt fence signalling) does not disable the primary's GuC context, so in-flight GPU work of the group is not actually preempted. Make a secondary queue suspend/resume like any other queue, driven by its own xe_guc_exec_queue.suspend_count, and additionally forward the suspend/resume to the primary so the GPU is actually preempted. The forward is gated on the secondary's own 0->1 / 1->0 suspend_count transition, so each group member contributes exactly one suspend reference to the primary: the primary keeps its GuC context disabled until every member that suspended it has resumed, including across the resume-all-queues-each-rebind-cycle behavior. group->suspend_lock makes the secondary transition and the primary forward atomic, and a member leaving while still suspended (queue teardown) drops its reference on the primary. v2: Add comment about suspend_wait() in drop_suspend() v3: Do not suspend a secondary if primary is killed, wait for primay suspend to complete before drop_suspend() Assisted-by: Github-Copilot:Claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260713202317.2187787-14-niranjana.vishwanathapura@intel.com
2026-07-13drm/xe/guc: Add suspend refcount to exec queue opsThomas Hellström
With the lr.suspended flag a consumer already pairs its own suspend() and resume() correctly, and no current path issues overlapping suspends on the same queue. Add a reference count to the exec queue suspend operations, as a small self-contained building block for callers that can genuinely overlap. A queue stays suspended as long as any caller holds a suspend and only resumes once the last caller releases it, so each caller pairs its own suspend/resume without needing to know about the others. This is what the upcoming multi-queue support needs, where queues in a group share a primary and may be suspended concurrently. Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Co-authored-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260713202317.2187787-13-niranjana.vishwanathapura@intel.com
2026-07-13drm/xe/hw_engine_group: propagate suspend failures during mode switchNiranjana Vishwanathapura
The hw engine group fault-mode switch suspends all faulting LR queues but ignored the suspend()/suspend_wait() return value. A suspend() can fail (e.g. the queue is killed/banned/wedged), leaving the queue un-suspended, so silently continuing could later resume a queue that was never suspended. Propagate the failure instead: in xe_hw_engine_group_add_exec_queue() bail out if suspend() fails, and in xe_hw_engine_group_suspend_faulting_lr_jobs() undo the partial suspend via a new err_resume path that resumes the sibling queues already suspended in this call. Record per-queue success with lr.suspended so only queues that were actually suspended are waited on and resumed, and skip the cleanup resume() when suspend_wait() failed or the queue was reset/killed/banned/wedged (its suspend may not have completed, so resuming would trip the !suspend_pending assert in the resume path; teardown resolves its state instead). Gate the group resume worker (hw_engine_group_resume_lr_jobs_func()) on lr.suspended for the same reason, so it only resumes queues that were actually suspended. v2: Don't let a dying queue block the switch (Matt Brost) Assisted-by: Github-Copilot:Claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260713202317.2187787-12-niranjana.vishwanathapura@intel.com
2026-07-13drm/xe/guc: add uninterruptible suspend wait for cross-process cleanupNiranjana Vishwanathapura
Add a suspend_wait_blocking() exec queue op: an uninterruptible variant of suspend_wait() for callers that must complete a suspend on behalf of a queue that may belong to a different process than the calling task (e.g. cleanup/undo paths). An interruptible suspend_wait() returns -ERESTARTSYS when the calling task is signalled, which would leave the other process's queue suspended forever - a cross-process DoS. The blocking variant waits uninterruptibly and, on a genuine GuC timeout, bans and tears down the queue like suspend_wait() (shared via guc_exec_queue_suspend_timeout_ban()). It deliberately does not handle VF recovery since a blocking caller cannot retry. Assisted-by: Github-Copilot:Claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260713202317.2187787-11-niranjana.vishwanathapura@intel.com
2026-07-13drm/xe/guc: ban exec queue on suspend timeoutNiranjana Vishwanathapura
Harden guc_exec_queue_suspend_wait(): - In multi-queue mode the primary owns the group's GuC scheduling context, so wait on the primary's suspend to complete. - On timeout, ban the queue and trigger cleanup rather than leaving it suspended forever. Clearing suspend_pending via __suspend_fence_signal() lets a subsequent resume() proceed without tripping the !suspend_pending assert. A timeout on the primary wedges the whole group, so ban and tear down the entire group in the multi-queue case. The ban/cleanup is factored into guc_exec_queue_suspend_timeout_ban(). Add a note that on a signal (-ERESTARTSYS) the queue is not banned and the suspend is not confirmed complete, so callers must not resume() without re-confirming. Assisted-by: Github-Copilot:Claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260713202317.2187787-10-niranjana.vishwanathapura@intel.com
2026-07-13drm/xe: only resume exec queues that were actually suspendedNiranjana Vishwanathapura
A consumer-issued suspend() can fail (e.g. the queue is killed, banned or wedged), leaving the queue un-suspended. The consumer must then not issue the matching resume(): resuming a queue that was never suspended is incorrect. Add an lr.suspended flag to struct xe_exec_queue that records whether a consumer suspend() succeeded and a matching resume() is still owed. Set it on a successful suspend() in the preempt-fence path, clear it on resume(), and only resume queues that have it set. In resume_and_reinstall_preempt_fences() also skip queues that have since been reset/killed/banned/wedged: such a queue's suspend may not have completed (suspend_pending can still be set, e.g. a preempt fence signalled with -ENOENT without waiting), so resuming it would trip the !suspend_pending assert in the backend. Leave it marked suspended and let teardown resolve its state. A queue is only ever suspended by a single consumer at a time (preempt-fence mode and hw engine group fault mode are mutually exclusive), so a single flag is sufficient. Assisted-by: Github-Copilot:Claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260713202317.2187787-9-niranjana.vishwanathapura@intel.com
2026-07-13drm/i915/gt: use correct selftest config symbolPengpeng Hou
intel_engine_user.c checks CONFIG_DRM_I915_SELFTESTS before running the engine UABI isolation check. Kconfig defines DRM_I915_SELFTEST, without the trailing "S", and the rest of i915 uses CONFIG_DRM_I915_SELFTEST. Because CONFIG_DRM_I915_SELFTESTS is not backed by any Kconfig symbol, the IS_ENABLED() test is always false. Use the existing selftest symbol so the debug/selftest guarded path can be reached when selftests are enabled. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the Kconfig definition and the inconsistent guard in intel_engine_user.c. Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260705080225.436-1-pengpeng@iscas.ac.cn (cherry picked from commit 14a2012a490258f3f93857bc4f1b203405964be7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-13drm/panel: novatek-nt37801: Use mipi_dsi_*_multi() functionsNicolás Antinori
Replace mipi_dsi_* functions with their non-deprecated mipi_dsi_*_multi counterparts. This change reduces error-checking boilerplate and improves readability. Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260706224414.1015766-1-nico.antinori.7@gmail.com
2026-07-13drm/virtio: fix deadlock in display_info_cb by removing hotplug from dequeue ↵Ryosuke Yasuoka
worker A probe-time deadlock can occur between the dequeue worker and drm_client_register(). During probe, drm_client_register() holds clientlist_mutex and calls the fbdev hotplug callback, which triggers an atomic commit that ends up sleeping in virtio_gpu_queue_ctrl_sgs() waiting for virtqueue space. The dequeue worker that would free that space calls virtio_gpu_cmd_get_display_info_cb(), which invokes drm_kms_helper_hotplug_event() -> drm_client_dev_hotplug(), attempting to acquire the same clientlist_mutex. Since wake_up() is only called after the resp_cb loop, the probe thread is never woken and both threads deadlock. Fix this by removing the hotplug notification from virtio_gpu_cmd_get_display_info_cb(). The display data (outputs[i].info) is still updated synchronously in the callback. For the init path, drm_client_register() already fires an initial hotplug when the client is registered, which picks up the connector state updated by display_info_cb. For the runtime config_changed path, add a wait_event_timeout() in config_changed_work_func() so that display_info_cb updates the connector data before the hotplug notification is sent. Also replace drm_helper_hpd_irq_event() with drm_kms_helper_hotplug_event() since virtio-gpu never calls drm_kms_helper_poll_init() and thus drm_helper_hpd_irq_event() always returns false without doing anything. Fixes: 27655b9bb9f0 ("drm/client: Send hotplug event after registering a client") Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224 Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e Suggested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260713-virtiogpu_syzbot-v2-1-2958fa37d46d@redhat.com
2026-07-13drm/virtio: Don't detach GEM from a non-created contextJason Macnak
Applies the same treatment as commit 7cf6dd467e87 ("drm/virtio: Don't attach GEM to a non-created context in gem_object_open()") to virtio_gpu_gem_object_close() to avoid trying to detach a resource that was never attached due to a context never being created when context_init is supported. Fixes: 086b9f27f0ab ("drm/virtio: Don't create a context with default param if context_init is supported") Cc: <stable@vger.kernel.org> # v6.14+ Signed-off-by: Jason Macnak <natsu@google.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260625170828.3335431-1-natsu@google.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-16 00:22:03 +0000