diff options
| author | Ville Syrjälä <ville.syrjala@linux.intel.com> | 2021-02-09 04:19:17 +0200 |
|---|---|---|
| committer | Jani Nikula <jani.nikula@intel.com> | 2021-02-10 11:03:56 +0200 |
| commit | 5feba0e905c495a217aea9db4ea91093d8fe5dde (patch) | |
| tree | d60a0d34ab21569d35f4dd451f3b3be401178174 /kernel/locking/rtmutex-debug.c | |
| parent | 2f51312bebb77962a518b4c6de777dd378b6110a (diff) | |
drm/i915: Fix overlay frontbuffer tracking
We don't have a persistent fb holding a reference to the frontbuffer
object, so every time we do the get+put we throw the frontbuffer object
immediately away. And so the next time around we get a pristine
frontbuffer object with bits==0 even for the old vma. This confuses
the frontbuffer tracking code which understandably expects the old
frontbuffer to have the overlay's bit set.
Fix this by hanging on to the frontbuffer reference until the next
flip. And just to make this a bit more clear let's track the frontbuffer
explicitly instead of just grabbing it via the old vma.
Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1136
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-2-ville.syrjala@linux.intel.com
Fixes: 8e7cb1799b4f ("drm/i915: Extract intel_frontbuffer active tracking")
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 553c23bdb4775130f333f07a51b047276bc53f79)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Diffstat (limited to 'kernel/locking/rtmutex-debug.c')
0 files changed, 0 insertions, 0 deletions