kernel/linux.git/drivers/gpu/drm/i915/display/intel_frontbuffer.c, branch linux-7.0.y

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

drm/i915/frontbuffer: Nuke intel_frontbuffer_flip_{prepare,complete}()

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

Get rid of intel_frontbuffer_flip_{prepare,complete}() (and the accompanying flip_bits) since they are unused. I suppose these could technically provide a minor optimization over intel_frontbuffer_flip() in that the flush would get deferred further if new rendering were to sneak in between the prepare() and complete() calls. But for correctness it should not make any difference since another flush will anyway follow once the new rendering finishes. Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20251016185408.22735-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

drm: include drm_print.h where needed

2025-10-31T08:34:52+00:00

There are a gazillion files that depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In preparation for removing those includes, explicitly include drm_print.h where needed. Cc: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Signed-off-by: Jani Nikula Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com

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

2025-10-13T18:08:41+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 (cherry picked from commit eb4d490729a5fd8dc5a76d334f8d01fec7c14bbe) Signed-off-by: Rodrigo Vivi