[RFC PATCH 0/2] drm: etnaviv: Unmap gems on gem_close

[Guido Günther]

This is meant as a RFC since i'm not sure if this is the right
way to fix the problem:

So far the unmap from gpu address space only happened when dropping the
last ref in gem_free_object_unlocked, however that is skipped if there's
still multiple handles to the same GEM object.

Since userspace (here mesa) in the case of softpin hands back the memory
region to the pool of available GPU virtual memory closing the handle
via DRM_IOCTL_GEM_CLOSE this can lead to etnaviv_iommu_insert_exact
failing later since userspace thinks the vaddr is available while the
kernel thinks it isn't making the submit fail like

     [E] submit failed: -14 (No space left on device) (etna_cmd_stream_flush:244)

Fix this by unmapping the memory via the .gem_close_object callback.

The patch is against 5.9 and will need to be redone for drm-misc-next due to
the conversion to GEM object functions but i'm happy to do that it looks like
the right approach.

I can trigger the problem when plugging/unplugging a DP screen driven by DCSS
while DSI is driven by mxsfb. It preferably happens with 4k since this
allocates bigger chunks.

I also folded in a commit checking for the context->lock in
etnaviv_iommu_insert_exact and etnaviv_iommu_remove_mapping too to make it
match etnaviv_iommu_find_iova.

Guido Günther (2):
  drm: etnaviv: Add lockdep annotations for context lock
  drm: etnaviv: Unmap gems on gem_close

 drivers/gpu/drm/etnaviv/etnaviv_drv.c |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 32 +++++++++++++++++++++++++++
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c |  4 ++++
 4 files changed, 38 insertions(+)

-- 
2.28.0