[PATCH v3] drm/panfrost: Add the panfrost_gem_mapping concept

[Rob Herring]

On Wed, Jan 15, 2020 at 8:14 PM Rob Herring <robh at kernel.org> wrote:
>
> From: Boris Brezillon <boris.brezillon at 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...