From: Rob Herring <robh@kernel.org>
To: dri-devel <dri-devel@lists.freedesktop.org>
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Steven Price <steven.price@arm.com>
Subject: Re: [PATCH v3] drm/panfrost: Add the panfrost_gem_mapping concept
Date: Wed, 15 Jan 2020 20:17:40 -0600 [thread overview]
Message-ID: <CAL_JsqKFKAnW7z7C=MibDdem-x+x-C8F+OC3NjL3WOpuK+501w@mail.gmail.com> (raw)
In-Reply-To: <20200116021456.14262-1-robh@kernel.org>
On Wed, Jan 15, 2020 at 8:14 PM Rob Herring <robh@kernel.org> wrote:
>
> From: Boris Brezillon <boris.brezillon@collabora.com>
>
> With the introduction of per-FD address space, the same BO can be mapped
> in different address space if the BO is globally visible (GEM_FLINK)
> and opened in different context or if the dmabuf is self-imported. The
> current implementation does not take case into account, and attaches the
> mapping directly to the panfrost_gem_object.
>
> Let's create a panfrost_gem_mapping struct and allow multiple mappings
> per BO.
>
> The mappings are refcounted which helps solve another problem where
> mappings were torn down (GEM handle closed by userspace) while GPU
> jobs accessing those BOs were still in-flight. Jobs now keep a
> reference on the mappings they use.
>
> v2 (robh):
> - Minor review comment clean-ups from Steven
> - Use list_is_singular helper
> - Just WARN if we add a mapping when madvise state is not WILLNEED.
> With that, drop the use of object_name_lock.
>
> v3 (robh):
> - Revert returning list iterator in panfrost_gem_mapping_get()
Ignore this one...
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-01-16 2:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 2:14 [PATCH v3] drm/panfrost: Add the panfrost_gem_mapping concept Rob Herring
2020-01-16 2:17 ` Rob Herring [this message]
2020-01-16 2:15 Rob Herring
2020-01-16 8:37 ` Boris Brezillon
2020-01-17 11:40 ` Steven Price
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='CAL_JsqKFKAnW7z7C=MibDdem-x+x-C8F+OC3NjL3WOpuK+501w@mail.gmail.com' \
--to=robh@kernel.org \
--cc=alyssa.rosenzweig@collabora.com \
--cc=boris.brezillon@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=steven.price@arm.com \
--cc=tomeu.vizoso@collabora.com \
/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.