kernel/linux.git/drivers/gpu/drm/i915/display/intel_frontbuffer.c, branch v7.1

drm/i915/frontbuffer: reduce fb for frontbuffer abbreviation usage

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

Using fb for frontbuffer is a bit misleading, as framebuffer is the more common fb. Reduce fb usage in frontbuffer function naming. Reviewed-by: Jouni Högander Link: https://patch.msgid.link/f7f04d63771891d1c3b1aa280485437bc4a70f20.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915/frontbuffer: call parent interface directly

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

Do away with the redundant intel_frontbuffer_get(), intel_frontbuffer_put(), and intel_frontbuffer_ref() functions, and call the parent interface functions directly. Reviewed-by: Jouni Högander Link: https://patch.msgid.link/7451574d6840fe9a4af16d2d6b81ffb7739b5b76.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

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

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

2025-11-11T10:32:07+00:00

Primarily sync with the drm_print.h changes from drm-misc. 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: Add intel_frontbuffer::display

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

After upcoming intel_frontbuffer lifetime related changes we won't need intel_frontbuffer::obj for anything apart from getting at the display. Add a direct pointer for that instead so that the obj pointer can be completely eliminated. Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20251016185408.22735-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

drm/i915/frontbuffer: Extract intel_frontbuffer_ref()

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

I want to hide the kref from the high level frontbuffer code. To that end abstract the kref_get() in intel_frontbuffer_queue_flush() (which is the only high level function that needs this) as a new intel_frontbuffer_ref(). Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20251016185408.22735-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

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: Handle the dirtyfb cache flush inside intel_frontbuffer_flush()

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

intel_bo_frontbuffer_flush_for_display() is a bit too low level to be directly in the high level dirtyfb code. Move the calls into intel_frontbuffer_flush(). There is a slight behavioural change here in that we now skip the flush if the bo is not a current scanout buffer (front->bits == 0). But that is fine as the flush will eventually happen via the fb pinning code if/when the bo becomes a scanout buffer again. Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20251016185408.22735-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

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