[PATCH] amdgpu/uvd: use kmemdup

[PATCH] amdgpu/uvd: use kmemdup

[Muhammad Falak R Wani]

Use kmemdup when some other buffer is immediately copied into allocated
region. It replaces call to allocation followed by memcpy, by a single
call to kmemdup.

Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 01abfc2..c977ab6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -295,12 +295,10 @@ int amdgpu_uvd_suspend(struct amdgpu_device *adev)
 	size = amdgpu_bo_size(adev->uvd.vcpu_bo);
 	ptr = adev->uvd.cpu_addr;
 
-	adev->uvd.saved_bo = kmalloc(size, GFP_KERNEL);
+	adev->uvd.saved_bo = kmemdup(ptr, size, GFP_KERNEL);
 	if (!adev->uvd.saved_bo)
 		return -ENOMEM;
 
-	memcpy(adev->uvd.saved_bo, ptr, size);
-
 	return 0;
 }
 
-- 
1.9.1

Re: [PATCH] amdgpu/uvd: use kmemdup

[Christian König]

Am 19.05.2016 um 13:11 schrieb Muhammad Falak R Wani:
> Use kmemdup when some other buffer is immediately copied into allocated
> region. It replaces call to allocation followed by memcpy, by a single
> call to kmemdup.
>
> Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>

NAK, actually using memcpy() is wrong in the first place.

The UVD BO is in VRAM so the pointer is pointing to IO memory here, so 
this should be memcpy_fromio() instead of memcpy().

Christian.

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> index 01abfc2..c977ab6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> @@ -295,12 +295,10 @@ int amdgpu_uvd_suspend(struct amdgpu_device *adev)
>   	size = amdgpu_bo_size(adev->uvd.vcpu_bo);
>   	ptr = adev->uvd.cpu_addr;
>   
> -	adev->uvd.saved_bo = kmalloc(size, GFP_KERNEL);
> +	adev->uvd.saved_bo = kmemdup(ptr, size, GFP_KERNEL);
>   	if (!adev->uvd.saved_bo)
>   		return -ENOMEM;
>   
> -	memcpy(adev->uvd.saved_bo, ptr, size);
> -
>   	return 0;
>   }
>   

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] amdgpu/uvd: use kmemdup

[Muhammad Falak R Wani]

On Thu, May 19, 2016 at 01:18:10PM +0200, Christian König wrote:
> Am 19.05.2016 um 13:11 schrieb Muhammad Falak R Wani:
> >Use kmemdup when some other buffer is immediately copied into allocated
> >region. It replaces call to allocation followed by memcpy, by a single
> >call to kmemdup.
> >
> >Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
> 
> NAK, actually using memcpy() is wrong in the first place.
> 
> The UVD BO is in VRAM so the pointer is pointing to IO memory here,
> so this should be memcpy_fromio() instead of memcpy().
> 
> Christian.
> 
Should I send V2 with the required changes, and I had a query, 
If memcpy was wrong, did it still work or it just got un-noticed ?

Re: [PATCH] amdgpu/uvd: use kmemdup

[Christian König]

Am 19.05.2016 um 13:49 schrieb Muhammad Falak R Wani:
> On Thu, May 19, 2016 at 01:18:10PM +0200, Christian König wrote:
>> Am 19.05.2016 um 13:11 schrieb Muhammad Falak R Wani:
>>> Use kmemdup when some other buffer is immediately copied into allocated
>>> region. It replaces call to allocation followed by memcpy, by a single
>>> call to kmemdup.
>>>
>>> Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
>> NAK, actually using memcpy() is wrong in the first place.
>>
>> The UVD BO is in VRAM so the pointer is pointing to IO memory here,
>> so this should be memcpy_fromio() instead of memcpy().
>>
>> Christian.
>>
> Should I send V2 with the required changes, and I had a query,

I can take care of fixing this.

> If memcpy was wrong, did it still work or it just got un-noticed ?

Both, on X86 memcpy from IO memory works fine. Only on other 
architectures you run into problems with that.

Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel