[PATCH] drm/gem-shmem: Optimize DMA mapping for exported buffers

Christian König christian.koenig at amd.com
Tue Mar 25 15:38:30 UTC 2025


Am 25.03.25 um 16:33 schrieb Jacek Lawrynowicz:
> Hi,
>
> On 3/25/2025 2:53 PM, Christian König wrote:
>> Am 25.03.25 um 14:37 schrieb Jacek Lawrynowicz:
>>> Use DMA_ATTR_SKIP_CPU_SYNC flag for exported buffers during DMA mapping.
>>> The same flag is already used by drm_gem_map_dma_buf() for imported
>>> buffers.
>>>
>>> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz at linux.intel.com>
>>> ---
>>>  drivers/gpu/drm/drm_gem_shmem_helper.c |  8 ++++++--
>>>  include/drm/drm_gem.h                  | 12 ++++++++++++
>>>  2 files changed, 18 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> index d99dee67353a1..8938d8e3de52f 100644
>>> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> @@ -699,7 +699,7 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
>>>  static struct sg_table *drm_gem_shmem_get_pages_sgt_locked(struct drm_gem_shmem_object *shmem)
>>>  {
>>>  	struct drm_gem_object *obj = &shmem->base;
>>> -	int ret;
>>> +	int ret, flags = 0;
>>>  	struct sg_table *sgt;
>>>  
>>>  	if (shmem->sgt)
>>> @@ -716,8 +716,12 @@ static struct sg_table *drm_gem_shmem_get_pages_sgt_locked(struct drm_gem_shmem_
>>>  		ret = PTR_ERR(sgt);
>>>  		goto err_put_pages;
>>>  	}
>>> +
>>> +	if (drm_gem_is_exported())
>>> +		flags |= DMA_ATTR_SKIP_CPU_SYNC;
>> We should probably just unconditionally set this flag or not at all.
>>
>> Otherwise we could run into quite some surprises.
> I see that this flag is usually set in drm_gem_map_dma_buf() and similar callbacks across drm drivers.
> Shouldn't it be the default on x86?

Not really, no. If you can skip CPU sync depends on the platform.

On x86 it's correct that almost all devices are coherent with the CPU cache, but that isn't always the case.

The device driver using the GEM shmem helper needs to decide if that is ok or not.

Regards,
Christian.

>
> Regards,
> Jacek



More information about the dri-devel mailing list