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.
To: Lucas Stach l.stach@pengutronix.de,Russell King linux+etnaviv@armlinux.org.uk,Christian Gmeiner christian.gmeiner@gmail.com,David Airlie airlied@linux.ie,Daniel Vetter daniel@ffwll.ch,etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org
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(+)