[Intel-gfx] [PATCH v4 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification

Dmitry Osipenko dmitry.osipenko at collabora.com
Thu Sep 1 10:41:21 UTC 2022


On 9/1/22 09:50, Christian König wrote:
> Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
>> Prepare Etnaviv driver to the common dynamic dma-buf locking convention
>> by starting to use the unlocked versions of dma-buf API functions.
>>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko at collabora.com>
> 
> Interesting, where is the matching vmap()?
> 
> Anyway, this patch is Acked-by: Christian König <christian.koenig at amd.com>

Etnaviv maps GEM only once and then unmaps it when GEM is destroyed. The
dma-buf vmapping should happen under the reservation lock, hence only
the release function needs to be changed to the unlocked variant.

Lucas/Christian(Gmeiner), could you please check that I haven't missed
anything?

>> ---
>>   drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> index 3fa2da149639..7031db145a77 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> @@ -65,7 +65,7 @@ static void etnaviv_gem_prime_release(struct
>> etnaviv_gem_object *etnaviv_obj)
>>       struct iosys_map map = IOSYS_MAP_INIT_VADDR(etnaviv_obj->vaddr);
>>         if (etnaviv_obj->vaddr)
>> -        dma_buf_vunmap(etnaviv_obj->base.import_attach->dmabuf, &map);
>> +       
>> dma_buf_vunmap_unlocked(etnaviv_obj->base.import_attach->dmabuf, &map);
>>         /* Don't drop the pages for imported dmabuf, as they are not
>>        * ours, just free the array we allocated:
> 


-- 
Best regards,
Dmitry


More information about the Intel-gfx mailing list