linux-stable.git/drivers/gpu, branch v7.1.12

drm/amdgpu: Allocate coredump ring buffers per ring

2026-08-27T12:34:38+00:00

[ Upstream commit e40ff9840fa8a633d149f0242df10cae5e518062 ]

Allocate each ring buffer separately. A single allocation summing all
ring sizes can exceed the page allocator's MAX_ORDER limit and fail;
per-ring buffers stay small enough to satisfy. The existing allocation
style doesn't capture any ring data if the huge allocation fails.
Splitting into multiple allocations helps to capture as much data as
possible for the core dump.

A failed ring is left with a NULL buffer and skipped when formatting.

Fixes: eea85914d15b ("drm/amdgpu: save ring content before resetting the device")
Signed-off-by: Lijo Lazar 
Assisted-by: Claude Code
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
(cherry picked from commit 3e8e92b7892a6377bef86106bfff1b98cf586aee)
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format

2026-08-27T12:34:38+00:00

[ Upstream commit 7152b248dc3c8d5fa8629e99ed5655dd41b51562 ]

When dumping IB contents from a hung job, amdgpu_devcoredump_format()
acquired the VM root PD's reservation via amdgpu_vm_lock_by_pasid() and
then, for each IB, called amdgpu_bo_reserve() on the BO backing the IB.
Both reservations are reservation_ww_class_mutex objects and neither
used a ww_acquire_ctx, which trips lockdep:

  WARNING: possible recursive locking detected
  --------------------------------------------
  kworker/u128:0 is trying to acquire lock:
  ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4},
    at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]

  but task is already holding lock:
  ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4},
    at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]

   Possible unsafe locking scenario:
         CPU0
         ----
    lock(reservation_ww_class_mutex);
    lock(reservation_ww_class_mutex);

   *** DEADLOCK ***
   May be due to missing lock nesting notation

  Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu]
  Call Trace:
   __ww_mutex_lock.constprop.0
   ww_mutex_lock
   amdgpu_bo_reserve
   amdgpu_devcoredump_format+0x1594 [amdgpu]
   amdgpu_devcoredump_deferred_work+0xea [amdgpu]

The two reservations are on different BOs in the captured trace, so the
splat is a lockdep-correctness warning, not an observed deadlock. It
becomes a real self-deadlock whenever the IB BO shares its dma_resv with
the root PD (the always-valid case, see amdgpu_vm_is_bo_always_valid()):
amdgpu_bo_reserve(abo) re-acquires the same ww_mutex without a ticket
and blocks forever. With amdgpu.gpu_recovery=0 the timeout handler
refires every ~2 s and each invocation produces this splat, drowning the
kernel ring buffer.

Now that amdgpu_vm_lock_by_pasid() takes a drm_exec context, move the IB
dumping into a separate helper that locks the root PD and every IB BO
together in a single drm_exec ticket. DRM_EXEC_IGNORE_DUPLICATES handles
IB BOs that share a dma_resv (e.g. always-valid BOs, or two IBs backed
by the same BO). Every lock is now a top-level acquire under one
ww_acquire_ctx, so the recursive ww_mutex condition is gone, and the
per-IB amdgpu_bo_reserve()/amdgpu_bo_unref() dance -- including a BO
refcount leak on the amdgpu_bo_reserve() failure path -- is removed.

Fixes: 7b15fc2d1f1a ("drm/amdgpu: dump job ibs in the devcoredump")
Suggested-by: Christian König 
Signed-off-by: Mikhail Gavrilov 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)
Stable-dep-of: e40ff9840fa8 ("drm/amdgpu: Allocate coredump ring buffers per ring")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/xe: Fix DPT allocation paths.

2026-08-27T12:34:36+00:00

[ Upstream commit fc648757908304aedbad74f74bf58192aec383db ]

Remove the fallback for VRAM to system memory, I tested it and that
doesn't work at all, only a black screen with pipe fault errors were
observed.

On systems with media GT, extra latency is added when accessing stolen
memory when the GT is in MC6. Since we additionally aren't counting how
much memory is used for stolen and we could in theory fill up the
entire stolen area with DPT's, avoid using stolen and only use the
default memory region.

Using stolen may also result in random system hangs under load.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513
Fixes: 775d0adc01a5 ("drm/xe/fbdev: Limit the usage of stolen for LNL+")
Cc:  # v6.12+
Reviewed-by: Matthew Auld 
Link: https://patch.msgid.link/20260630135523.1775379-2-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst 
Acked-by: Matthew Brost  #teams
(cherry picked from commit a196406a3831291598fe8e73245914f7acffdfe0)
Signed-off-by: Thomas Hellström 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Introduce struct intel_fb_pin_params

2026-08-27T12:34:36+00:00

[ Upstream commit a89b7f72f20db1ae1a65e97881e785639db4480a ]

We need to pass a lot of information between the display driver
and the core driver to get framebuffers mapped into GGTT/DPT
correctly. Rather than passing around a swarm of integers and
boolean as function arguments, let's collect it all into a
structure (struct intel_fb_pin_params).

Start by moving the gtt view, alignment, phys_alignment,
and vtd_guard there. Going forward additional things need
to added as well (mainly various boolean flags).

