lwn.git/drivers/gpu/drm/i915/gem/i915_gem_object_frontbuffer.h, branch master

drm/{i915, xe}/frontbuffer: move frontbuffer handling to parent interface

2026-03-11T09:32:10+00:00

Move the get/put/ref/flush_for_display calls to the display parent interface. For i915, move the hooks next to the other i915 core frontbuffer code in i915_gem_object_frontbuffer.c. For xe, add new file xe_frontbuffer.c for the same. Note: The intel_frontbuffer_flush() calls from i915_gem_object_frontbuffer.c will partially route back to i915 core via the parent interface. This is less than stellar. Reviewed-by: Jouni Högander Link: https://patch.msgid.link/f69b967ed82bbcfd60ffa77ba197b26a1399f09f.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915/overlay: convert from struct intel_frontbuffer to i915_frontbuffer

2026-03-11T09:32:10+00:00

The intel_frontbuffer_get() and intel_frontbuffer_put() calls are routed through intel_frontbuffer.c to i915_gem_object_frontbuffer.c. We might as well call the functions directly, instead of going through display code. This would only get worse with get/put being moved to the parent interface. To make this easier, convert overlay code from struct intel_frontbuffer to struct i915_frontbuffer, and add a i915_gem_object_frontbuffer_track() wrapper for clarity. Reviewed-by: Jouni Högander Link: https://patch.msgid.link/829b304a6451e80fbce554bdc7788077245e803a.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915/gem: unify i915 gem object frontbuffer function names

2026-03-11T09:32:10+00:00

Many of the i915 gem object frontbuffer function names follow the file name as prefix. Follow suit with the remaining functions, renaming them i915_gem_object_frontbuffer_*(). Reviewed-by: Jouni Högander Link: https://patch.msgid.link/3415b59497f2c3a79586600d259eeaf58be73498.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915/gem: s/i915_gem_object_get_frontbuffer/i915_gem_object_frontbuffer_lookup/

2025-11-07T15:43:18+00:00

The i915_gem_object_get_frontbuffer() name is rather confusing wrt. intel_frontbuffer_get(). Rename to i915_gem_object_frontbuffer_lookup() to make things less confusing. Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20251016185408.22735-11-ville.syrjala@linux.intel.com Reviewed-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: Split fb_tracking.lock into two

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

Our fb_tracking.lock is serving a double duty: - protects fb_tracking.busy_bits - provides the write-side protection for obj->frontbuffer Split obj->frontbuffer role into a separate lock so that we can clean up the current mess with the frontbuffer lifetime management. Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20251016185408.22735-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

drm/i915/frontbuffer: Move bo refcounting intel_frontbuffer_{get,release}()

2025-10-09T18:01:48+00:00

Currently xe's intel_frontbuffer implementation forgets to hold a reference on the bo. This makes the entire thing extremely fragile as the cleanup order now depends on bo references held by other things (namely intel_fb_bo_framebuffer_fini()). Move the bo refcounting to intel_frontbuffer_{get,release}() so that both i915 and xe do this the same way. I first tried to fix this by having xe do the refcounting from its intel_bo_set_frontbuffer() implementation (which is what i915 does currently), but turns out xe's drm_gem_object_free() can sleep and thus drm_gem_object_put() isn't safe to call while we hold fb_tracking.lock. Fixes: 10690b8a49bc ("drm/i915/display: Add intel_fb_bo_framebuffer_fini") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

drm/{i915,xe}: convert i915 and xe display members into pointers

2025-05-16T08:15:16+00:00

As the first step towards making struct intel_display an opaque pointer in i915 and xe drivers, convert the struct drm_i915_private and struct xe_device display members into pointers. Initially, add temporary struct intel_display __display members, and point display at it to avoid dynamic allocation. In the future, we can drop this, and switch to dynamic allocation. The conversion is done simply with sed: sed -i 's/&$[a-zA-Z0-9_>.-]*$$dev_priv\|i915\|xe$->display$[^.]$/\1\2->display\3/g' \ $(git ls-files -- drivers/gpu/drm/i915 drivers/gpu/drm/xe) sed -i 's/$dev_priv\|i915\|xe$->display\./\1->display->/g' \ $(git ls-files -- drivers/gpu/drm/i915 drivers/gpu/drm/xe) With a couple of manual tweaks on top. v2: Initialize i915->display also in selftest mock_gem_device() Reviewed-by: Gustavo Sousa Signed-off-by: Jani Nikula Link: https://lore.kernel.org/r/20250507152254.2398934-1-jani.nikula@intel.com

drm/i915/display: Move releasing gem object away from fb tracking

2023-10-23T06:06:10+00:00

As a preparation for Xe we want to remove all i915_gem_object details away from frontbuffer tacking code. Due to this move releasing gem object reference to i915_gem_object_set_frontbuffer. Signed-off-by: Jouni Högander Reviewed-by: Juha-Pekka Heikkila Link: https://patchwork.freedesktop.org/patch/msgid/20231012072158.4115795-2-jouni.hogander@intel.com

drm/i915: add minimal i915_gem_object_frontbuffer.h

2023-08-31T15:41:34+00:00

Split out frontbuffer related declarations and static inlines from gem/i915_gem_object.h into new gem/i915_gem_object_frontbuffer.h. The main goal is to reduce header interdependencies. With gem/i915_gem_object.h including display/intel_frontbuffer.h, modification of the latter causes a whopping 300+ objects to be rebuilt, while many of the source files actually needing it aren't explicitly including it at all. After the change, only 21 objects depend on display/intel_frontbuffer.h, directly or indirectly. Cc: Jouni Högander Reviewed-by: Jouni Högander Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20230830085127.2416842-1-jani.nikula@intel.com