diff options
| author | Ville Syrjälä <ville.syrjala@linux.intel.com> | 2025-10-16 21:54:07 +0300 |
|---|---|---|
| committer | Ville Syrjälä <ville.syrjala@linux.intel.com> | 2025-11-07 17:38:48 +0200 |
| commit | 965930962a41cdb24a4b0e1c2f580b20b139bacb (patch) | |
| tree | 5c2c6dd6df7d2b5cc689ac47d0170b9c0c072039 /tools/lib/python/kdoc/kdoc_re.py | |
| parent | 8f1ddb0251452c9de35a96ac5f7c4f5e87a37266 (diff) | |
drm/i915/frontbuffer: Fix intel_frontbuffer lifetime handling
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 <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251016185408.22735-10-ville.syrjala@linux.intel.com
Diffstat (limited to 'tools/lib/python/kdoc/kdoc_re.py')
0 files changed, 0 insertions, 0 deletions