Signed-off-by: Ville Syrjälä 
Link: https://patch.msgid.link/20260416174448.28264-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula 
Stable-dep-of: fc6487579083 ("drm/xe: Fix DPT allocation paths.")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Track fence region ID in plane state

2026-08-27T12:34:36+00:00

[ Upstream commit eb3dd9640731ae3ace871190f80474a8e7bae121 ]

Get rid of the needlessly complicated PLANE_HAS_FENCE +
intel_parent_vma_fence_id() dance by simply tracking the
fence_id directly in the plane state.

v2: Don't request the redundant fence for fbdev (Jani)
    Assign *out_fence_id with '=' instead of '|=' (Sashiko,Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
Link: https://patch.msgid.link/20260407170942.16515-1-ville.syrjala@linux.intel.com
Stable-dep-of: fc6487579083 ("drm/xe: Fix DPT allocation paths.")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/i915/pin: s/dev_priv/i915/ and drop struct drm_device usage

2026-08-27T12:34:36+00:00

[ Upstream commit 3823bf019d3b31ccd3e79860b7a3e20c719a1db4 ]

Improve consistency within i915_fb_pin.c by replacing dev_priv naming
with i915, and dropping struct drm_device usage.

Reviewed-by: Ville Syrjälä 
Link: https://patch.msgid.link/3a4ac0a732a561a487e46838bde6327cff5ccb38.1775556190.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula 
Stable-dep-of: fc6487579083 ("drm/xe: Fix DPT allocation paths.")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/log: Fix infinite loop when scale is too large for display

2026-08-23T12:29:34+00:00

[ Upstream commit f4f2bba28df9b9aaa00262a462139dbbcdc38d9f ]

When scale is large enough that scaled_font exceeds the display
dimensions, rows or columns become 0. A columns value of 0 causes
an infinite loop in drm_log_draw_kmsg_record() because the loop
never decrements len.

Check for zero rows/columns in drm_log_setup_modeset() and return
an error, cleaning up the already allocated buffer to avoid a leak.

Fixes: 8a4b913df427 ("drm/log: Add integer scaling support")
Signed-off-by: Shixiong Ou 
Reviewed-by: Jocelyn Falempe 
Link: https://patch.msgid.link/20260729084815.692944-1-oushixiong1025@163.com
Signed-off-by: Jocelyn Falempe 
Signed-off-by: Sasha Levin

drm/log: Fix out-of-bounds read on empty message length

2026-08-23T12:29:34+00:00

[ Upstream commit 60baa179ed1333535f6e2da4133511db55278ee4 ]

drm_log_draw_kmsg_record() accesses s[len - 1] to strip the trailing
newline, but len is unsigned int. If len is 0, the subtraction wraps
to UINT_MAX, causing an out-of-bounds read.

Add an early return when len is 0.

Fixes: 25e2c2a3eff5 ("drm/log: Color the timestamp, to improve readability")
Signed-off-by: Shixiong Ou 
Reviewed-by: Jocelyn Falempe 
Link: https://patch.msgid.link/20260729084520.688087-1-oushixiong1025@163.com
Signed-off-by: Jocelyn Falempe 
Signed-off-by: Sasha Levin

drm/log: Fix division by zero when scale module parameter is 0

2026-08-23T12:29:34+00:00

[ Upstream commit 921ac6cb066d09b5765db892d0db0ffaffa98767 ]

The scale module parameter can be set to 0 via kernel command line.
When scale is 0, scaled_font_h and scaled_font_w become 0, causing
a division by zero in the rows/columns calculation.

Since the scale module parameter is read-only (0444 permissions), it
cannot be changed at runtime via sysfs. Clamp it to 1 once in
drm_log_register().

Fixes: 8a4b913df427 ("drm/log: Add integer scaling support")
Signed-off-by: Shixiong Ou 
Reviewed-by: Jocelyn Falempe 
Link: https://patch.msgid.link/20260730014440.66323-1-oushixiong1025@163.com
Signed-off-by: Jocelyn Falempe 
Signed-off-by: Sasha Levin

drm/xe: Fix a bug in pc_adjust_freq_bounds()

2026-08-23T12:29:34+00:00

[ Upstream commit 5cf82c8cec90056511eb881a267aab6101eaf57a ]

In cases where min frequency was actually greater than BMG_MIN_FREQ,
we were not using the updated min frequency as there was a missing
call to pc_action_query_task_state() between the two settings of
min frequency. Since we know what min_freq was last set, use that
cached value while comparing to BMG_MIN_FREQ to fix this issue.

v2: pc->freq_ready is not set until after pc_adjust_freq_bounds(). Stay
with pc_action_query_task_state() instead.

v3: Update commit message (Stuart)

Fixes: bdde16c9ac5c ("drm/xe/bmg: Update Wa_14022085890")
Signed-off-by: Balasubramani Vivekanandan 
Signed-off-by: Vinay Belgaumkar 
Reviewed-by: Stuart Summers 
Link: https://patch.msgid.link/20260805234649.2076384-1-vinay.belgaumkar@intel.com
(cherry picked from commit a2c2d2b13a9ea9494d2d76b46273833111749507)
Signed-off-by: Thomas Hellström 
Signed-off-by: Sasha Levin