summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-02-27drm/ttm: Fix ttm_pool_beneficial_order() return typeTvrtko Ursulin
Fix a nasty copy and paste bug, where the incorrect boolean return type of the ttm_pool_beneficial_order() helper had a consequence of avoiding direct reclaim too eagerly for drivers which use this feature (currently amdgpu). Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 7e9c548d3709 ("drm/ttm: Allow drivers to specify maximum beneficial TTM pool size") Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.19+ Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260227124901.3177-1-tvrtko.ursulin@igalia.com
2026-02-27drm/nouveau: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The test itself does not change. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Lyude Paul <lyude@redhat.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: nouveau@lists.freedesktop.org Link: https://patch.msgid.link/20260227133113.235940-6-tzimmermann@suse.de Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-02-27drm/tests: Mark slow tests as slowMaxime Ripard
Some DRM tests cross the 1s execution time threshold that defines a test as slow. Let's flag them as such. Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260224110310.1854608-1-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-27drm/sched: Remove racy hack from drm_sched_fini()Philipp Stanner
drm_sched_fini() contained a hack to work around a race in amdgpu. According to AMD, the hack should not be necessary anymore. In case there should have been undetected users, commit 975ca62a014c ("drm/sched: Add warning for removing hack in drm_sched_fini()") had added a warning one release cycle ago. Thus, it can be derived that the hack can be savely removed by now. Remove the hack. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260108083019.63532-2-phasta@kernel.org
2026-02-27drm/i915/overlay: Convert overlay to parent interfaceVille Syrjälä
Convert the direct i915_overlay_*() calls from the display side to go over a new parent interface instead. v2: Correctly handle the ERR_PTR returned by i915_overlay_obj_lookup() (Jani) v3: Rebase due to the NULL check in intel_overlay_cleanup() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226130150.16816-1-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Move i915 specific code into i915_overlay.cVille Syrjälä
Relocate the i915 driver specific parts of the overlay code into i915_overlay.c. This leaves intel_overlay.c with just the display specific code. The one annoyance here is the DSPCLK_GATE_D register access being done from i830_overlay_clock_gating(). The register definition lives on the display side as we do need to access it on other platforms there. Since it's just one register and bit, I decided to just duplicate that part in i915_reg.h. v2: Use kzalloc_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/20260226133855.17690-1-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Don't use fetch_and_zero() in display codeVille Syrjälä
We don't generally want fetch_and_zero() on the display side, so stop using it in the display side intel_overlay_cleanup(). Fortunately we don't really have anything to do here apart from freeing the data. And we'll keep on clearing the pointer, just in case something somewhere cares about it. Note that once i915_overlay_cleanup() is converted to the parent interface we can't call it unconditionally (as xe won't have it). So we need to keep the early bailout for overlay==NULL. v2: Adjust the commit message since we do apparently have fetch_and_zero() in display code as well (Jani) v3: Skip i915_overlay_cleanup() if the overlay wasn't initialized Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226130113.16714-1-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Split 'struct intel_overlay'Ville Syrjälä
Split the i915 driver specific bits from 'struct intel_overlay' into a seaarate 'struct i915_overlay'. The latter will move to the i915 side of the parent vs. display driver split. The display side will also need to know the virtual address of the register map. That now gets passed as the return value from i915_overlay_setup(), so that the display side doesn't need to know how the mapping was achieved. v2: Use kzalloc_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-17-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: s/dev_priv/i915/Ville Syrjälä
Rename the one lingering 'dev_priv' variable to the more modern 'i915' in the overlay code. 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-16-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Make i830_overlay_clock_gating() i915 specificVille Syrjälä
i830_overlay_clock_gating() will remain on the i915 side of the parent vs. display driver split. Stop using display specific stuff inside it. The one annoyance here is access to the display engine's DSPCLK_GATE_D register. The proper way to deal with that might be to move it to the display side, but that seems a bit hard right now. So leave it where it is for now. 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-15-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Adjust i915 specific interfacesVille Syrjälä
Adjust the names ("i915_overlay_" prefix) and calling convention (pass the driver agnostic 'struct drm_device'() of the functions that will provide the remainder of the parent driver interface to be used by the overlay display code. 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-14-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Rename low level i915 specific functionsVille Syrjälä
Some of the lower level functions in the overlay code will move to the i915 side of the upcoming parent vs. display driver split. Move all such functions to the "i915_overlay_" namespace to make it easier to see what belongs where. 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-13-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Abstract buffer (un)pinningVille Syrjälä
Make the buffer (un)pinning a bit more abstract so that the display side of the code doesn't need to know about i915 specific things (i915_ggtt_offset() and i915_vma_unpin()). In preparation for the full parent vs. display driver split we'll also pass in the drm_device to these functions, although not strictly needed yet. 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-12-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Extract i915_overlay_cleanup()Ville Syrjälä
Pull the i915 specific bits of the overlay cleanup into a separate function (i915_overlay_cleanup()) to accommodate the upcoming 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-11-ville.syrjala@linux.intel.com
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
generated by cgit v1.2.3 (git 2.25.1) at 2026-06-09 11:24:34 +0000