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

[Boris Brezillon]

On Wed, 15 Jan 2020 20:15:54 -0600
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()

Feels a bit weird to ack my own patch, but this version is

Acked-by: Boris Brezillon <boris.brezillon at collabora.com>

> 
> Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc: <stable at vger.kernel.org>
> Signed-off-by: Boris Brezillon <boris.brezillon at collabora.com>
> Signed-off-by: Rob Herring <robh at kernel.org>