2022-08-31 15:43:48

by Dmitry Osipenko

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

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 <[email protected]>
---
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:
--
2.37.2

2022-09-01 07:39:48

by Christian König

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

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 <[email protected]>

Interesting, where is the matching vmap()?

Anyway, this patch is Acked-by: Christian König <[email protected]>

> ---
> 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:

2022-09-01 11:56:09

by Dmitry Osipenko

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

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 <[email protected]>
>
> Interesting, where is the matching vmap()?
>
> Anyway, this patch is Acked-by: Christian König <[email protected]>

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