All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Guido Günther" <agx@sigxcpu.org>
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
Subject: [RFC PATCH 0/2] drm: etnaviv: Unmap gems on gem_close
Date: Thu, 29 Oct 2020 15:20:55 +0100	[thread overview]
Message-ID: <cover.1603981111.git.agx@sigxcpu.org> (raw)
In-Reply-To: <cover.1603979517.git.agx@sigxcpu.org>

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

-- 
2.28.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

       reply	other threads:[~2020-10-29 14:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1603979517.git.agx@sigxcpu.org>
2020-10-29 14:20 ` Guido Günther [this message]
2020-10-29 14:20   ` [RFC PATCH 1/2] drm: etnaviv: Add lockdep annotations for context lock Guido Günther
2020-10-30 14:35     ` Lucas Stach
2020-10-29 14:20   ` [RFC PATCH 2/2] drm: etnaviv: Unmap gems on gem_close Guido Günther
2020-10-29 14:38     ` Lucas Stach
2020-10-29 18:20       ` Daniel Vetter
2020-10-30  9:19         ` Lucas Stach
2020-10-30  9:33           ` Daniel Vetter
2020-10-30  9:38             ` Lucas Stach
2020-10-30 14:17           ` Guido Günther

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1603981111.git.agx@sigxcpu.org \
    --to=agx@sigxcpu.org \
    --cc=airlied@linux.ie \
    --cc=christian.gmeiner@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux+etnaviv@armlinux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.