linux.git/drivers/gpu/drm/i915/gt, branch master

drm/i915/selftests: Fix GT PM sort comparators

2026-07-16T15:27:19+00:00

Compare the sampled clock values instead of their addresses. Comparing
addresses leaves the samples unsorted, preventing the code from discarding
the minimum and maximum samples.

Fixes: 1a5392479207 ("drm/i915/selftests: Measure CS_TIMESTAMP")
Signed-off-by: Emre Cecanpunar 
Signed-off-by: Tvrtko Ursulin 
Link: https://lore.kernel.org/r/20260714220430.238433-1-emreleno@gmail.com
(cherry picked from commit 682ea2d28d18bb06f9fc663cb5ab7e80dc0e606a)
Signed-off-by: Rodrigo Vivi

drm/i915/gt: use correct selftest config symbol

2026-07-13T19:48:59+00:00

intel_engine_user.c checks CONFIG_DRM_I915_SELFTESTS before running
the engine UABI isolation check. Kconfig defines DRM_I915_SELFTEST,
without the trailing "S", and the rest of i915 uses
CONFIG_DRM_I915_SELFTEST.

Because CONFIG_DRM_I915_SELFTESTS is not backed by any Kconfig symbol,
the IS_ENABLED() test is always false. Use the existing selftest symbol
so the debug/selftest guarded path can be reached when selftests are
enabled.

This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the Kconfig definition and the inconsistent
guard in intel_engine_user.c.

Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT")
Signed-off-by: Pengpeng Hou 
Signed-off-by: Tvrtko Ursulin 
Link: https://lore.kernel.org/r/20260705080225.436-1-pengpeng@iscas.ac.cn
(cherry picked from commit 14a2012a490258f3f93857bc4f1b203405964be7)
Signed-off-by: Rodrigo Vivi

drm/i915/gt: Fix NULL deref on sched_engine alloc failure

2026-07-06T14:26:06+00:00

Avoid using intel_context_put() before intel_context_init() in
execlists_create_virtual() as the kref_put() inside would lead
to NULL deref on the IOCTL path when sched_engine allocation fails.

Discovered using AI-assisted static analysis confirmed by
Intel Product Security.

Reported-by: Martin Hodo 
Fixes: 3e28d37146db ("drm/i915: Move priolist to new i915_sched_engine object")
Cc: Matthew Brost 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc:  # v5.15+
Signed-off-by: Joonas Lahtinen 
Reviewed-by: Andi Shyti 
Signed-off-by: Tvrtko Ursulin 
Link: https://lore.kernel.org/r/20260701114513.221254-1-joonas.lahtinen@linux.intel.com
(cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)
Signed-off-by: Rodrigo Vivi

drm/i915: Skip deprecated selftest

2026-05-19T09:41:31+00:00

One of workaround test cases is now deprecated on modern platfroms,
skip it.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/12061
Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Krzysztof Karas 
Reviewed-by: Andi Shyti 
Signed-off-by: Andi Shyti 
Link: https://lore.kernel.org/r/20260515133052.1628281-2-janusz.krzysztofik@linux.intel.com

Merge drm/drm-next into drm-intel-gt-next

2026-05-12T08:16:35+00:00

