Loading
drm/amdgpu/userq: dont lock root bo with userq_mutex held
Do not hold reservation lock for root bo if userq_mutex is already held in the call flow this cause a lock issue with ttm_bo_delayed_delete. Its better to lock the vm->root.bo first and then go ahead with userq_mutex so userq_mutex threads dont get stuck until the reservation lock is held. In this case it helps in the function amdgpu_userq_buffer_vas_mapped for each queue during restore_all. Signed-off-by:Sunil Khatri <sunil.khatri@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>