summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-01-15drm/msm: Fix x2-85 TPL1_DBG_ECO_CNTL1Rob Clark
We actually need to set b26, just claiming to do so is not enough :-) Fixes: 01ff3bf27215 ("drm/msm/a8xx: Add support for Adreno X2-85 GPU") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/697778/ Message-ID: <20260109153730.130462-2-robin.clark@oss.qualcomm.com>
2026-01-15drm/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>
2026-01-15drm/xe/xe_query: Remove check for gtNakshtra Goyal
There's no need to check a userspace-provided GT ID (which may come from any tile) against the number of GTs that can be present on a single tile. The xe_device_get_gt() lookup already checks that the GT ID passed is valid for the current device.(Matt Roper) Signed-off-by: Nakshtra Goyal <nakshtra.goyal@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260113091928.67446-1-nakshtra.goyal@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-01-15drm/i915/dp: Use intel_dp_dsc_get_slice_config()Imre Deak
Simplify things by computing the detailed slice configuration using intel_dp_dsc_get_slice_config(), instead of open-coding the same. While at it add a TODO comment to intel_dp_dsc_compute_config() to explore if it's worth increasing the number of VDSC stream engines used, in order to reduce the minimum CDCLK required. v2: Add a TODO comment to intel_dp_dsc_compute_config() to explore if it's worth increasing the number of slices in order to use a lower CDCLK. (Jouni) Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-16-imre.deak@intel.com
2026-01-15drm/i915/dp: Add intel_dp_dsc_get_slice_config()Imre Deak
Add intel_dp_dsc_get_slice_config() to compute the detailed slice configuration and determine the slices-per-line value (returned by intel_dp_dsc_get_slice_count()) using this function. v2: Fix incorrectly returning false from intel_dp_dsc_min_slice_count() due to rebase fail. (Jouni) Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-15-imre.deak@intel.com
2026-01-15drm/i915/dp: Unify DP and eDP slice count computationImre Deak
Unify the DP and eDP slices-per-line computation. Atm eDP simply returns the maximum slices-per-line value supported by the sink, but using the same helper function for both cases still makes sense, since a follow-up change will compute the detailed slice config for both cases. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-14-imre.deak@intel.com
2026-01-15drm/i915/dsi: Use intel_dsc_get_slice_config()Imre Deak
Use intel_dsc_get_slice_config() for DSI to compute the slice configuration based on the slices-per-line sink capability, instead of open-coding the same. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-13-imre.deak@intel.com
2026-01-15drm/i915/dsc: Add intel_dsc_get_slice_config()Imre Deak
Add intel_dsc_get_slice_config() and move the logic to select a given slice configuration to that function from the configuration loop in intel_dp_dsc_get_slice_count(). The same functionality can be used by other outputs like DSI as well, done as a follow-up. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-12-imre.deak@intel.com
2026-01-15drm/i915/dp: Simplify the DSC slice config loop's slices-per-pipe iterationImre Deak
Simplify the slice config loop in intel_dp_dsc_get_slice_count(), using the loop iterator as the slices-per-pipe value directly, instead of looking up the same value from an array. While at it move the code comment about the slice configuration closer to where the configuration is determined and clarify it a bit. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-11-imre.deak@intel.com
2026-01-15drm/i915/dp: Rename test_slice_count to slices_per_lineImre Deak
Rename test_slice_count to slices_per_line for clarity. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-10-imre.deak@intel.com
2026-01-15drm/i915/dp: Use int for DSC slice count variablesImre Deak
There is no reason to use the more specific u8 type for slice count variables, use the more generic int type instead. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-9-imre.deak@intel.com
2026-01-15drm/i915/dp: Factor out intel_dp_dsc_min_slice_count()Imre Deak
Factor out intel_dp_dsc_min_slice_count() for making intel_dp_dsc_get_slice_count() more readable and also to prepare for a follow-up change unifying the eDP and DP slice count/config computation. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-8-imre.deak@intel.com
2026-01-15drm/i915/dsc: Switch to using intel_dsc_line_slice_count()Imre Deak
By now all the places are updated to track the DSC slice configuration in intel_crtc_state::dsc.slice_config, so calculate the slices-per-line value using that config, instead of using intel_crtc_state::dsc.slice_count caching the same value and remove the cached slice_count. v2: Rebase on latest drm-tip, converting another user of dsc.slice_count in intel_vdsc_min_cdclk(). Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> # v1 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-7-imre.deak@intel.com
2026-01-15drm/i915/dp: Track the detailed DSC slice configurationImre Deak
Add tracking for the DP DSC pipes-per-line and slices-per-stream value in the slice config state and compute the current slices-per-line (slice_count) value using this slice config. The slices-per-line value used atm will be removed by a follow-up change after converting all the places using it to use the slice config instead. For now the slices-per-stream value is calculated based on the slices-per-line value (slice_count) calculated by the drm_dp_dsc_sink_max_slice_count() / intel_dp_dsc_get_slice_count() functions. In a follow-up change these functions will be converted to calculate the slices-per-stream value directly, along with the detailed slice configuration. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-6-imre.deak@intel.com
2026-01-15drm/i915/dsi: Track the detailed DSC slice configurationImre Deak
Add tracking for the DSI DSC pipes-per-line and slices-per-stream value in the slice config state and compute the current slices-per-line value using this slice config state. The slices-per-line value used atm will be removed by a follow-up change after converting all the places using it to use the detailed slice config instead. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-5-imre.deak@intel.com
2026-01-15drm/i915/dsi: Move initialization of DSI DSC streams-per-pipe to fill_dsc()Imre Deak
Move the initialization of the DSI DSC streams-per-pipe value to fill_dsc() next to where the corresponding (per-line) slice_count value is initialized. This allows converting the initialization to use the detailed slice configuration state in follow-up changes. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-4-imre.deak@intel.com
2026-01-15drm/i915/dsc: Track the DSC stream count in the DSC slice config stateImre Deak
Move the tracking for the DSC stream count from intel_crtc_state::dsc.num_streams to intel_crtc_state::dsc.slice_config.streams_per_pipe. While at it add a TODO comment to read out the full DSC configuration from HW including the pipes-per-line and slices-per-stream values. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-3-imre.deak@intel.com
2026-01-15drm/i915/dsc: Track the detaild DSC slice configurationImre Deak
Add a way to track the detailed DSC pipes-per-line, streams-per-pipe, slices-per-stream configuration instead of the current streams-per-pipe and slices-per-line value. This way describes the slice configuration in a clearer way, for instance providing a 2 pipes-per-line x 2 streams-per-pipe x 2 slices-per-stream = 8 slices-per-line view, instead of the current, coarser 2 streams-per-pipe, 8 slices-per-line view, the former better reflecting that each DSC stream engine has 2 slices. This also let's optimizing the configuration in a simpler/clearer way, for instance using 1 stream x 2 slices, or 1 stream x 4 slices instead of the current 2 stream x 1 slice, or 2 streams x 2 slices configuration (so that 1 DSC stream engine can be powered off in each pipe). Follow-up changes will convert the current slices-per-line computation logic to compute instead the above detailed slice configuration. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260114162232.92731-2-imre.deak@intel.com
2026-01-15drm/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
2026-01-15drm/xe: Cleanup unused header includesMatt Roper
clangd reports many "unused header" warnings throughout the Xe driver. Start working to clean this up by removing unnecessary includes in our .c files and/or replacing them with explicit includes of other headers that were previously being included indirectly. By far the most common offender here was unnecessary inclusion of xe_gt.h. That likely originates from the early days of xe.ko when xe_mmio did not exist and all register accesses, including those unrelated to GTs, were done with GT functions. There's still a lot of additional #include cleanup that can be done in the headers themselves; that will come as a followup series. v2: - Squash the 79-patch series down to a single patch. (MattB) Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260115032803.4067824-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-01-15Merge tag 'amd-drm-next-6.20-2026-01-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.20-2026-01-09: amdgpu: - GPUVM updates - Initial support for larger GPU address spaces - Initial SMUIO 15.x support - Documentation updates - Initial PSP 15.x support - Initial IH 7.1 support - Initial IH 6.1.1 support - SMU 13.0.12 updates - RAS updates - Initial MMHUB 3.4 support - Initial MMHUB 4.2 support - Initial GC 12.1 support - Initial GC 11.5.4 support - HDMI fixes - Panel replay improvements - DML updates - DC FP fixes - Initial SDMA 6.1.4 support - Initial SDMA 7.1 support - Userq updates - DC HPD refactor - SwSMU cleanups and refactoring - TTM memory ops parallelization - DCN 3.5 fixes - DP audio fixes - Clang fixes - Misc spelling fixes and cleanups - Initial SDMA 7.11.4 support - Convert legacy DRM logging helpers to new drm logging helpers - Initial JPEG 5.3 support - Add support for changing UMA size via the driver - DC analog fixes - GC 9 gfx queue reset support - Initial SMU 15.x support amdkfd: - Reserved SDMA rework - Refactor SPM - Initial GC 12.1 support - Initial GC 11.5.4 support - Initial SDMA 7.1 support - Initial SDMA 6.1.4 support - Increase the kfd process hash table - Per context support - Topology fixes radeon: - Convert legacy DRM logging helpers to new drm logging helpers - Use devm for i2c adapters - Variable sized array fix - Misc cleanups UAPI: - KFD context support. Proposed userspace: https://github.com/ROCm/rocm-systems/pull/1705 https://github.com/ROCm/rocm-systems/pull/1701 - Add userq metadata queries for more queue types. Proposed userspace: https://gitlab.freedesktop.org/yogeshmohan/mesa/-/commits/userq_query From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260109154713.3242957-1-alexander.deucher@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-01-14drm/amd/display: Add an hdmi_hpd_debounce_delay_ms moduleIvan Lipski
[Why&How] Right now, the HDMI HPD filter is enabled by default at 1500ms. We want to disable it by default, as most modern displays with HDMI do not require it for DPMS mode. The HPD can instead be enabled as a driver parameter with a custom delay value in ms (up to 5000ms). Fixes: c918e75e1ed9 ("drm/amd/display: Add an HPD filter for HDMI") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4859 Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6a681cd9034587fe3550868bacfbd639d1c6891f)
2026-01-14drm/amdgpu/userq: Fix fence reference leak on queue teardown v2Srinivasan Shanmugam
The user mode queue keeps a pointer to the most recent fence in userq->last_fence. This pointer holds an extra dma_fence reference. When the queue is destroyed, we free the fence driver and its xarray, but we forgot to drop the last_fence reference. Because of the missing dma_fence_put(), the last fence object can stay alive when the driver unloads. This leaves an allocated object in the amdgpu_userq_fence slab cache and triggers This is visible during driver unload as: BUG amdgpu_userq_fence: Objects remaining on __kmem_cache_shutdown() kmem_cache_destroy amdgpu_userq_fence: Slab cache still has objects Call Trace: kmem_cache_destroy amdgpu_userq_fence_slab_fini amdgpu_exit __do_sys_delete_module Fix this by putting userq->last_fence and clearing the pointer during amdgpu_userq_fence_driver_free(). This makes sure the fence reference is released and the slab cache is empty when the module exits. v2: Update to only release userq->last_fence with dma_fence_put() (Christian) Fixes: edc762a51c71 ("drm/amdgpu/userq: move some code around") Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8e051e38a8d45caf6a866d4ff842105b577953bb)
2026-01-14drm/amdkfd: No need to suspend whole MES to evict processHarish Kasiviswanathan
Each queue of the process is individually removed and there is not need to suspend whole mes. Suspending mes stops kernel mode queues also causing unnecessary timeouts when running mixed work loads Fixes: 079ae5118e1f ("drm/amdkfd: fix suspend/resume all calls in mes based eviction path") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4765 Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3fd20580b96a6e9da65b94ac3b58ee288239b731)
2026-01-14Revert "drm/amdgpu: don't attach the tlb fence for SI"Prike Liang
This reverts commit 820b3d376e8a102c6aeab737ec6edebbbb710e04. It’s better to validate VM TLB flushes in the flush‑TLB backend rather than in the generic VM layer. Reverting this patch depends on commit fa7c231fc2b0 ("drm/amdgpu: validate the flush_gpu_tlb_pasid()") being present in the tree. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9163fe4d790fb4e16d6b0e23f55b43cddd3d4a65)
2026-01-14drm/amdgpu: validate the flush_gpu_tlb_pasid()Prike Liang
Validate flush_gpu_tlb_pasid() availability before flushing tlb. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f4db9913e4d3dabe9ff3ea6178f2c1bc286012b8)
2026-01-14drm/amd/pm: fix smu overdrive data type wrong issue on smu 14.0.2Yang Wang
resolving the issue of incorrect type definitions potentially causing calculation errors. Fixes: 54f7f3ca982a ("drm/amdgpu/swm14: Update power limit logic") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e3a03d0ae16d6b56e893cce8e52b44140e1ed985)
2026-01-14drm/amd/display: Initialise backlight level values from hwVivek Das Mohapatra
Internal backlight levels are initialised from ACPI but the values are sometimes out of sync with the levels in effect until there has been a read from hardware (eg triggered by reading from sysfs). This means that the first drm_commit can cause the levels to be set to a different value than the actual starting one, which results in a sudden change in brightness. This path shows the problem (when the values are out of sync): amdgpu_dm_atomic_commit_tail() -> amdgpu_dm_commit_streams() -> amdgpu_dm_backlight_set_level(..., dm->brightness[n]) This patch calls the backlight ops get_brightness explicitly at the end of backlight registration to make sure dm->brightness[n] is in sync with the actual hardware levels. Fixes: 2fe87f54abdc ("drm/amd/display: Set default brightness according to ACPI") Signed-off-by: Vivek Das Mohapatra <vivek@collabora.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 318b1c36d82a0cd2b06a4bb43272fa6f1bc8adc1) Cc: stable@vger.kernel.org
2026-01-14drm/amd/display: Bump the HDMI clock to 340MHzMario Limonciello
[Why] DP-HDMI dongles can execeed bandwidth requirements on high resolution monitors. This can lead to pruning the high resolution modes. HDMI 1.3 bumped the clock to 340MHz, but display code never matched it. [How] Set default to (DVI) 165MHz. Once HDMI display is identified update to 340MHz. Reported-by: Dianne Skoll <dianne@skoll.ca> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4780 Reviewed-by: Chris Park <chris.park@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@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> (cherry picked from commit ac1e65d8ade46c09fb184579b81acadf36dcb91e) Cc: stable@vger.kernel.org
2026-01-14drm/amd/display: Show link name in PSR status messageMario Limonciello (AMD)
[Why] The PSR message was moved in commit 4321742c394e ("drm/amd/display: Move PSR support message into amdgpu_dm"). This message however shows for every single link without showing which link is which. This can send a confusing message to the user. [How] Add link name into the message. Fixes: 4321742c394e ("drm/amd/display: Move PSR support message into amdgpu_dm") Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> 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> (cherry picked from commit 99f77f6229c0766b980ae05affcf9f742d97de6a)
2026-01-14drm/amdkfd: fix a memory leak in device_queue_manager_init()Haoxiang Li
If dqm->ops.initialize() fails, add deallocate_hiq_sdma_mqd() to release the memory allocated by allocate_hiq_sdma_mqd(). Move deallocate_hiq_sdma_mqd() up to ensure proper function visibility at the point of use. Fixes: 11614c36bc8f ("drm/amdkfd: Allocate MQD trunk for HIQ and SDMA") Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit b7cccc8286bb9919a0952c812872da1dcfe9d390) Cc: stable@vger.kernel.org
2026-01-14drm/amdgpu: make sure userqs are enabled in userq IOCTLsAlex Deucher
These IOCTLs shouldn't be called when userqs are not enabled. Make sure they are enabled before executing the IOCTLs. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d967509651601cddce7ff2a9f09479f3636f684d) Cc: stable@vger.kernel.org
2026-01-14drm/amdgpu: Use correct address to setup gart page table for vram accessXiaogang Chen
Use dst input parameter to setup gart page table entries instead of using fixed location. Fixes: 237d623ae659 ("drm/amdgpu/gart: Add helper to bind VRAM pages (v2)") Signed-off-by: Xiaogang Chen <xiaogang.chen@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ca5d4db8db843be7ed35fc9334737490c2b58d32)
2026-01-14Revert duplicate "drm/amdgpu: disable peer-to-peer access for DCC-enabled ↵Peter Colberg
GC12 VRAM surfaces" This reverts commit 22a36e660d014925114feb09a2680bb3c2d1e279 once, which was merged twice due to an incorrect backmerge resolution. Fixes: ce0478b02ed2 ("Merge tag 'v6.18-rc6' into drm-next") Signed-off-by: Peter Colberg <pcolberg@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 38a0f4cf8c6147fd10baa206ab349f8ff724e391)
2026-01-14drm/amd: Clean up kfd node on surprise disconnectMario Limonciello (AMD)
When an eGPU is unplugged the KFD topology should also be destroyed for that GPU. This never happens because the fini_sw callbacks never get to run. Run them manually before calling amdgpu_device_ip_fini_early() when a device has already been disconnected. This location is intentionally chosen to make sure that the kfd locking refcount doesn't get incremented unintentionally. Cc: kent.russell@amd.com Closes: https://community.frame.work/t/amd-egpu-on-linux/8691/33 Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6a23e7b4332c10f8b56c33a9c5431b52ecff9aab) Cc: stable@vger.kernel.org
2026-01-14drm/amdgpu: fix drm panic null pointer when driver not support atomicLu Yao
When driver not support atomic, fb using plane->fb rather than plane->state->fb. Fixes: fe151ed7af54 ("drm/amdgpu: add generic display panic helper code") Signed-off-by: Lu Yao <yaolu@kylinos.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2f2a72de673513247cd6fae14e53f6c40c5841ef)
2026-01-14drm/amdgpu: Fix gfx9 update PTE mtype flagPhilip Yang
Fix copy&paste error, that should have been an assignment instead of an or, otherwise MTYPE_UC 0x3 can not be updated to MTYPE_RW 0x1. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit fc1366016abe4103c0f0fac882811aea961ef213) Cc: stable@vger.kernel.org
2026-01-14drm/amd/display: Add an hdmi_hpd_debounce_delay_ms moduleIvan Lipski
[Why&How] Right now, the HDMI HPD filter is enabled by default at 1500ms. We want to disable it by default, as most modern displays with HDMI do not require it for DPMS mode. The HPD can instead be enabled as a driver parameter with a custom delay value in ms (up to 5000ms). Fixes: c918e75e1ed9 ("drm/amd/display: Add an HPD filter for HDMI") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4859 Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amdkfd: Add domain parameter to alloc kernel BOPhilip Yang
To allocate kernel BO from VRAM domain for MQD in the following patch. No functional change because kernel BO allocate all from GTT domain. Rename amdgpu_amdkfd_alloc_gtt_mem to amdgpu_amdkfd_alloc_kernel_mem Rename amdgpu_amdkfd_free_gtt_mem to amdgpu_amdkfd_free_kernel_mem Rename mem_kfd_mem_obj gtt_mem to mem Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amdgpu/userq: Fix fence reference leak on queue teardown v2Srinivasan Shanmugam
The user mode queue keeps a pointer to the most recent fence in userq->last_fence. This pointer holds an extra dma_fence reference. When the queue is destroyed, we free the fence driver and its xarray, but we forgot to drop the last_fence reference. Because of the missing dma_fence_put(), the last fence object can stay alive when the driver unloads. This leaves an allocated object in the amdgpu_userq_fence slab cache and triggers This is visible during driver unload as: BUG amdgpu_userq_fence: Objects remaining on __kmem_cache_shutdown() kmem_cache_destroy amdgpu_userq_fence: Slab cache still has objects Call Trace: kmem_cache_destroy amdgpu_userq_fence_slab_fini amdgpu_exit __do_sys_delete_module Fix this by putting userq->last_fence and clearing the pointer during amdgpu_userq_fence_driver_free(). This makes sure the fence reference is released and the slab cache is empty when the module exits. v2: Update to only release userq->last_fence with dma_fence_put() (Christian) Fixes: edc762a51c71 ("drm/amdgpu/userq: move some code around") Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amdkfd: No need to suspend whole MES to evict processHarish Kasiviswanathan
Each queue of the process is individually removed and there is not need to suspend whole mes. Suspending mes stops kernel mode queues also causing unnecessary timeouts when running mixed work loads Fixes: 079ae5118e1f ("drm/amdkfd: fix suspend/resume all calls in mes based eviction path") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4765 Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amd/pm: Deprecate print_clk_levels callbackLijo Lazar
Use emit_clk_levels instead. Also, remove the unused helper function for getting sysfs buffer offset. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amd/pm: Use emit clock levels in SMU v15.0.0Lijo Lazar
print_clk_levels is no longer used, use emit_clk_levels instead. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14Revert "drm/amdgpu: don't attach the tlb fence for SI"Prike Liang
This reverts commit 820b3d376e8a102c6aeab737ec6edebbbb710e04. It’s better to validate VM TLB flushes in the flush‑TLB backend rather than in the generic VM layer. Reverting this patch depends on commit fa7c231fc2b0 ("drm/amdgpu: validate the flush_gpu_tlb_pasid()") being present in the tree. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amdgpu: validate the flush_gpu_tlb_pasid()Prike Liang
Validate flush_gpu_tlb_pasid() availability before flushing tlb. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amdkfd: Switch to using GC VERSION to decide LDS/Scratch baseLang Yu
Next generation GC IP with 4-level page table needs to use the same LDS/Scratch base with 5-level page table, use GC VERSION to decide is more appropriate. Signed-off-by: Lang Yu <lang.yu@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amd/pm: fix smu overdrive data type wrong issue on smu 14.0.2Yang Wang
resolving the issue of incorrect type definitions potentially causing calculation errors. Fixes: 54f7f3ca982a ("drm/amdgpu/swm14: Update power limit logic") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amdkfd: kfd driver supports hot unplug/replug amdgpu devicesXiaogang Chen
This patch allows kfd driver function correctly when AMD gpu devices got unplug/replug at run time. When an AMD gpu device got unplug kfd driver gracefully terminates existing kfd processes after stops all queues by sending SIGBUS to user process. After that user space can still use remaining AMD gpu devices. When all AMD gpu devices at system got removed kfd driver will not response new requests. Unplugged AMD gpu devices can be re-plugged. kfd driver will use added devices to function as usual. The purpose of this patch is having kfd driver behavior as expected during and after AMD gpu devices unplug/replug at run time. Signed-off-by: Xiaogang Chen <Xiaogang.Chen@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amd/pm: fix issue of missing '*' on pp_dpm_xxx nodesYang Wang
refine the code to fix '*' missing on pp_dpm_xxx series node. e.g.: missing '*' on navi10 pp_dpm_sclk $ cat /sys/class/drm/card0/device/pp_dpm_sclk 0: 300Mhz 1: 1930Mhz (missing symbol '*') Fixes: a08ea4bc7711 ("drm/amd/pm: Add a helper to show dpm table") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-14drm/amdkfd: Fix GART PTE for non-4K pagesize in svm_migrate_gart_map()Donet Tom
In svm_migrate_gart_map(), while migrating GART mapping, the number of bytes copied for the GART table only accounts for CPU pages. On non-4K systems, each CPU page can contain multiple GPU pages, and the GART requires one 8-byte PTE per GPU page. As a result, an incorrect size was passed to the DMA, causing only a partial update of the GART table. Fix this function to work correctly on non-4K page-size systems by accounting for the number of GPU pages per CPU page when calculating the number of bytes to be copied. Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Donet Tom <donettom@linux.ibm.com> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-21 15:48:46 +0000