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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
