[Intel-gfx] [PATCH 0/2] drm/i915/gem: dma-buf fixes for migration

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx