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

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: 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/i915/frontbuffer: convert intel_frontbuffer.[ch] to struct intel_display

2025-04-17T08:31:13+00:00

Going forward, struct intel_display is the main display device data pointer. Convert intel_frontbuffer.[ch] to struct intel_display. Reviewed-by: Chaitanya Kumar Borah Link: https://lore.kernel.org/r/ef0860583b7d6ad141959f84c25657e0c102d6d2.1744222449.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915/frontbuffer: convert frontbuffer->obj to struct drm_gem_object

2024-09-19T13:37:11+00:00

Prefer the driver agnostic struct drm_gem_object over i915 specific struct drm_i915_gem_object. Do some opportunistic struct intel_display conversions while at it, because it's more convenient to deal with. Reviewed-by: Maarten Lankhorst Acked-by: Rodrigo Vivi Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/51bdb3c9b798e28bd70c259fc3874d80bc9b7443.1726589119.git.jani.nikula@intel.com

drm/i915/frontbuffer: convert intel_frontbuffer_get() to struct drm_gem_object

2024-09-19T13:37:11+00:00

Prefer the driver agnostic struct drm_gem_object over i915 specific struct drm_i915_gem_object. Reviewed-by: Maarten Lankhorst Acked-by: Rodrigo Vivi Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/358cfcb5eb666732cd7ae21e4f63d07837960ec2.1726589119.git.jani.nikula@intel.com

drm/i915: Add new frontbuffer tracking interface to queue flush

2023-09-04T09:04:07+00:00

We want to wait dma fences in dirtyfb ioctl. As we don't want to make dirtyfb ioctl as blocking call we need to use dma_fence_add_callback. Callback used for dma_fence_add_callback is called from atomic context. Due to this we need to add a new frontbuffer tracking interface to queue flush. v3: - Check schedule work success rather than work being pending - Init flush work when frontbuffer struct is initialized v2: Check if flush work is already pending Signed-off-by: Jouni Högander Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230901093500.3463046-4-jouni.hogander@intel.com

drm/i915/display: Remove i915_gem_object_types.h from intel_frontbuffer.h

2023-08-01T05:47:09+00:00

Now as we have removed all the references to internals of i915_gem_object from the frontbuffer header we can also remove including i915_gem_object_types.h. Signed-off-by: Jouni Högander Reviewed-by: Jeevan B Link: https://patchwork.freedesktop.org/patch/msgid/20230727064142.751976-4-jouni.hogander@intel.com

drm/i915: Add getter/setter for i915_gem_object->frontbuffer

2023-08-01T05:47:08+00:00

Add getter/setter for i915_gem_object->frontbuffer and use it instead of directly touching i915_gem_object->frontbuffer frontbuffer pointer. v3: - Fix intel_frontbuffer_get return value - s/front_ret/cur/ v2: Move getter/setter into i915_gem_object.h Signed-off-by: Jouni Högander Reviewed-by: Nirmoy Das Link: https://patchwork.freedesktop.org/patch/msgid/20230727064142.751976-3-jouni.hogander@intel.com

drm/i915: move INTEL_FRONTBUFFER_* macros to intel_frontbuffer.h

2022-08-29T10:37:05+00:00

The macros clearly don't belong in i915_drv.h. Move to intel_frontbuffer.h. Also split the BUILD_BUG_ON()s to intel_frontbuffer_track() to avoid depending on some other macros in the header. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/c899fd1ef2220564a876cd88c03e53c4c7b0168b.1661346845.git.jani.nikula@intel.com