summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-02-27drm/i915/overlay: Extract i915_overlay_setup()Ville Syrjälä
Pull the gem/gt related bits of the overlay setup into a separate function (i915_overlay_setup()) that will eventually move to the i915 side of the parent vs. display driver split. For now we'll also have to pass in the overlay struct, but that will disappear once the i915 vs. display split is completed. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-10-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Extract i915_overlay_reset()Ville Syrjälä
overlay->frontbuffer_bits tracking will move to the i915 side of the parent vs. display driver split, so extract the reset part of that into a new function (i915_overlay_reset()). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-9-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Use struct drm_gem_object as the typeVille Syrjälä
Use 'struct drm_gem_object' for the BO instead of 'struct drm_i915_gem_object', to avoid having the display side know anything about the i915 specific BO type. v2: Correctly handle the ERR_PTR returned by i915_overlay_obj_lookup() (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-8-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Introduce i915_overlay_obj_lookup()Ville Syrjälä
Extract the BO lookup and tiling check into a new helper called i915_overlay_obj_lookup(). This will have to move to the i915 side of the parent vs. display driver split. There is a slight change here in that we now do the tiling check before taking the modeset locks, but those locks don't protect the BO tiling stuff in any way, so nothing is really different here. Note that the hardware should support X-tiled scanout also for the overlay, but I guess no one ever bothered to hook it up and test it. So the check should stay at least for now. v2: Correctly handle the ERR_PTR returned by i915_overlay_obj_lookup() (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-7-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Relocate the underrun checkVille Syrjälä
Move the underrun check out from intel_overlay_continue() so that the DOVSTA register access can stay on the display side of the parent vs. display driver split. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-6-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Remove redundant overlay->activeVille Syrjälä
Now that we have overlay->frontbuffer_bits, overlay->active is completely redundant, so remove it. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-5-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Extract i915_overlay_is_active()Ville Syrjälä
Pull the "is the overlay active?" check to a helper (i915_overlay_is_active()). This will have to move to the i915 side of the parent vs. display driver split. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-4-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Track current frontbuffer_bitsVille Syrjälä
Store the current frontbuffer_bits in the overlay data. The main benefit here is that we get rid of the 'crtc->pipe' usage from intel_overlay_flip_prepare() which will have to move to the i915 side of the parent vs. display driver split. And since the goal is to get rid of the crtc stuff, move those out from intel_overlay_off_tail() into intel_overlay_switch_off() since the i915 side doesn't use those anymore, and the display side doesn't need those anymore after that anyway. intel_overlay_off_tail() will itself move to the i915 side of the fence once the driver split is done. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-3-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Remove GPU hang snapshot stuffVille Syrjälä
The overlay snapshot stuff is a bit annoying because some of it more or less of belongs on the gt side, and some on the display side. Remove the whole thing to avoid having to deal with it when splitting the overlay code around the i915 vs. display boundary. I don't think I've ever actually used this for anything, so no real loss from my POV. And it can always be resurrected later should the need arise. v2: Rebase due to kmalloc_obj() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-2-ville.syrjala@linux.intel.com
2026-02-27drm/xe/compat: Remove unused i915_reg.h from compat headerUma Shankar
Display Code is made independent of i915_reg.h, hence it can be dropped from compat header. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260226175531.2324526-1-uma.shankar@intel.com
2026-02-27drm/i915/backlight: Remove try_vesa_interfaceSuraj Kandpal
Some panels need VESA DPCD AUX backlight but VBT says otherwise. This is why we try with Intel backlight interface over VESA backlight interface. This causes a blankout on such panels without any fallback mechanism. Remove try_vesa_interface and use VESA AUX backlight interface as a fallback mechanism. While at in sneak in a small comment cleanup too. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15679 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260224031322.2568874-1-suraj.kandpal@intel.com
2026-02-27Merge tag 'amd-drm-fixes-7.0-2026-02-26' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.0-2026-02-26: amdgpu: - UserQ fixes - DC fix - RAS fixes - VCN 5 fix - Slot reset fix - Remove MES workaround that's no longer needed Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260226161330.3549393-1-alexander.deucher@amd.com
2026-02-27Merge tag 'drm-xe-fixes-2026-02-26' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - W/a fix for multi-cast registers (Roper) - Fix xe_sync initialization issues (Shuicheng) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/aaBGHy_0RLGGIBP5@intel.com
2026-02-26drm/xe/configfs: Free ctx_restore_mid_bb in releaseShuicheng Lin
ctx_restore_mid_bb memory is allocated in wa_bb_store(), but xe_config_device_release() only frees ctx_restore_post_bb. Free ctx_restore_mid_bb[0].cs as well to avoid leaking the allocation when the configfs device is removed. Fixes: b30d5de3d40c ("drm/xe/configfs: Add mid context restore bb") Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20260225013448.3547687-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-26drm/xe/xe3p_xpc: Drop stale MCR steering TODO commentMatt Roper
Proper steering+termination for Xe3p_XPC NODE and BANK multicast ranges was added in commit 6d5511e56b2d ("drm/xe/xe3p_xpc: Add MCR steering for NODE and L3BANK ranges") but we forgot to remove the corresponding TODO comment at the top of the block. Drop it now to avoid confusion. Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260225203719.3310570-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-26drm/i915/dpt: pass opaque struct intel_dpt around instead of i915_address_spaceJani Nikula
struct i915_address_space is used in an opaque fashion in the display parent interface, but it's just one include away from being non-opaque. And anyway the name is rather specific. Switch to using the struct intel_dpt instead, which embeds struct i915_address_space anyway. With the definition hidden in i915_dpt.c, this can't be accidentally made non-opaque, and the type seems rather more generic anyway. We do have to add a new helper i915_dpt_to_vm(), as there's one case in intel_fb_pin_to_dpt() that requires direct access to struct i915_address_space. But this just underlines the point about opacity. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/daa39178c0b0305b010564952d691f06e3cd63ca.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: rename struct i915_dpt to intel_dptJani Nikula
Rename struct i915_dpt to intel_dpt. This may seem rather inconsistent considering we just renamed the functions the other way round, but the intent here is to lift struct intel_dpt to the display parent interface as the generic opaque type for DPT instead of the very specific struct i915_address_space. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/afb89dcce35c5b0cff2007b58d6ee20fd3200c24.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: rename i915 specific functions to i915_dpt_ prefixJani Nikula
Follow the common convention of naming functions by file name, in this case also clarifying which functions are i915 specific. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/9bb94942ed4a15bcdd89be3f0029a2cb6cdf170d.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: switch to i915 runtime pm callsJani Nikula
The i915 specific code doesn't need to, and should not, call the display runtime pm functions. Just call the i915 functions directly, instead of routing through the parent interface. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/e8e00552ebf439b5f7b5d293014cce950c9c2999.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: drop _common from the DPT file namesJani Nikula
With the intel_dpt.[ch] file names vacated, and i915 specific code moved away, we can rename the intel_dpt_common.[ch] files to the simpler name. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/3f2da737a26bb71a7bc05a3e6c456302e3c72656.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: remove display/intel_dpt.hJani Nikula
The remaining functions declared in intel_dpt.h are i915 specific, and so are the users, so we can move them to i915_dpt.h. There are some useless intel_dpt.h includes around that we can remove. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/de16eddbb49110b56ff44899d9498e3081da91fa.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: move suspend/resume to parent interfaceJani Nikula
Add per-vm DPT suspend/resume calls to the display parent interface, and lift the generic code away from i915 specific code. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/080945a49559ec1f5183ad409e1526736e828d90.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: move create/destroy to parent interfaceJani Nikula
Move the DPT create/destroy calls to the display parent interface. With this, we can remove the dummy xe implementation. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/9753b21466c668872f468ccff827eab7be034b0c.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: pass obj, size instead of framebuffer to intel_dpt_create()Jani Nikula
Split the size determination between caller and callee to drop the dependency on struct intel_framebuffer from DPT code, but avoid adding a dependency on I915_GTT_PAGE_SIZE in the caller side. Pass zero size to let intel_dpt_create() handle the regular obj->size case, but remapped size if fb needs stride remap. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/3a6e987ce8bb9f2c8d90c35342de14494a64de1b.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: move display/intel_dpt.c to i915_dpt.cJani Nikula
The DPT implementation is i915 specific. The xe driver has a different implementation. Move display/intel_dpt.c to i915_dpt.c. Cleanups will follow. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/20a3bfb2762f39f9666d9a5752b8d2fb133583b0.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-27Merge tag 'drm-misc-fixes-2026-02-26' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Several fixes for: - amdxdna: Fix for a deadlock, a NULL pointer dereference, a suspend failure, a hang, an out-of-bounds access, a buffer overflow, input sanitization and other minor fixes. - dw-dp: An error handling fix - ethosu: A binary shift overflow fix - imx: An error handling fix - logicvc: A dt node reference leak fix - nouveau: A WARN_ON removal - samsung-dsim: A memory leak fix - sharp-memory: A NULL pointer dereference fix - vmgfx: A reference count and error handling fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260226-heretic-stimulating-swine-6a2f27@penduick
2026-02-26drm/xe: Move LRC seqno to system memory to avoid slow dGPU readsMatthew Brost
The LRC seqno is read by the CPU in the fence signaling path. On dGPU that read can turn into a PCIe transaction when the seqno lives in the main LRC BO, making the hot-path poll/peek much more expensive. Allocate a small dedicated seqno BO in system memory and map the seqno and start_seqno fields from there instead. The GPU still updates the values, but CPU reads stay in cached system memory and avoid PCIe read latency. Update the LRC map/address helpers to accept a BO expression and use the new lrc->seqno_bo for seqno mappings. Unpin/unmap seqno_bo during teardown. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260218043319.809548-4-matthew.brost@intel.com
2026-02-26drm/xe: Avoid unconditional VRAM reads in H2G pathMatthew Brost
desc_read() issues an VRAM read which serializes the CPU and drains posted writes on dGPU platforms. The H2G tracepoint evaluated its arguments unconditionally, so even with tracing disabled the submission path paid the full VRAM readf latency. Guard the tracepoint with trace_xe_guc_ctb_h2g_enabled(). Adso move the descriptor status verification under CONFIG_DRM_XE_DEBUG. This removes another unnecessary VRAM read in non-debug builfds. This results in ~10× faster H2G submission and significantly reduces lock contention across the driver. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260218043319.809548-3-matthew.brost@intel.com
2026-02-26drm/xe: Split H2G and G2H into separate buffer objectsMatthew Brost
H2G and G2H buffers have different access patterns (H2G is CPU-write, GuC-read, while G2H is GPU-write, CPU-read). On dGPU, these patterns benefit from different memory placements: H2G in VRAM and G2H in system memory. Split the CT buffer into two separate buffers—one for H2G and one for G2H—and select the optimal placement for each. This provides a significant performance improvement on the G2H read path, reducing a single read from ~20 µs to under 1 µs on BMG. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260218043319.809548-2-matthew.brost@intel.com
2026-02-26drm/xe: Do not preempt fence signaling CS instructionsMatthew Brost
If a batch buffer is complete, it makes little sense to preempt the fence signaling instructions in the ring, as the largest portion of the work (the batch buffer) is already done and fence signaling consists of only a few instructions. If these instructions are preempted, the GuC would need to perform a context switch just to signal the fence, which is costly and delays fence signaling. Avoid this scenario by disabling preemption immediately after the BB start instruction and re-enabling it after executing the fence signaling instructions. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Carlos Santa <carlos.santa@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260115004546.58060-1-matthew.brost@intel.com
2026-02-26Revert "drm/xe/compat: Remove unused i915_reg.h from compat header"Uma Shankar
This reverts commit 4953d806a423087fcc49d4f8884fde85cd23ec1e. Change breaks build for drm-xe-next, hence revert. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260226113413.2045899-1-uma.shankar@intel.com
2026-02-26drm/panel-edp: Change BOE NV140WUM-N64 timingsHaikun Zhou
This screen timing requires a backlight off time of more than 100ms from the end of the data stream to avoid screen flickering and red light caused by screen material limitations. Signed-off-by: Haikun Zhou <zhouhaikun5@huaqin.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260226083235.2176689-1-zhouhaikun5@huaqin.corp-partner.google.com
2026-02-26drm/amdkfd: fix CWSR trap handlerAlex Deucher
Fix up what looks like a bad merge. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-26drm/xe: Don't expose display modparam if no display supportMichal Wajdeczko
With CONFIG_DRM_XE_DISPLAY=n the display support will be compiled out, so exposing probe_display modparam is pointless. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260216183240.1308-1-michal.wajdeczko@intel.com
2026-02-26drm/solomon: Fix page start when updating rectangle in page addressing modeFrancesco Lavra
In page addressing mode, the pixel values of a dirty rectangle must be sent to the display controller one page at a time. The range of pages corresponding to a given rectangle is being incorrectly calculated as if the Y value of the top left coordinate of the rectangle was 0. This can result in rectangle updates being displayed on wrong parts of the screen. Fix the above issue by consolidating the start page calculation in a single place at the beginning of the update_rect function, and using the calculated value for all addressing modes. Fixes: b0daaa5cfaa5 ("drm/ssd130x: Support page addressing mode") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260210180932.736502-1-flavra@baylibre.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-02-26drm/xe/pf: Don't use LMTT page size if no LMTTMichal Wajdeczko
While today all our DGFX platforms have LMTT, we already started preparation to do not rely on this assumption. Add check for the LMTT presence and return default page size as VRAM/LMEM alignment if there is no LMTT. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260221152230.7071-4-michal.wajdeczko@intel.com
2026-02-26drm/xe/pf: Don't force 2MB VRAM alignmentMichal Wajdeczko
There is no need to always request VRAM BO to have 2MB alignment as for now this is required by the LMTT only, which could be not present on some platforms with VRAM. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260221152230.7071-3-michal.wajdeczko@intel.com
2026-02-26drm/xe/pf: Use explicit VRAM BO flag for VRAM provisioningMichal Wajdeczko
When we are about to provision VRAM/LMEM for VF, there is no point in using semi-automatic flag that supports fallback to the SMEM. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260221152230.7071-2-michal.wajdeczko@intel.com
2026-02-25drm/amd: Disable MES LR compute W/AMario Limonciello
A workaround was introduced in commit 1fb710793ce2 ("drm/amdgpu: Enable MES lr_compute_wa by default") to help with some hangs observed in gfx1151. This WA didn't fully fix the issue. It was actually fixed by adjusting the VGPR size to the correct value that matched the hardware in commit b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151"). There are reports of instability on other products with newer GC microcode versions, and I believe they're caused by this workaround. As we don't need the workaround any more, remove it. Fixes: b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151") Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9973e64bd6ee7642860a6f3b6958cbf14e89cabd) Cc: stable@vger.kernel.org
2026-02-25drm/amdgpu: Fix error handling in slot resetLijo Lazar
If the device has not recovered after slot reset is called, it goes to out label for error handling. There it could make decision based on uninitialized hive pointer and could result in accessing an uninitialized list. Initialize the list and hive properly so that it handles the error situation and also releases the reset domain lock which is acquired during error_detected callback. Fixes: 732c6cefc1ec ("drm/amdgpu: Replace tmp_adev with hive in amdgpu_pci_slot_reset") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Ce Sun <cesun102@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bb71362182e59caa227e4192da5a612b09349696)
2026-02-25drm/amdgpu/vcn5: Add SMU dpm interface typesguttula
This will set AMDGPU_VCN_SMU_DPM_INTERFACE_* smu_type based on soc type and fixing ring timeout issue seen for DPM enabled case. Signed-off-by: sguttula <suresh.guttula@amd.com> Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f0f23c315b38c55e8ce9484cf59b65811f350630)
2026-02-25drm/amdgpu: Fix locking bugs in error pathsBart Van Assche
Do not unlock psp->ras_context.mutex if it has not been locked. This has been detected by the Clang thread-safety analyzer. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: YiPeng Chai <YiPeng.Chai@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: amd-gfx@lists.freedesktop.org Fixes: b3fb79cda568 ("drm/amdgpu: add mutex to protect ras shared memory") Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6fa01b4335978051d2cd80841728fd63cc597970)
2026-02-25drm/amdgpu: Unlock a mutex before destroying itBart Van Assche
Mutexes must be unlocked before these are destroyed. This has been detected by the Clang thread-safety analyzer. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: amd-gfx@lists.freedesktop.org Fixes: f5e4cc8461c4 ("drm/amdgpu: implement RAS ACA driver framework") Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 270258ba320beb99648dceffb67e86ac76786e55)
2026-02-25drm/amd/display: Use GFP_ATOMIC in dc_create_stream_for_sinkNatalie Vock
This can be called while preemption is disabled, for example by dcn32_internal_validate_bw which is called with the FPU active. Fixes "BUG: scheduling while atomic" messages I encounter on my Navi31 machine. Signed-off-by: Natalie Vock <natalie.vock@gmx.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit b42dae2ebc5c84a68de63ec4ffdfec49362d53f1) Cc: stable@vger.kernel.org
2026-02-25drm/amdgpu: add upper bound check on user inputs in wait ioctlSunil Khatri
Huge input values in amdgpu_userq_wait_ioctl can lead to a OOM and could be exploited. So check these input value against AMDGPU_USERQ_MAX_HANDLES which is big enough value for genuine use cases and could potentially avoid OOM. v2: squash in Srini's fix Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit fcec012c664247531aed3e662f4280ff804d1476) Cc: stable@vger.kernel.org
2026-02-25drm/amdgpu: add upper bound check on user inputs in signal ioctlSunil Khatri
Huge input values in amdgpu_userq_signal_ioctl can lead to a OOM and could be exploited. So check these input value against AMDGPU_USERQ_MAX_HANDLES which is big enough value for genuine use cases and could potentially avoid OOM. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit be267e15f99bc97cbe202cd556717797cdcf79a5) Cc: stable@vger.kernel.org
2026-02-25drm/amdgpu/userq: Do not allow userspace to trivially triger kernel warningsTvrtko Ursulin
Userspace can either deliberately pass in the too small num_fences, or the required number can legitimately grow between the two calls to the userq wait ioctl. In both cases we do not want the emit the kernel warning backtrace since nothing is wrong with the kernel and userspace will simply get an errno reported back. So lets simply drop the WARN_ONs. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL") Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2c333ea579de6cc20ea7bc50e9595ef72863e65c)
2026-02-25drm/amdgpu/userq: Fix reference leak in amdgpu_userq_wait_ioctlTvrtko Ursulin
Drop reference to syncobj and timeline fence when aborting the ioctl due output array being too small. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL") Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 68951e9c3e6bb22396bc42ef2359751c8315dd27) Cc: <stable@vger.kernel.org> # v6.16+
2026-02-25drm/amd: Disable MES LR compute W/AMario Limonciello
A workaround was introduced in commit 1fb710793ce2 ("drm/amdgpu: Enable MES lr_compute_wa by default") to help with some hangs observed in gfx1151. This WA didn't fully fix the issue. It was actually fixed by adjusting the VGPR size to the correct value that matched the hardware in commit b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151"). There are reports of instability on other products with newer GC microcode versions, and I believe they're caused by this workaround. As we don't need the workaround any more, remove it. Fixes: b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151") Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-25drm/amdgpu: Fix error handling in slot resetLijo Lazar
If the device has not recovered after slot reset is called, it goes to out label for error handling. There it could make decision based on uninitialized hive pointer and could result in accessing an uninitialized list. Initialize the list and hive properly so that it handles the error situation and also releases the reset domain lock which is acquired during error_detected callback. Fixes: 732c6cefc1ec ("drm/amdgpu: Replace tmp_adev with hive in amdgpu_pci_slot_reset") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Ce Sun <cesun102@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-09 02:20:29 +0000