kernel/linux.git/drivers/gpu/drm/xe/display/intel_bo.c, branch linux-7.0.y

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

drm/{i915, xe}/display: make pxp key check part of bo interface

2025-12-02T10:08:46+00:00

Add intel_bo_key_check() next to intel_bo_is_protected() where it feels like it belongs, and drop the extra pxp compat header. Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20251201172730.2154668-1-jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915/frontbuffer: Fix intel_frontbuffer lifetime handling

2025-11-07T15:38:48+00:00

The current attempted split between xe/i915 vs. display for intel_frontbuffer is a mess: - the i915 rcu leaks through the interface to the display side - the obj->frontbuffer write-side is now protected by a display specific spinlock even though the actual obj->framebuffer pointer lives in a i915 specific structure - the kref is getting poked directly from both sides - i915_active is still on the display side Clean up the mess by moving everything about the frontbuffer lifetime management to the i915/xe side: - the rcu usage is now completely contained in i915 - frontbuffer_lock is moved into i915 - kref is on the i915/xe side (xe needs the refcount as well due to intel_frontbuffer_queue_flush()->intel_frontbuffer_ref()) - the bo (and its refcounting) is no longer on the display side - i915_active is contained in i915 I was pondering whether we could do this in some kind of smaller steps, and perhaps we could, but it would probably have to start with a bunch of reverts (which for sure won't go cleanly anymore). So not convinced it's worth the hassle. Acked-by: Jani Nikula Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20251016185408.22735-10-ville.syrjala@linux.intel.com

drm/i915/frontbuffer: Turn intel_bo_flush_if_display() into a frontbuffer operation

2025-11-07T15:37:21+00:00

Convert intel_bo_flush_if_display() to be an operation on the frontbuffer object rather than the underlying gem bo. This will help with cleaning up the frontbuffer xe/i915 vs. display split. Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20251016185408.22735-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

drm/{i915,xe}/panic: split out intel_panic.[ch]

2025-09-08T11:23:46+00:00

intel_bo.[ch] is not the appropriate location for the panic functionality. Split out intel_panic.[ch] and xe_panic.c in i915 and xe. Keep the function names for now. Cc: Jocelyn Falempe Cc: Maarten Lankhorst Signed-off-by: Jani Nikula Reviewed-by: Jocelyn Falempe Link: https://lore.kernel.org/r/d98b831a011a028ffd33ce99b0ba62be061ee235.1756835342.git.jani.nikula@intel.com

drm/i915/display: Add drm_panic support for Y-tiling with DPT

2025-06-27T09:48:23+00:00

On Alder Lake and later, it's not possible to disable tiling when DPT is enabled. So this commit implements Y-Tiling support, to still be able to draw the panic screen. Signed-off-by: Jocelyn Falempe Link: https://lore.kernel.org/r/20250624091501.257661-10-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst

drm/i915: Add intel_bo_panic_setup() and intel_bo_panic_finish()

2025-06-27T09:48:22+00:00

Implement both functions for i915 and xe, they prepare the work for drm_panic support. They both use kmap_try_from_panic(), and map one page at a time, to write the panic screen on the framebuffer. Signed-off-by: Jocelyn Falempe Link: https://lore.kernel.org/r/20250624091501.257661-8-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst

drm/i915: Add intel_bo_alloc_framebuffer()

2025-06-27T09:48:22+00:00

Encapsulate the struct intel_framebuffer into an xe_framebuffer or i915_framebuffer, and allow to add specific fields for each variant for the panic use-case. This is particularly needed to have a struct xe_res_cursor available to support drm panic on discrete GPU. Signed-off-by: Jocelyn Falempe Link: https://lore.kernel.org/r/20250624091501.257661-7-jfalempe@redhat.com Signed-off-by: Maarten Lankhorst

drm/xe/pxp/uapi: Add API to mark a BO as using PXP

2025-02-03T19:51:23+00:00

The driver needs to know if a BO is encrypted with PXP to enable the display decryption at flip time. Furthermore, we want to keep track of the status of the encryption and reject any operation that involves a BO that is encrypted using an old key. There are two points in time where such checks can kick in: 1 - at VM bind time, all operations except for unmapping will be rejected if the key used to encrypt the BO is no longer valid. This check is opt-in via a new VM_BIND flag, to avoid a scenario where a malicious app purposely shares an invalid BO with a non-PXP aware app (such as a compositor). If the VM_BIND was failed, the compositor would be unable to display anything at all. Allowing the bind to go through means that output still works, it just displays garbage data within the bounds of the illegal BO. 2 - at job submission time, if the queue is marked as using PXP, all objects bound to the VM will be checked and the submission will be rejected if any of them was encrypted with a key that is no longer valid. Note that there is no risk of leaking the encrypted data if a user does not opt-in to those checks; the only consequence is that the user will not realize that the encryption key is changed and that the data is no longer valid. v2: Better commnnts and descriptions (John), rebase v3: Properly return the result of key_assign up the stack, do not use xe_bo in display headers (Jani) v4: improve key_instance variable documentation (John) Signed-off-by: Daniele Ceraolo Spurio Cc: Matthew Brost Cc: Thomas Hellström Cc: John Harrison Cc: Jani Nikula Reviewed-by: John Harrison Link: https://patchwork.freedesktop.org/patch/msgid/20250129174140.948829-11-daniele.ceraolospurio@intel.com