On Wed, Jan 15, 2020 at 8:14 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > From: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
