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(-)