summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/kdoc_re.py
diff options
context:
space:
mode:
authorVille Syrjälä <ville.syrjala@linux.intel.com>2025-10-16 21:54:07 +0300
committerVille Syrjälä <ville.syrjala@linux.intel.com>2025-11-07 17:38:48 +0200
commit965930962a41cdb24a4b0e1c2f580b20b139bacb (patch)
tree5c2c6dd6df7d2b5cc689ac47d0170b9c0c072039 /tools/lib/python/kdoc/kdoc_re.py
parent8f1ddb0251452c9de35a96ac5f7c4f5e87a37266 (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