Backmerging to pull in commit 5401b9adebc9 ("i915: don't use
a vma that didn't match the context VM") to revert it.

Signed-off-by: Joonas Lahtinen

drm/i915: skip __i915_request_skip() for already signaled requests

2026-05-07T12:13:01+00:00

After a GPU reset the HWSP is zeroed, so previously completed
requests appear incomplete. If such a request is picked up during
reset_rewind() and marked guilty, i915_request_set_error_once()
returns early (fence already signaled), leaving fence.error without
a fatal error code. The subsequent __i915_request_skip() then hits:
```
GEM_BUG_ON(!fatal_error(rq->fence.error))
```

Fixes a kernel BUG observed on Sandy Bridge (Gen6) during
heartbeat-triggered engine resets.
```
kernel BUG at drivers/gpu/drm/i915/i915_request.c:556!
RIP: __i915_request_skip+0x15e/0x1d0 [i915]
...
__i915_request_reset+0x212/0xa70 [i915]
reset_rewind+0xe4/0x280 [i915]
intel_gt_reset+0x30d/0x5b0 [i915]
heartbeat+0x516/0x530 [i915]
```

Guard __i915_request_skip() with i915_request_signaled(), if the
fence is already signaled, the ring content is committed and there
is nothing left to skip.

Fixes: 36e191f0644b ("drm/i915: Apply i915_request_skip() on submission")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/13729
Signed-off-by: Sebastian Brzezinka 
Cc: stable@vger.kernel.org # v5.7+
Reviewed-by: Krzysztof Karas 
Reviewed-by: Andi Shyti 
Signed-off-by: Andi Shyti 
Link: https://lore.kernel.org/r/fe76921d35b6ae85aa651822726d0d9815aa5362.1776339012.git.sebastian.brzezinka@intel.com

Merge tag 'drm-intel-next-2026-05-05' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next

2026-05-06T00:55:14+00:00

 - Enable PIPEDMC_ERROR interrupt (Dibin)
 - Some general display fixes and cleanups (Ville, Nemesa,
   Suraj, Dibin, Arun, Desnes, Juha-Pekka, Vidya, Julian)
 - More refactor to split display code (Jani, Ville, Luca)
 - Panel Replay BW optimization (Animesh)
 - Integrate the sharpness filter properly into the scaler (Ville)
 - Watermark/SAGV fixes/cleanups/etc (Ville)
 - Restructure DP/HDMI sink format handling (Ville)
 - Eliminate FB usage from low level pinning code (Ville)
 - Some initial prep patches for always enable AS SDP (Ankit)
 - Many PSR related fixes (Jouni)
 - Fix MST VCPI lookup and modeset-lock splat (Suraj)

Signed-off-by: Dave Airlie 

From: Rodrigo Vivi 
Link: https://patch.msgid.link/afot1cjSpeAjYzg2@intel.com

drm/i915/reset: Disable execlist per-engine reset for display reset tests

2026-04-16T17:22:24+00:00

The display reset only happens from the full reset path. We must
therefore force execlist submission to always take the full reset
path and not the per-engine reset path. Currently the display
reset tests are in fact not testing display resets at all on
platforms using execlist submission. Ring submission and GuC
submission always take the full path anyway.

Also disable the engine reset inside __intel_gt_set_wedged() so
that we simulate the intel_gt_gpu_reset_clobbers_display() behavior
as closely as possible also when taking the full wedge path.

The slight race between the separate intel_display_reset_test()
calls in the overall reset path is harmless. kms_busy will keep
the modparam fixed during the test, and even if someone were to
fiddle with the modparam manually nothing bad should happen if
the calls return different values.

Cc: Jouni Högander 
Cc: Maarten Lankhorst 
Acked-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
Link: https://patch.msgid.link/20260415210411.24750-8-ville.syrjala@linux.intel.com

drm/i915/reset: Move pending_fb_pin handling to i915

2026-04-16T16:24:22+00:00

Only i915 uses the pending_fb_pin counter to potentially whack
the GPU harder if the display gets nuked during a GPU reset.
Move the atomic counter into the i915 specific bits of code, so
that we don't need to worry about on the display side.

For some reason the overlay code kept the pending_fb_pin counter
elevated for longer than just for the pin, but from now on it'll
just cover the actual pinning part.

Cc: Jouni Högander 
Cc: Maarten Lankhorst 
Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
Link: https://patch.msgid.link/20260415210411.24750-5-ville.syrjala@linux.intel.com

drm/i915/reset: Reorganize display reset code

2026-04-16T16:24:22+00:00

Stop returning the "is there a display?" status from
intel_display_reset_prepare(). I plan to move the pending_fb_pin
into the i915 code, so I need to make that determination already
before intel_display_reset_prepare() is called. Add a new
intel_display_reset_supported() function for that.

v2: Also check display!=NULL for mock tests

Cc: Jouni Högander 
Cc: Maarten Lankhorst 
Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
Link: https://patch.msgid.link/20260415210411.24750-4-ville.syrjala@linux.intel.com