Fixing SDMA TO after GPU reset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



By current code logic job->vm_pd_addr is never going to be set unless 
the job is created for user SC or for buffer copy in amdgpu_copy_buffer
So in any other case we are going to skip VM flush. But amdgpu_vm_flush 
wants a flush to happen in case GPU reset just happend 
(amdgpu_vmid_had_gpu_reset is true)
so we will be skipping that VM flush (as in my case with 
amdgpu_driver_open_kms->amdgpu_vm_init->amdgpu_vm_clear_bo right after 
GPU reset occured)
Is it safe ?

Andrey

On 09/11/2018 07:46 AM, Christian König wrote:
> It would probably be better to initialize job->vm_pd_addr with 
> AMDGPU_BO_INVALID_OFFSET.
>
> And then just drop the vm flush alltogether when the vm_pd_addr isn't 
> set to something sane.
>
> Thanks,
> Christian.
>
> Am 11.09.2018 um 00:52 schrieb Andrey Grodzovsky:
>> Attached patch fixes SDMA TO after GPU reset, it's a regression 
>> caused by cbd5285 drm/amdgpu: move setting the GART addr into TTM.
>>
>> But to me it looks safer just to revert the original patch all 
>> together since we never can predict for sure if VM flush will take 
>> place and so it's safer to just always assign job->vm_pd_addr.
>>
>> Andrey
>>
>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180911/7ae0ac36/attachment-0001.html>


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux