[PATCH v2 1/1] drm/amdgpu: Add gem_prime_mmap support
Christian König
christian.koenig at amd.com
Thu Sep 21 14:34:04 UTC 2017
Am 21.09.2017 um 16:31 schrieb Li, Samuel:
>> Please just completely drop the begin_cpu_access() and end_cpu_access()
>> callbacks.
>> Checking other drivers the only one actually implementing something special
>> is the i915 driver which needs to remove the BO from the GTT domain for
>> cache coherency I think.
> Well, as the first step, we can drop the begin/end() callbacks for now, and revisit later.
Yeah, that's something I can perfectly live with. How about adding an in
code comment and noting it in the commit message?
Christian.
>
> Sam
>
>> -----Original Message-----
>> From: Koenig, Christian
>> Sent: Thursday, September 21, 2017 3:39 AM
>> To: Li, Samuel <Samuel.Li at amd.com>; amd-gfx at lists.freedesktop.org
>> Subject: Re: [PATCH v2 1/1] drm/amdgpu: Add gem_prime_mmap support
>>
>> Am 20.09.2017 um 22:31 schrieb Li, Samuel:
>>>> The waiting done here is only for the shared fence to switch from
>>>> explicitly to implicitly synchronization for correct interaction with the Intel
>> driver.
>>> Actually here it is going to wait for all fences,
>>> 94 ret = reservation_object_wait_timeout_rcu(bo->tbo.resv, true...
>> That is actually a bug, we only need to wait here when prime_shared_count
>> == 0.
>>
>>>> ttm_bo_validate() is an asynchronous operation to enable GPU access
>>>> to the BO, it isn't related at all to possible CPU access and can
>>>> actually prevent it a number of cases.
>>>>> amdgpu_ttm_bind() in turn binds the BO to the GART space and isn't
>>>>> related
>>>> to CPU access either.
>>> ttm_bo_validate() can move buffer is necessary,
>> No, that is a very common misconception.
>>
>> ttm_bo_validate() schedules the buffer to be moved at some point in the
>> future.
>>
>> The only thing which saves us here is the fact that TTM waits for the move to
>> be completed in it's page fault handler.
>>
>>> and amdgpu_ttm_bind() will flush hdp, which we have discussed before.
>> And as concluded before that is unnecessary.
>>
>>>> What you most likely need to do here is to use
>>>> reservation_object_wait_timeout_rcu() to wait for all GPU operations to
>> end.
>>> Right, that is called by amdgpu_gem_prime_pin().
>> Please just completely drop the begin_cpu_access() and end_cpu_access()
>> callbacks.
>>
>> Checking other drivers the only one actually implementing something special
>> is the i915 driver which needs to remove the BO from the GTT domain for
>> cache coherency I think.
>>
>> The omap driver implements those callbacks to grab an extra reference to
>> the pages while they are access, we don't need to do this since TTM grabs an
>> extra reference during the mmap anyway.
>>
>> All other drivers implementing mmap (exynos, rockchip, tilcdc, arcpgu, msm,
>> meson, etnaviv, sti, qxl, vc4, rcar-du, atmel-hlcdc, imx, mediatek, mali, vgem,
>> fsl-dcu, zte, hisilicon, sun4i, mxsfb) don't have a begin/end callback.
>>
>> Pinning the BO can actually cause problem with the display code when the
>> BO needs to be scanned out, so we should avoid that as much as possible.
>>
>> Regards,
>> Christian.
>>
>>> Sam
>>>
>>>> -----Original Message-----
>>>> From: Christian König [mailto:ckoenig.leichtzumerken at gmail.com]
>>>> Sent: Wednesday, September 20, 2017 2:15 PM
>>>> To: Li, Samuel <Samuel.Li at amd.com>; Koenig, Christian
>>>> <Christian.Koenig at amd.com>; amd-gfx at lists.freedesktop.org
>>>> Subject: Re: [PATCH v2 1/1] drm/amdgpu: Add gem_prime_mmap
>> support
>>>> Am 20.09.2017 um 19:47 schrieb Li, Samuel:
>>>>>> No that isn't correct. Pinning just notes that the BO shouldn't be
>>>>>> moved any more. It doesn't wait for anything.
>>>>> It does. The following is from amdgpu_gem_prime_pin(),
>>>>> 91 * Wait for all shared fences to complete before we switch to
>> future
>>>>> 92 * use of exclusive fence on this prime shared bo.
>>>>> 93 */
>>>>> 94 ret = reservation_object_wait_timeout_rcu(bo->tbo.resv, true,
>>>> false,
>>>>> 95 MAX_SCHEDULE_TIMEOUT);
>>>>> 96 if (unlikely(ret < 0)) {
>>>>> 97 DRM_DEBUG_PRIME("Fence wait failed: %li\n", ret);
>>>>> 98 amdgpu_bo_unreserve(bo);
>>>>> 99 return ret;
>>>>> 100 }
>>>>>
>>>>> Besides, pinning process prepares all the stuff before and after
>>>>> moving buffer(ttm_bo_validate, amdgpu_ttm_bind),
>>>> No, you misunderstood what this is good for.
>>>>
>>>> The waiting done here is only for the shared fence to switch from
>>>> explicitly to implicitly synchronization for correct interaction with the Intel
>> driver.
>>>> As soon the the BO is exported that shouldn't wait for anything any more.
>>>>
>>>>> I think if a buffer can be moved, it is probably also in a good
>>>>> condition to be
>>>> accessed.
>>>>
>>>> That is complete nonsense.
>>>>
>>>> ttm_bo_validate() is an asynchronous operation to enable GPU access
>>>> to the BO, it isn't related at all to possible CPU access and can
>>>> actually prevent it a number of cases.
>>>>
>>>> amdgpu_ttm_bind() in turn binds the BO to the GART space and isn't
>>>> related to CPU access either.
>>>>
>>>> What you most likely need to do here is to use
>>>> reservation_object_wait_timeout_rcu() to wait for all GPU operations to
>> end.
>>>> Regards,
>>>> Christian.
>>>>
>>>>> Sam
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Koenig, Christian
>>>>>> Sent: Wednesday, September 20, 2017 1:38 PM
>>>>>> To: Li, Samuel <Samuel.Li at amd.com>; amd-gfx at lists.freedesktop.org
>>>>>> Subject: Re: [PATCH v2 1/1] drm/amdgpu: Add gem_prime_mmap
>>>> support
>>>>>> Am 20.09.2017 um 19:34 schrieb Li, Samuel:
>>>>>>>> If that is what this callback should do then this implementation
>>>>>>>> would be incorrect. Pinning doesn't wait for any GPU operation to
>>>> finish.
>>>>>>> During pining, it will all the fences to finish. That shall be OK.
>>>>>> No that isn't correct. Pinning just notes that the BO shouldn't be
>>>>>> moved any more.
>>>>>>
>>>>>> It doesn't wait for anything.
>>>>>>
>>>>>> Christian.
>>>>>>
>>>>>>> Sam
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Koenig, Christian
>>>>>>>> Sent: Wednesday, September 20, 2017 12:21 PM
>>>>>>>> To: Li, Samuel <Samuel.Li at amd.com>; amd-
>> gfx at lists.freedesktop.org
>>>>>>>> Subject: Re: [PATCH v2 1/1] drm/amdgpu: Add gem_prime_mmap
>>>>>> support
>>>>>>>> Am 20.09.2017 um 17:44 schrieb Li, Samuel:
>>>>>>>>>> What happens when another thread is using
>> amdgpu_dmabuf_ops
>>>> to
>>>>>> call
>>>>>>>>>> begin_cpu_access/end_cpu_access when you are fixing it up
>> again?
>>>>>>>>> Right, that is an issue.
>>>>>>>> A simple "if (!amdgpu_dmabuf_ops.begin_cpu_access)" should be
>>>> able
>>>>>> to
>>>>>>>> deal with that.
>>>>>>>>
>>>>>>>>>> I would just completely drop the two callbacks, pinning is not
>>>>>>>>>> necessary for CPU access and thinking more about it it actually
>>>>>>>>>> has some unwanted side effects.
>>>>>>>>> CPU access needs synchronization anyway, so the two callbacks
>>>>>>>>> cannot be
>>>>>>>> dropped (other drivers implemented too), so I would like to keep
>>>>>>>> it there for now.
>>>>>>>>
>>>>>>>> Wait a second what do you mean with "CPU access needs
>>>>>> synchronization"?
>>>>>>>> At least i915 makes the memory GPU inaccessible when you start to
>>>>>>>> use it with the CPU.
>>>>>>>>
>>>>>>>> If that is what this callback should do then this implementation
>>>>>>>> would be incorrect. Pinning doesn't wait for any GPU operation to
>>>> finish.
>>>>>>>> Regards,
>>>>>>>> Christian.
>>>>>>>>
>>>>>>>>> Sam
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Koenig, Christian
>>>>>>>>>> Sent: Wednesday, September 20, 2017 2:58 AM
>>>>>>>>>> To: Li, Samuel <Samuel.Li at amd.com>; amd-
>>>> gfx at lists.freedesktop.org
>>>>>>>>>> Subject: Re: [PATCH v2 1/1] drm/amdgpu: Add
>> gem_prime_mmap
>>>>>>>> support
>>>>>>>>>>> What do you mean "This isn't race free"?
>>>>>>>>>> Take a look at the code again:
>>>>>>>>>>> + dma_buf = drm_gem_prime_export(dev, gobj, flags);
>>>>>>>>>>> + amdgpu_dmabuf_ops = *(dma_buf->ops);
>>>>>>>>>>> + amdgpu_dmabuf_ops.begin_cpu_access =
>>>>>>>>>> amdgpu_gem_begin_cpu_access;
>>>>>>>>>>> + amdgpu_dmabuf_ops.end_cpu_access =
>>>>>>>>>> amdgpu_gem_end_cpu_access;
>>>>>>>>>>> + dma_buf->ops = &amdgpu_dmabuf_ops;
>>>>>>>>>> What happens when another thread is using
>> amdgpu_dmabuf_ops
>>>> to
>>>>>> call
>>>>>>>>>> begin_cpu_access/end_cpu_access when you are fixing it up
>> again?
>>>>>>>>>> I would just completely drop the two callbacks, pinning is not
>>>>>>>>>> necessary for CPU access and thinking more about it it actually
>>>>>>>>>> has some unwanted side effects.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Christian.
>>>>>>>>>>
>>>>>>>>>> Am 19.09.2017 um 23:22 schrieb Samuel Li:
>>>>>>>>>>>>> + vma->vm_pgoff = amdgpu_bo_mmap_offset(bo) >>
>>>>>> PAGE_SHIFT;
>>>>>>>>>>>> Maybe better use "vma->vm_pgoff +=
>>>>>>>> amdgpu_bo_mmap_offset(bo) >>
>>>>>>>>>> PAGE_SHIFT;", but I'm not sure.
>>>>>>>>>>>> How other drivers handle this?
>>>>>>>>>>> This is a good catch. Looks like pgoff is honored during prime
>>>>>>>>>>> mmap, not a
>>>>>>>>>> fake offset here.
>>>>>>>>>>>>> + dma_buf->ops = &amdgpu_dmabuf_ops;
>>>>>>>>>>>> This isn't race free and needs to be fixed.
>>>>>>>>>>>> Better add callbacks to drm_prime.c similar to
>>>>>>>>>> drm_gem_dmabuf_mmap().
>>>>>>>>>>> What do you mean "This isn't race free"?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Sam
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2017-09-15 11:05 AM, Christian König wrote:
>>>>>>>>>>>> Am 14.09.2017 um 00:39 schrieb Samuel Li:
>>>>>>>>>>>>> v2: drop hdp invalidate/flush.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Samuel Li <Samuel.Li at amd.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 ++
>>>>>>>>>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +-
>>>>>>>>>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 77
>>>>>>>>>> ++++++++++++++++++++++++++++++-
>>>>>>>>>>>>> 3 files changed, 81 insertions(+), 2 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>>>>>>>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>>>>>>>>>>> index d2aaad7..188b705 100644
>>>>>>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>>>>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>>>>>>>>>>>> @@ -395,11 +395,14 @@
>>>>>>>> amdgpu_gem_prime_import_sg_table(struct
>>>>>>>>>> drm_device *dev,
>>>>>>>>>>>>> struct dma_buf *amdgpu_gem_prime_export(struct
>>>>>> drm_device
>>>>>>>> *dev,
>>>>>>>>>>>>> struct drm_gem_object *gobj,
>>>>>>>>>>>>> int flags);
>>>>>>>>>>>>> +struct drm_gem_object
>> *amdgpu_gem_prime_import(struct
>>>>>>>>>> drm_device *dev,
>>>>>>>>>>>>> + struct dma_buf *dma_buf);
>>>>>>>>>>>>> int amdgpu_gem_prime_pin(struct drm_gem_object
>> *obj);
>>>>>>>>>>>>> void amdgpu_gem_prime_unpin(struct drm_gem_object
>>>> *obj);
>>>>>>>>>>>>> struct reservation_object
>>>>>>>>>>>>> *amdgpu_gem_prime_res_obj(struct
>>>>>>>>>> drm_gem_object *);
>>>>>>>>>>>>> void *amdgpu_gem_prime_vmap(struct drm_gem_object
>>>> *obj);
>>>>>>>>>>>>> void amdgpu_gem_prime_vunmap(struct
>> drm_gem_object
>>>>>> *obj,
>>>>>>>> void
>>>>>>>>>>>>> *vaddr);
>>>>>>>>>>>>> +int amdgpu_gem_prime_mmap(struct drm_gem_object
>> *obj,
>>>>>> struct
>>>>>>>>>>>>> +vm_area_struct *vma);
>>>>>>>>>>>>> int amdgpu_gem_debugfs_init(struct amdgpu_device
>> *adev);
>>>>>>>>>>>>> /* sub-allocation manager, it has to be protected
>>>>>>>>>>>>> by another
>>>>>> lock.
>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>>>>>>>>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>>>>>>>>>>>> index 2cdf844..9b63ac5 100644
>>>>>>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>>>>>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>>>>>>>>>>>> @@ -835,7 +835,7 @@ static struct drm_driver kms_driver = {
>>>>>>>>>>>>> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>>>>>>>>>>>>> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>>>>>>>>>>>>> .gem_prime_export = amdgpu_gem_prime_export,
>>>>>>>>>>>>> - .gem_prime_import = drm_gem_prime_import,
>>>>>>>>>>>>> + .gem_prime_import = amdgpu_gem_prime_import,
>>>>>>>>>>>>> .gem_prime_pin = amdgpu_gem_prime_pin,
>>>>>>>>>>>>> .gem_prime_unpin = amdgpu_gem_prime_unpin,
>>>>>>>>>>>>> .gem_prime_res_obj = amdgpu_gem_prime_res_obj,
>> @@
>>>>>>>>>>>>> -843,6
>>>>>>>>>>>>> +843,7 @@ static struct drm_driver kms_driver = {
>>>>>>>>>>>>> .gem_prime_import_sg_table =
>>>>>>>>>> amdgpu_gem_prime_import_sg_table,
>>>>>>>>>>>>> .gem_prime_vmap = amdgpu_gem_prime_vmap,
>>>>>>>>>>>>> .gem_prime_vunmap = amdgpu_gem_prime_vunmap,
>>>>>>>>>>>>> + .gem_prime_mmap = amdgpu_gem_prime_mmap,
>>>>>>>>>>>>> .name = DRIVER_NAME,
>>>>>>>>>>>>> .desc = DRIVER_DESC, diff --git
>>>>>>>>>>>>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
>>>>>>>>>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
>>>>>>>>>>>>> index 5b3f928..13c977a 100644
>>>>>>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
>>>>>>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
>>>>>>>>>>>>> @@ -57,6 +57,40 @@ void
>> amdgpu_gem_prime_vunmap(struct
>>>>>>>>>> drm_gem_object *obj, void *vaddr)
>>>>>>>>>>>>> ttm_bo_kunmap(&bo->dma_buf_vmap);
>>>>>>>>>>>>> }
>>>>>>>>>>>>> +int amdgpu_gem_prime_mmap(struct drm_gem_object
>>>> *obj,
>>>>>>>> struct
>>>>>>>>>>>>> vm_area_struct *vma)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
>>>>>>>>>>>>> + struct amdgpu_device *adev = amdgpu_ttm_adev(bo-
>>>>>>> tbo.bdev);
>>>>>>>>>>>>> + unsigned asize = amdgpu_bo_size(bo);
>>>>>>>>>>>>> + int ret;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (!vma->vm_file)
>>>>>>>>>>>>> + return -ENODEV;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (adev == NULL)
>>>>>>>>>>>>> + return -ENODEV;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + /* Check for valid size. */
>>>>>>>>>>>>> + if (asize < vma->vm_end - vma->vm_start)
>>>>>>>>>>>>> + return -EINVAL;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
>>>>>>>>>>>>> + (bo->flags &
>> AMDGPU_GEM_CREATE_NO_CPU_ACCESS)) {
>>>>>>>>>>>>> + return -EPERM;
>>>>>>>>>>>>> + }
>>>>>>>>>>>>> + vma->vm_pgoff = amdgpu_bo_mmap_offset(bo) >>
>>>>>> PAGE_SHIFT;
>>>>>>>>>>>> Maybe better use "vma->vm_pgoff +=
>>>>>>>> amdgpu_bo_mmap_offset(bo) >>
>>>>>>>>>> PAGE_SHIFT;", but I'm not sure.
>>>>>>>>>>>> How other drivers handle this?
>>>>>>>>>>>>
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + /* prime mmap does not need to check access, so allow
>>>>>>>>>>>>> + here
>>>> */
>>>>>>>>>>>>> + ret = drm_vma_node_allow(&obj->vma_node, vma-
>>>>> vm_file-
>>>>>>>>>>> private_data);
>>>>>>>>>>>>> + if (ret)
>>>>>>>>>>>>> + return ret;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + ret = ttm_bo_mmap(vma->vm_file, vma, &adev-
>>>>> mman.bdev);
>>>>>>>>>>>>> + drm_vma_node_revoke(&obj->vma_node,
>>>>>>>>>>>>> + vma->vm_file->private_data);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + return ret;
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> struct drm_gem_object *
>>>>>>>>>>>>> amdgpu_gem_prime_import_sg_table(struct drm_device
>>>> *dev,
>>>>>>>>>>>>> struct dma_buf_attachment *attach,
>>>>>>>>>>>>> @@
>>>>>>>>>>>>> -130,14
>>>>>>>>>>>>> +164,55 @@ struct reservation_object
>>>>>>>>>> *amdgpu_gem_prime_res_obj(struct drm_gem_object *obj)
>>>>>>>>>>>>> return bo->tbo.resv;
>>>>>>>>>>>>> }
>>>>>>>>>>>>> +static int amdgpu_gem_begin_cpu_access(struct
>>>>>>>>>>>>> dma_buf *dma_buf, enum dma_data_direction direction)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> + return amdgpu_gem_prime_pin(dma_buf->priv);
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static int amdgpu_gem_end_cpu_access(struct dma_buf
>>>>>> *dma_buf,
>>>>>>>>>> enum
>>>>>>>>>>>>> +dma_data_direction direction) {
>>>>>>>>>>>>> + amdgpu_gem_prime_unpin(dma_buf->priv);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + return 0;
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +static struct dma_buf_ops amdgpu_dmabuf_ops;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> struct dma_buf *amdgpu_gem_prime_export(struct
>>>>>> drm_device
>>>>>>>> *dev,
>>>>>>>>>>>>> struct drm_gem_object *gobj,
>>>>>>>>>>>>> int flags)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> struct amdgpu_bo *bo = gem_to_amdgpu_bo(gobj);
>>>>>>>>>>>>> + struct dma_buf *dma_buf;
>>>>>>>>>>>>> if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm))
>>>>>>>>>>>>> return ERR_PTR(-EPERM);
>>>>>>>>>>>>> - return drm_gem_prime_export(dev, gobj, flags);
>>>>>>>>>>>>> + dma_buf = drm_gem_prime_export(dev, gobj, flags);
>>>>>>>>>>>>> + amdgpu_dmabuf_ops = *(dma_buf->ops);
>>>>>>>>>>>>> + amdgpu_dmabuf_ops.begin_cpu_access =
>>>>>>>>>> amdgpu_gem_begin_cpu_access;
>>>>>>>>>>>>> + amdgpu_dmabuf_ops.end_cpu_access =
>>>>>>>>>> amdgpu_gem_end_cpu_access;
>>>>>>>>>>>>> + dma_buf->ops = &amdgpu_dmabuf_ops;
>>>>>>>>>>>> This isn't race free and needs to be fixed.
>>>>>>>>>>>>
>>>>>>>>>>>> Better add callbacks to drm_prime.c similar to
>>>>>>>>>> drm_gem_dmabuf_mmap().
>>>>>>>>>>>> Alternative you could just completely drop
>>>>>>>>>> amdgpu_gem_begin_cpu_access() and
>>>>>> amdgpu_gem_end_cpu_access()
>>>>>>>> as
>>>>>>>>>> well.
>>>>>>>>>>>> When the buffer is shared between device it is pinned anyway
>>>>>>>>>>>> and when
>>>>>>>>>> it isn't shared ttm_bo_mmap() is able to handle VRAM mappings
>>>>>>>>>> as
>>>>>> well.
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Christian.
>>>>>>>>>>>>
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + return dma_buf;
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +struct drm_gem_object
>> *amdgpu_gem_prime_import(struct
>>>>>>>>>> drm_device *dev,
>>>>>>>>>>>>> + struct dma_buf *dma_buf) {
>>>>>>>>>>>>> + struct drm_gem_object *obj;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + if (dma_buf->ops == &amdgpu_dmabuf_ops) {
>>>>>>>>>>>>> + obj = dma_buf->priv;
>>>>>>>>>>>>> + if (obj->dev == dev) {
>>>>>>>>>>>>> + /*
>>>>>>>>>>>>> + * Importing dmabuf exported from out own gem
>>>> increases
>>>>>>>>>>>>> + * refcount on gem itself instead of f_count of dmabuf.
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> + drm_gem_object_get(obj);
>>>>>>>>>>>>> + return obj;
>>>>>>>>>>>>> + }
>>>>>>>>>>>>> + }
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + return drm_gem_prime_import(dev, dma_buf);
>>>>>>>>>>>>> }
>>>>> _______________________________________________
>>>>> amd-gfx mailing list
>>>>> amd-gfx at lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
More information about the amd-gfx
mailing list