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

[Daniel Vetter]

On Thu, Oct 29, 2020 at 2:54 PM Guido Günther <agx at sigxcpu.org> wrote:
>
> 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

Can you pls resubmit with dri-devel on cc? This is kinda a general
problem of letting userspace manage the gpu VA.
-Daniel

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


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch