[Intel-gfx] [PATCH 0/2] drm/i915/gem: dma-buf fixes for migration
Thomas Hellström
thomas.hellstrom at linux.intel.com
Wed Jun 30 13:06:59 UTC 2021
Our dma-buf code is currently completely broken unless the importer is
dynamic in which case the sg_list caching saves the day. In particular,
the case where another instance of our driver tries to import a dma-buf
exported by our driver ends up in a recursive lock.
Since the recent TTM migration work spec specifies to fix up the dma-buf
code with migration and there's no point in doing so when it's
completely broken, take a first step to make at least the exporter obey
the dma-buf locking rules the dma-buf core enforces for a dynamic exporter:
- Implement and act on pin- and unpin.
- Call move_notify if migrating. (we opt not to migrate while dma-buf_mapped).
- map_dma_buf() is unconditionally called locked.
Add a selftest that ensures that it works with both our own and a fake
dynamic importer.
Also implement migration in the second patch before pinning in pin()
and map_dma_buf().
Note that the importer remains broken for other non-dynamic exporters, but
at least not for the same-driver-separate-instances case.
Regardless whether we want to fix this now with this series, or in an
unspecified future, the selftest may come in handy.
Thomas Hellström (2):
drm/i915/gem: Make our dma-buf exporter dynamic
drm/i915/gem: Migrate to system at dma-buf map time
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 48 ++++++-
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 118 +++++++++++++++++-
2 files changed, 162 insertions(+), 4 deletions(-)
--
2.31.1
More information about the Intel-gfx
mailing list