summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-01-27drm/amd/display: Add FR skipping CTS functionsJack Chang
1. To check whether Sink reaches maximum skipping number Reviewed-by: Robin Chen <robin.chen@amd.com> Signed-off-by: Jack Chang <jack.chang@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-27drm/amd/display: Fix GFX12 family constant checksMatthew Stewart
Using >=, <= for checking the family is not always correct. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-27drm/amd/display: Enable vstateup hook for DCN401 to be reusedCharlene Liu
Add the hook to the DCN401 header file so that it can be reused in other files Reviewed-by: Leo Chen <leo.chen@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-27drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_removeJon Doron
On APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and ih2 interrupt ring buffers are not initialized. This is by design, as these secondary IH rings are only available on discrete GPUs. See vega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when AMD_IS_APU is set. However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to get the timestamp of the last interrupt entry. When retry faults are enabled on APUs (noretry=0), this function is called from the SVM page fault recovery path, resulting in a NULL pointer dereference when amdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[]. The crash manifests as: BUG: kernel NULL pointer dereference, address: 0000000000000004 RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu] Call Trace: amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu] svm_range_restore_pages+0xae5/0x11c0 [amdgpu] amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu] gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu] amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu] amdgpu_ih_process+0x84/0x100 [amdgpu] This issue was exposed by commit 1446226d32a4 ("drm/amdgpu: Remove GC HW IP 9.3.0 from noretry=1") which changed the default for Renoir APU from noretry=1 to noretry=0, enabling retry fault handling and thus exercising the buggy code path. Fix this by adding a check for ih1.ring_size before attempting to use it. Also restore the soft_ih support from commit dd299441654f ("drm/amdgpu: Rework retry fault removal"). This is needed if the hardware doesn't support secondary HW IH rings. v2: additional updates (Alex) Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3814 Fixes: dd299441654f ("drm/amdgpu: Rework retry fault removal") Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Jon Doron <jond@wiz.io> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-27drm/amd/pm: fix smu v14 soft clock frequency setting issueYang Wang
v1: resolve the issue where some freq frequencies cannot be set correctly due to insufficient floating-point precision. v2: patch this convert on 'max' value only. Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-27drm/amd/pm: fix smu v13 soft clock frequency setting issueYang Wang
v1: resolve the issue where some freq frequencies cannot be set correctly due to insufficient floating-point precision. v2: patch this convert on 'max' value only. Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-27drm/amd/include : Update MES v12 API header - SUSPENDShaoyun Liu
Update SUSPEND API to support sdma queues. It's been supportted since 0x82 for gfx12 Signed-off-by: Shaoyun Liu <shaoyun.liu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-27drm/amdgpu: Simplify sorting of the bo listTvrtko Ursulin
Sort function only cares about the sign so we can replace the conditionals with a single subtraction. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-27drm/amdgpu/mes: Remove idr leftovers v2Tvrtko Ursulin
Commit cb17fff3a254 ("drm/amdgpu/mes: remove unused functions") removed most of the code using these IDRs but forgot to remove the struct members and init/destroy paths. There is also interrupt handling code in SDMA 5.0 and 5.2 which appears to be using it, but is is unreachable since nothing ever allocates the relevant IDR. We replace those with one time warnings just to avoid any functional difference, but it is also possible they should be removed. v2: also fix up gfx_v12_1.c and sdma_v7_1.c Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> References: cb17fff3a254 ("drm/amdgpu/mes: remove unused functions") Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-27drm/xe/vf: Reset VF GuC state on finiMichal Wajdeczko
Unlike native/PF driver, which was explicitly triggering full GuC reset during driver unwind, the VF driver was not notifying GuC that it is about to unwind, and this could lead GuC to access stale data, which in turn could be interpreted as VF's malicious activity. Add managed action to send to GuC VF_RESET message during GT unwind. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260122151924.3726-1-michal.wajdeczko@intel.com
2026-01-27drm/xe: Move _THIS_IP_ usage from xe_vm_create() to dedicated functionNathan Chancellor
After commit a3866ce7b122 ("drm/xe: Add vm to exec queues association"), building for an architecture other than x86 (which defines its own _THIS_IP_) with clang fails with: drivers/gpu/drm/xe/xe_vm.c:1586:3: error: cannot jump from this indirect goto statement to one of its possible targets 1586 | drm_exec_retry_on_contention(&exec); | ^ include/drm/drm_exec.h:123:4: note: expanded from macro 'drm_exec_retry_on_contention' 123 | goto *__drm_exec_retry_ptr; \ | ^ drivers/gpu/drm/xe/xe_vm.c:1542:3: note: possible target of indirect goto statement 1542 | might_lock(&vm->exec_queues.lock); | ^ include/linux/lockdep.h:553:33: note: expanded from macro 'might_lock' 553 | lock_release(&(lock)->dep_map, _THIS_IP_); \ | ^ include/linux/instruction_pointer.h:10:41: note: expanded from macro '_THIS_IP_' 10 | #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; }) | ^ drivers/gpu/drm/xe/xe_vm.c:1583:2: note: jump exits scope of variable with __attribute__((cleanup)) 1583 | xe_validation_guard(&ctx, &xe->val, &exec, (struct xe_val_flags) {.interruptible = true}, | ^ drivers/gpu/drm/xe/xe_validation.h:189:2: note: expanded from macro 'xe_validation_guard' 189 | scoped_guard(xe_validation, _ctx, _val, _exec, _flags, &_ret) \ | ^ include/linux/cleanup.h:442:2: note: expanded from macro 'scoped_guard' 442 | __scoped_guard(_name, __UNIQUE_ID(label), args) | ^ include/linux/cleanup.h:433:20: note: expanded from macro '__scoped_guard' 433 | for (CLASS(_name, scope)(args); \ | ^ drivers/gpu/drm/xe/xe_vm.c:1542:3: note: jump enters a statement expression 1542 | might_lock(&vm->exec_queues.lock); | ^ include/linux/lockdep.h:553:33: note: expanded from macro 'might_lock' 553 | lock_release(&(lock)->dep_map, _THIS_IP_); \ | ^ include/linux/instruction_pointer.h:10:20: note: expanded from macro '_THIS_IP_' 10 | #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; }) | ^ While this is a false positive error because __drm_exec_retry_ptr is only ever assigned the label in drm_exec_until_all_locked() (thus it can never jump over the cleanup variable), this error is not unreasonable in general because the only supported use case for taking the address of a label is computed gotos [1]. The kernel's use of the address of a label in _THIS_IP_ is considered problematic by both GCC [2][3] and clang [4] but they need to provide something equivalent before they can break this use case. Hide the usage of _THIS_IP_ by moving the CONFIG_PROVE_LOCKING if statement to its own function, avoiding the error. This is similar to commit 187e16f69de2 ("drm/xe: Work around clang multiple goto-label error") but with the sources of _THIS_IP_. Fixes: a3866ce7b122 ("drm/xe: Add vm to exec queues association") Link: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html [1] Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 [2] Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071 [3] Link: https://github.com/llvm/llvm-project/issues/138272 [4] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260121-xe-vm-fix-clang-goto-error-v1-1-7e121d81512e@kernel.org
2026-01-27drm/amd/display: Attach OLED property to eDP panelsMario Limonciello (AMD)
amdgpu verifies that a given panel is an OLED panel from extended caps and can provide accurate information to userspace. Attach a property to the DRM connector. Reviewed-by: Leo Li <sunpeng.li@amd.com> Link: https://patch.msgid.link/20260106170017.68158-3-superm1@kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-01-27drm/connector: Add a new 'panel_type' propertyMario Limonciello (AMD)
If the driver can make an assertion whether a connected panel is an OLED panel or not then it can attach a property to the connector that userspace can use as a hint for color schemes. Reviewed-by: Leo Li <sunpeng.li@amd.com> Link: https://patch.msgid.link/20260106170017.68158-2-superm1@kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-01-27drm/xe: Unregister drm device on probe errorShuicheng Lin
Call drm_dev_unregister() when xe_device_probe() fails after successful drm_dev_register(). This ensures the DRM device is promptly unregistered before returning an error, avoiding leaving it registered on the failure path. Otherwise, there is warn message if xe_device_probe() is called again: " [ 207.322365] [drm:drm_minor_register] [ 207.322381] debugfs: '128' already exists in 'dri' [ 207.322432] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/renderD128' [ 207.322435] CPU: 5 UID: 0 PID: 10261 Comm: modprobe Tainted: G B W 6.19.0-rc2-lgci-xe-kernel+ #223 PREEMPT(voluntary) [ 207.322439] Tainted: [B]=BAD_PAGE, [W]=WARN [ 207.322440] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 [ 207.322441] Call Trace: [ 207.322442] <TASK> [ 207.322443] dump_stack_lvl+0xa0/0xc0 [ 207.322446] dump_stack+0x10/0x20 [ 207.322448] sysfs_warn_dup+0xd5/0x110 [ 207.322451] sysfs_create_dir_ns+0x1f6/0x280 [ 207.322453] ? __pfx_sysfs_create_dir_ns+0x10/0x10 [ 207.322455] ? lock_acquire+0x1a4/0x2e0 [ 207.322458] ? __kasan_check_read+0x11/0x20 [ 207.322461] kobject_add_internal+0x28d/0x8e0 [ 207.322464] kobject_add+0x11f/0x1f0 [ 207.322465] ? lock_acquire+0x1a4/0x2e0 [ 207.322467] ? __pfx_kobject_add+0x10/0x10 [ 207.322469] ? __kasan_check_write+0x14/0x20 [ 207.322471] ? kobject_put+0x62/0x4a0 [ 207.322473] ? get_device_parent.isra.0+0x1bb/0x4c0 [ 207.322475] ? kobject_put+0x62/0x4a0 [ 207.322477] device_add+0x2d7/0x1500 [ 207.322479] ? __pfx_device_add+0x10/0x10 [ 207.322481] ? drm_debugfs_add_file+0xfa/0x170 [ 207.322483] ? drm_debugfs_add_files+0x82/0xd0 [ 207.322485] ? drm_debugfs_add_files+0x82/0xd0 [ 207.322487] drm_minor_register+0x10a/0x2d0 [ 207.322489] drm_dev_register+0x143/0x860 [ 207.322491] ? xe_configfs_get_psmi_enabled+0x12/0x90 [xe] [ 207.322667] xe_device_probe+0x185b/0x2c40 [xe] [ 207.322812] ? __pfx___drm_dev_dbg+0x10/0x10 [ 207.322815] ? add_dr+0x180/0x220 [ 207.322818] ? __pfx___drmm_mutex_release+0x10/0x10 [ 207.322821] ? __pfx_xe_device_probe+0x10/0x10 [xe] [ 207.322966] ? xe_pm_init_early+0x33a/0x410 [xe] [ 207.323136] xe_pci_probe+0x936/0x1250 [xe] [ 207.323298] ? lock_acquire+0x1a4/0x2e0 [ 207.323302] ? __pfx_xe_pci_probe+0x10/0x10 [xe] [ 207.323464] local_pci_probe+0xe6/0x1a0 [ 207.323468] pci_device_probe+0x523/0x840 [ 207.323470] ? __pfx_pci_device_probe+0x10/0x10 [ 207.323473] ? sysfs_do_create_link_sd.isra.0+0x8c/0x110 [ 207.323476] ? sysfs_create_link+0x48/0xc0 [ 207.323479] really_probe+0x1fd/0x8a0 ... " Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patch.msgid.link/20260109211041.2446012-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 60bfb8baf8f0d5b0d521744dfd01c880ce1a23f3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-27drm/i915/selftests: Keep mock file open during unfaultable migrate with fillKrzysztof Karas
igt_mmap_migrate() tests migration with various parameters. In one of the cases, where FILL and UNFAULTABLE flags are set, during first stages of this test, a mock file is opened in igt_mmap_offset(), which results in allocating GEM objects for page table structures and scratch in GPU mappable memory. Then, also in igt_mmap_offset(), the file is closed (fput) and the cleanup of these objects is scheduled on a delayed worqueue, which is designed to execute after unspecified amount of time. Next, the test calls igt_fill_mappable() to fill mappable GPU memory. At this point, three scenarios are possible (N = max size of GPU memory for this test in MiB): 1) the objects allocated for the mock file get cleaned up after crucial part of the test is over, so the memory is full with the 1 MiB they occupy and N - 1 MiB added by igt_fill_mappable(), so the migration fails properly; 2) the object cleanup fires before igt_fill_mappable() completes, so the whole memory is populated with N MiB from igt_fill_mappable(), so migration fails as well; 3) the object cleanup is performed right after fill is done, so only N - 1 MiB are in the mappable portion of GPU memory, allowing the migration to succeed - we'd expect no space left to perform migration, but an object was able to fit in the remaining 1 MiB, which caused get_user() to succeed, so a page fault did not fail. The test incorrectly assumes that the GPU mappable memory state is unchanging during the test. Amend this by keeping the mock file open until migration and page fault checking is complete. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13929 Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Acked-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/6xc74s3mbmtliqxihtxbok32jobhc26vfm5mu6cod4ywov6utf@ujp3rmqcwmr3 Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
2026-01-27drm/{i915, xe}/pcode: move display pcode calls to parent interfaceJani Nikula
Call the parent driver pcode functions through the parent interface function pointers instead of expecting both to have functions of the same name. In i915, add the interface to existing intel_pcode.[ch], while in xe move them to new display/xe_display_pcode.[ch] and build it only for CONFIG_DRM_XE_DISPLAY=y. Do not add separate write and write_timeout calls in the interface. Instead, handle the default 1 ms timeout in the intel_parent.c glue layer. This drops the last intel_pcode.h includes from display, and allows us to remove the corresponding xe compat header. v2: initialize .pcode in i915 Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260126112925.2452171-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-27drm/bridge: imx8qxp-pxl2dpi: Fix NULL pointer dereference in ↵Liu Ying
imx8qxp_pxl2dpi_bridge_destroy() Pointer bridge->driver_private in imx8qxp_pxl2dpi_bridge_destroy() is NULL when imx8qxp_pxl2dpi_bridge_probe() returns error, because the pointer is initialized only when imx8qxp_pxl2dpi_bridge_probe() returns 0. The NULL pointer would be set to pointer p2d and then NULL pointer p2d would be dereferenced. Fix this by returning early from imx8qxp_pxl2dpi_bridge_destroy() if !p2d is true. Fixes: 900699ba830f ("drm/bridge: imx8qxp-pxl2dpi: get/put the companion bridge") Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260123-imx8qxp-drm-bridge-fixes-v1-2-8bb85ada5866@nxp.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-27drm/bridge: imx8qxp-ldb: Fix NULL pointer dereference in ↵Liu Ying
imx8qxp_ldb_bridge_destroy() Pointer bridge->driver_private in imx8qxp_ldb_bridge_destroy() is NULL when a LDB channel is unavailable or imx8qxp_ldb_probe() returns error, because ldb_add_bridge_helper() is the last function called from imx8qxp_ldb_probe() and it doesn't initialize bridge->driver_private if a LDB channel is unavailable. The NULL pointer would be set to pointer ldb_ch and then NULL pointer ldb_ch would be dereferenced. Fix this by returning early from imx8qxp_ldb_bridge_destroy() if !ldb_ch is true. Fixes: 32529d384cea ("drm/bridge: imx8qxp-ldb: convert to of_drm_find_and_get_bridge()") Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260123-imx8qxp-drm-bridge-fixes-v1-1-8bb85ada5866@nxp.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-27drm/rcar-du: dsi: Clean up VCLK divider calculationMarek Vasut
Currently, in rcar_mipi_dsi_parameters_calc(), the VCLK divider is stored in setup_info structure as BIT(divider). The rcar_mipi_dsi_parameters_calc() is called at the early beginning of rcar_mipi_dsi_startup() function. Later, in the same rcar_mipi_dsi_startup() function, the stored BIT(divider) value is passed to __ffs() to calculate back the divider out of the value again. Factor out VCLK divider calculation into rcar_mipi_dsi_vclk_divider() function and call the function from both rcar_mipi_dsi_parameters_calc() and rcar_mipi_dsi_startup() to avoid this back and forth BIT() and _ffs() and avoid unnecessarily storing the divider value in setup_info at all. This rework has a slight side-effect, in that it should allow the compiler to better evaluate the code and avoid compiler warnings about variable value overflows, which can never happen. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512051834.bESvhDiG-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202512222321.TeY4VbvK-lkp@intel.com/ Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260105175250.64309-1-marek.vasut+renesas@mailbox.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-01-27dma-buf: Always build with DMABUF_MOVE_NOTIFYLeon Romanovsky
DMABUF_MOVE_NOTIFY was introduced in 2018 and has been marked as experimental and disabled by default ever since. Six years later, all new importers implement this callback. It is therefore reasonable to drop CONFIG_DMABUF_MOVE_NOTIFY and always build DMABUF with support for it enabled. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20260124-dmabuf-revoke-v5-3-f98fca917e96@nvidia.com Signed-off-by: Christian König <christian.koenig@amd.com>
2026-01-27dma-buf: Rename dma_buf_move_notify() to dma_buf_invalidate_mappings()Leon Romanovsky
Along with renaming the .move_notify() callback, rename the corresponding dma-buf core function. This makes the expected behavior clear to exporters calling this function. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20260124-dmabuf-revoke-v5-2-f98fca917e96@nvidia.com Signed-off-by: Christian König <christian.koenig@amd.com>
2026-01-27dma-buf: Rename .move_notify() callback to a clearer identifierLeon Romanovsky
Rename the .move_notify() callback to .invalidate_mappings() to make its purpose explicit and highlight that it is responsible for invalidating existing mappings. Suggested-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20260124-dmabuf-revoke-v5-1-f98fca917e96@nvidia.com Signed-off-by: Christian König <christian.koenig@amd.com>
2026-01-27drm/i915/display: Disable DMG Clock GatingSuraj Kandpal
Incorrect clock is connected to DMG registers. Disable DMG Clock gating during display initialization. WA: 22021451799 Bspec: 69095 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Link: https://patch.msgid.link/20260122031818.703590-1-suraj.kandpal@intel.com
2026-01-26mm/zone_device: reinitialize large zone device private foliosMatthew Brost
Reinitialize metadata for large zone device private folios in zone_device_page_init prior to creating a higher-order zone device private folio. This step is necessary when the folio's order changes dynamically between zone_device_page_init calls to avoid building a corrupt folio. As part of the metadata reinitialization, the dev_pagemap must be passed in from the caller because the pgmap stored in the folio page may have been overwritten with a compound head. Without this fix, individual pages could have invalid pgmap fields and flags (with PG_locked being notably problematic) due to prior different order allocations, which can, and will, result in kernel crashes. Link: https://lkml.kernel.org/r/20260116111325.1736137-2-francois.dugast@intel.com Fixes: d245f9b4ab80 ("mm/zone_device: support large zone device private folios") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Acked-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Balbir Singh <balbirs@nvidia.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Zi Yan <ziy@nvidia.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Lyude Paul <lyude@redhat.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: David Hildenbrand <david@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Liam R. Howlett <Liam.Howlett@oracle.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Michal Hocko <mhocko@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-27drm/i915/cx0: Rename intel_clear_response_ready flagSuraj Kandpal
Rename the non static intel_clear_response_ready_flag to intel_cx0_clear_response_ready_flag so that we follow the naming standards of non static function. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Link: https://patch.msgid.link/20260122044859.753682-2-suraj.kandpal@intel.com
2026-01-27drm/i915/cx0: Clear response ready & error bitSuraj Kandpal
Clear the response ready and error bit of PORT_P2M_MESSAGE_BUS_STATUS before writing the transaction pending bit of PORT_M2P_MSGBUS_CTL as that is a hard requirement. If not done we find that the PHY hangs since it ends up in a weird state if left idle for more than 1 hour. Bspec: 65101 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260122044859.753682-1-suraj.kandpal@intel.com
2026-01-27Merge tag 'amd-drm-next-6.20-2026-01-23' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.20-2026-01-23: amdgpu: - GC 12 fix - UserQ fixes - Misc error path fixes - IP discovery fixes - Misc cleanups - HDMI fixes - Documentation update - Panel replay fixes - Panel type handling fixes - DCN 3.1.x fixes - DC analog display fix - SMU 6 fixes - VCN 4.0.3 queue reset fix - VCN 5.0.1 queue reset fix - GPUVM TLB flush fix - RAS fixes - DC idle optimization fix amdkfd: - MQD fix for GC 9.4.3 and 9.5 - GC 11 cooperative launch fix - GC 12.1 trap handler fixes - Misc cleanups radeon: - Use drm_* logging helpers for VCE Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260123173537.17221-1-alexander.deucher@amd.com
2026-01-26drm/xe: Unregister drm device on probe errorShuicheng Lin
Call drm_dev_unregister() when xe_device_probe() fails after successful drm_dev_register(). This ensures the DRM device is promptly unregistered before returning an error, avoiding leaving it registered on the failure path. Otherwise, there is warn message if xe_device_probe() is called again: " [ 207.322365] [drm:drm_minor_register] [ 207.322381] debugfs: '128' already exists in 'dri' [ 207.322432] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/renderD128' [ 207.322435] CPU: 5 UID: 0 PID: 10261 Comm: modprobe Tainted: G B W 6.19.0-rc2-lgci-xe-kernel+ #223 PREEMPT(voluntary) [ 207.322439] Tainted: [B]=BAD_PAGE, [W]=WARN [ 207.322440] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 [ 207.322441] Call Trace: [ 207.322442] <TASK> [ 207.322443] dump_stack_lvl+0xa0/0xc0 [ 207.322446] dump_stack+0x10/0x20 [ 207.322448] sysfs_warn_dup+0xd5/0x110 [ 207.322451] sysfs_create_dir_ns+0x1f6/0x280 [ 207.322453] ? __pfx_sysfs_create_dir_ns+0x10/0x10 [ 207.322455] ? lock_acquire+0x1a4/0x2e0 [ 207.322458] ? __kasan_check_read+0x11/0x20 [ 207.322461] kobject_add_internal+0x28d/0x8e0 [ 207.322464] kobject_add+0x11f/0x1f0 [ 207.322465] ? lock_acquire+0x1a4/0x2e0 [ 207.322467] ? __pfx_kobject_add+0x10/0x10 [ 207.322469] ? __kasan_check_write+0x14/0x20 [ 207.322471] ? kobject_put+0x62/0x4a0 [ 207.322473] ? get_device_parent.isra.0+0x1bb/0x4c0 [ 207.322475] ? kobject_put+0x62/0x4a0 [ 207.322477] device_add+0x2d7/0x1500 [ 207.322479] ? __pfx_device_add+0x10/0x10 [ 207.322481] ? drm_debugfs_add_file+0xfa/0x170 [ 207.322483] ? drm_debugfs_add_files+0x82/0xd0 [ 207.322485] ? drm_debugfs_add_files+0x82/0xd0 [ 207.322487] drm_minor_register+0x10a/0x2d0 [ 207.322489] drm_dev_register+0x143/0x860 [ 207.322491] ? xe_configfs_get_psmi_enabled+0x12/0x90 [xe] [ 207.322667] xe_device_probe+0x185b/0x2c40 [xe] [ 207.322812] ? __pfx___drm_dev_dbg+0x10/0x10 [ 207.322815] ? add_dr+0x180/0x220 [ 207.322818] ? __pfx___drmm_mutex_release+0x10/0x10 [ 207.322821] ? __pfx_xe_device_probe+0x10/0x10 [xe] [ 207.322966] ? xe_pm_init_early+0x33a/0x410 [xe] [ 207.323136] xe_pci_probe+0x936/0x1250 [xe] [ 207.323298] ? lock_acquire+0x1a4/0x2e0 [ 207.323302] ? __pfx_xe_pci_probe+0x10/0x10 [xe] [ 207.323464] local_pci_probe+0xe6/0x1a0 [ 207.323468] pci_device_probe+0x523/0x840 [ 207.323470] ? __pfx_pci_device_probe+0x10/0x10 [ 207.323473] ? sysfs_do_create_link_sd.isra.0+0x8c/0x110 [ 207.323476] ? sysfs_create_link+0x48/0xc0 [ 207.323479] really_probe+0x1fd/0x8a0 ... " Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patch.msgid.link/20260109211041.2446012-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-01-26drm/xe/ptl: Disable DCC on PTLVinay Belgaumkar
On PTL, the recommendation is to disable DCC(Duty Cycle Control) as it may cause some regressions due to added latencies. Upcoming GuC releases will disable DCC on PTL as well, but we need to force it in KMD so that this behavior is propagated to older kernels. v2: Update commit message (Rodrigo) v3: Rebase v4: Fix typo: s/propagted/propagated Fixes: 5cdb71d3b0db ("drm/xe/ptl: Add GuC FW definition for PTL") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patch.msgid.link/20260124005917.398522-1-vinay.belgaumkar@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 40ee63f5df2d5c6471b583df800aac89dc0502a4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-26drm/xe: Reduce LRC timestamp stuck message on VFs to noticeMatthew Brost
An LRC timestamp getting stuck is a somewhat normal occurrence. If a single VF submits a job that does not get timesliced, the LRC timestamp will not increment. Reduce the LRC timestamp stuck message on VFs to notice (same log level as job timeout) to avoid false CI bugs in tests where a VF submits a job that does not get timesliced. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7032 Fixes: bb63e7257e63 ("drm/xe: Avoid toggling schedule state to check LRC timestamp in TDR") Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20260114184905.4189026-1-matthew.brost@intel.com (cherry picked from commit e89aacd1ecdd3d13e8f347aa082687878621e03c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-26drm/xe/ptl: Disable DCC on PTLVinay Belgaumkar
On PTL, the recommendation is to disable DCC(Duty Cycle Control) as it may cause some regressions due to added latencies. Upcoming GuC releases will disable DCC on PTL as well, but we need to force it in KMD so that this behavior is propagated to older kernels. v2: Update commit message (Rodrigo) v3: Rebase v4: Fix typo: s/propagted/propagated Fixes: 5cdb71d3b0db ("drm/xe/ptl: Add GuC FW definition for PTL") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patch.msgid.link/20260124005917.398522-1-vinay.belgaumkar@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-26drm/display: bridge_connector: move audio_infoframe checks to OP_HDMIDmitry Baryshkov
There are DRM_BRIDGE_OP_HDMI_AUDIO bridges (e.g. Lontium LT9611UXC) which don't implement DRM_BRIDGE_OP_HDMI and don't implement hdmi_clear_audio_infoframe / hdmi_write_audio_infoframe callbacks. Move corresponding checks under the DRM_BRIDGE_OP_HDMI condition, making sure that we require those callbacks only from the bridges which are actually going to use them. Fixes: b626b1a1c9cc ("drm/bridge: refactor HDMI InfoFrame callbacks") Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260126-drm-fix-lt9611uxc-v1-1-04a635a8f5cf@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-26gpu: tyr: remove redundant `.as_ref()` for `dev_*` printGary Guo
This is now handled by the macro itself. Acked-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260120181152.3640314-4-gary@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-26drm/xe: derive mem copy capability from graphics versionNitin Gote
Drop .has_mem_copy_instr from the platform descriptors and set it in xe_info_init() after handle_gmdid() populates graphics_verx100. Centralizing the GRAPHICS_VER(xe) >= 20 check keeps MEM_COPY enabled on Xe2+ and removes redundant per-platform plumbing. Bspec: 57561 Fixes: 1e12dbae9d72 ("drm/xe/migrate: support MEM_COPY instruction") Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20260120054724.1982608-2-nitin.r.gote@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit 6ef02656c3222b1e12032a40d644ed56806b14fc) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-26drm/xe/xelp: Fix Wa_18022495364Tvrtko Ursulin
It looks I mistyped CS_DEBUG_MODE2 as CS_DEBUG_MODE1 when adding the workaround. Fix it. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: ca33cd271ef9 ("drm/xe/xelp: Add Wa_18022495364") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260116095040.49335-1-tvrtko.ursulin@igalia.com (cherry picked from commit 7fe6cae2f7fad2b5166b0fc096618629f9e2ebcb) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-26drm/xe: Skip address copy for sync-only execsShuicheng Lin
For parallel exec queues, xe_exec_ioctl() copied the batch buffer address array from userspace without checking num_batch_buffer. If user creates a sync-only exec that doesn't use the address field, the exec will fail with -EFAULT. Add num_batch_buffer check to skip the copy, and the exec could be executed successfully. Here is the sync-only exec: struct drm_xe_exec exec = { .extensions = 0, .exec_queue_id = qid, .num_syncs = 1, .syncs = (uintptr_t)&sync, .address = 0, /* ignored for sync-only */ .num_batch_buffer = 0, /* sync-only */ }; Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260122214053.3189366-2-shuicheng.lin@intel.com (cherry picked from commit 4761791c1e736273d612ff564f318bfbbb04fa4e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-26drm/xe/xelp: Fix Wa_18022495364Tvrtko Ursulin
It looks I mistyped CS_DEBUG_MODE2 as CS_DEBUG_MODE1 when adding the workaround. Fix it. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: ca33cd271ef9 ("drm/xe/xelp: Add Wa_18022495364") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260116095040.49335-1-tvrtko.ursulin@igalia.com
2026-01-26drm/panel: ilitek-ili9882t: Select DRM_DISPLAY_DSC_HELPERMaíra Canal
The panel-ilitek-ili9882t driver uses drm_dsc_pps_payload_pack() which is provided by the DRM_DISPLAY_DSC_HELPER. Add the missing Kconfig select to fix the following build error: ERROR: modpost: "drm_dsc_pps_payload_pack" [drivers/gpu/drm/panel/panel-ilitek-ili9882t.ko] undefined! Fixes: 65ce1f5834e9 ("drm/panel: ilitek-ili9882t: Switch Tianma TL121BVMS07 to DSC 120Hz mode") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20260115125136.64866-1-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-01-26Merge tag 'v6.19-rc7' into driver-core-nextDanilo Krummrich
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-26drm: Do not allow userspace to trigger kernel warnings in ↵Tvrtko Ursulin
drm_gem_change_handle_ioctl() Since GEM bo handles are u32 in the uapi and the internal implementation uses idr_alloc() which uses int ranges, passing a new handle larger than INT_MAX trivially triggers a kernel warning: idr_alloc(): ... if (WARN_ON_ONCE(start < 0)) return -EINVAL; ... Fix it by rejecting new handles above INT_MAX and at the same time make the end limit calculation more obvious by moving into int domain. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reported-by: Zhi Wang <wangzhi@stu.xidian.edu.cn> Fixes: 53096728b891 ("drm: Add DRM prime interface to reassign GEM handle") Cc: David Francis <David.Francis@amd.com> Cc: Felix Kuehling <felix.kuehling@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> # v6.18+ Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260123141540.76540-1-tvrtko.ursulin@igalia.com
2026-01-26drm/{i915, xe}/dsb: move DSB buffer to parent interfaceJani Nikula
Move the DSB buffer handling to the display parent interface, making display more independent of i915 and xe driver implementations. Since the DSB parent interface is only called from intel_dsb.c, add the wrappers there with smaller visibility instead of the usual intel_parent.[ch], and using struct intel_dsb as the context parameter for convenience. Unfortunately, memset() being a macro in linux/fortify-string.h, we can't use that as the function pointer name. dsb->memset() would be using the macro and leading to build failures. Therefore, use .fill() for the memset() functionality. v2: s/memset/fill/ Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/df117c862a6d34dae340e4a85c2482b4e29c8884.1768923917.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-26drm/i915/dsb: move i915 specific DSB buffer implementation to i915Jani Nikula
The DSB buffer implementation is different for both i915 and xe. Move the i915 specific implementation from display to i915 core. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/a01b3e69a3f79713eacf437af00dbe23d2f9c8dd.1768923917.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-26drm/i915/display: Prevent u64 underflow in intel_fbc_stolen_endJonathan Cavitt
Static analysis reveals a potential integer underflow in intel_fbc_stolen_end. This can apparently occur if intel_parent_stolen_area_size returns zero (or, theoretically, any value less than 2^23), as 2^23 is subtracted from the return value and stored in a u64. While this doesn't appear to cause any issues due to the use of the min() function to clamp the return values from the intel_fbc_stolen_end function, it would be best practice to avoid undeflowing values like this on principle. So, rework the function to prevent the underflow from occurring. Note that the underflow at present would result in the value of intel_fbc_cfb_base_max being returned at the end of intel_fbc_stolen_end, so just return that if the value of intel_parent_stolen_area_size is too small. While we're here, fix the other comments here and modify the execution path for readability. v2: (Jani) - Fix the comments in intel_fbc_stolen_end - Use check_sub_overflow - Remove macro that mirrors SZ_8M, as it is now only referenced once - Misc. formatting fixes Fixes: a9da512b3ed7 ("drm/i915: avoid the last 8mb of stolen on BDW/SKL") Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260107162935.8123-2-jonathan.cavitt@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 6695dc279820a50cb20ecd8b5250e05234dac780) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-01-26gpu: nova-core: gsp: use () as message type for GspInitDone messageAlexandre Courbot
`GspInitDone` has no payload whatsoever, so the unit type `()` is the correct way to represent its message content. We can use it now that `()` implements `FromBytes`. Reviewed-by: Alistair Popple <apopple@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20251215-transmute_unit-v4-2-477d71ec7c23@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-26drm/tyr: depend on `COMMON_CLK` to fix build errorMiguel Ojeda
Tyr needs `CONFIG_COMMON_CLK` to build: error[E0432]: unresolved import `kernel::clk::Clk` --> drivers/gpu/drm/tyr/driver.rs:3:5 | 3 | use kernel::clk::Clk; | ^^^^^^^^^^^^^^^^ no `Clk` in `clk` error[E0432]: unresolved import `kernel::clk::OptionalClk` --> drivers/gpu/drm/tyr/driver.rs:4:5 | 4 | use kernel::clk::OptionalClk; | ^^^^^^^^^^^^^^^^^^^^^^^^ no `OptionalClk` in `clk` Thus add the dependency to fix it. Fixes: cf4fd52e3236 ("rust: drm: Introduce the Tyr driver for Arm Mali GPUs") Cc: stable@vger.kernel.org Acked-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260124160948.67508-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-24gpu: nova-core: align LibosMemoryRegionInitArgument size to page sizeAlexandre Courbot
On Turing and GA100 (i.e. the versions that use Libos v2), GSP-RM insists that the 'size' parameter of the LibosMemoryRegionInitArgument struct be aligned to 4KB. The logging buffers are already aligned to that size, so only the GSP_ARGUMENTS_CACHED struct needs to be adjusted. Make that adjustment by adding padding to the end of the struct. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260122222848.2555890-12-ttabi@nvidia.com [acourbot@nvidia.com: GspArgumentsAligned -> GspArgumentsPadded] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-01-24gpu: nova-core: add FalconUCodeDescV2 supportTimur Tabi
The FRTS firmware in Turing and GA100 VBIOS has an older header format (v2 instead of v3). To support both v2 and v3 at runtime, add the FalconUCodeDescV2 struct, and update code that references the FalconUCodeDescV3 directly with a FalconUCodeDesc enum that encapsulates both. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260122222848.2555890-11-ttabi@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-01-24gpu: nova-core: add Falcon HAL method load_method()Timur Tabi
Some GPUs do not support using DMA to transfer code/data from system memory to Falcon memory, and instead must use programmed I/O (PIO). Add a function to the Falcon HAL to indicate whether a given GPU's Falcons support DMA for this purpose. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260122222848.2555890-10-ttabi@nvidia.com [acourbot@nvidia.com: add short code to call into the HAL.] [acourbot@nvidia.com: make `dma_load` private as per feedback.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-01-23drm/msm/a6xx: fix bogus hwcg register updatesJohan Hovold
The hw clock gating register sequence consists of register value pairs that are written to the GPU during initialisation. The a690 hwcg sequence has two GMU registers in it that used to amount to random writes in the GPU mapping, but since commit 188db3d7fe66 ("drm/msm/a6xx: Rebase GMU register offsets") they trigger a fault as the updated offsets now lie outside the mapping. This in turn breaks boot of machines like the Lenovo ThinkPad X13s. Note that the updates of these GMU registers is already taken care of properly since commit 40c297eb245b ("drm/msm/a6xx: Set GMU CGC properties on a6xx too"), but for some reason these two entries were left in the table. Fixes: 5e7665b5e484 ("drm/msm/adreno: Add Adreno A690 support") Cc: stable@vger.kernel.org # 6.5 Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konradybcio@kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Fixes: 188db3d7fe66 ("drm/msm/a6xx: Rebase GMU register offsets") Patchwork: https://patchwork.freedesktop.org/patch/695778/ Message-ID: <20251221164552.19990-1-johan@kernel.org> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> (cherry picked from commit dcbd2f8280eea2c965453ed8c3c69d6f121e950b)
2026-01-23drm/xe: Skip address copy for sync-only execsShuicheng Lin
For parallel exec queues, xe_exec_ioctl() copied the batch buffer address array from userspace without checking num_batch_buffer. If user creates a sync-only exec that doesn't use the address field, the exec will fail with -EFAULT. Add num_batch_buffer check to skip the copy, and the exec could be executed successfully. Here is the sync-only exec: struct drm_xe_exec exec = { .extensions = 0, .exec_queue_id = qid, .num_syncs = 1, .syncs = (uintptr_t)&sync, .address = 0, /* ignored for sync-only */ .num_batch_buffer = 0, /* sync-only */ }; Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260122214053.3189366-2-shuicheng.lin@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-12 16:11:01 +0000