if we don't block device open while gpu doing recover, the vm init (SDMA
working on page table creating) would be ruined by ASIC RESET
That is not a problem at all. SDMA just does some clear operation on the
page tables and those are either recovered from the shadow or run after
the reset.
Regards,
Christian.
Am 26.10.2017 um 10:17 schrieb Liu, Monk:
When amdgpu_gpu_recover() routine is in the fly, we shouldn't let UMD open our
device, otherwise the VM init would be ruined by gpu_recover().
e.g. VM init need to create page table, but keep In mind that gpu_recover()
calls ASIC RESET,
if we don't block device open while gpu doing recover, the vm init (SDMA
working on page table creating) would be ruined by ASIC RESET
do you have any good solution ? the key point is avoid/delay/push_back hw
activities from UMD side when we are running in gpu_recover() function
BR Monk
-----Original Message-----
From: Christian König [mailto:[email protected]]
Sent: 2017年10月26日 15:18
To: Liu, Monk <[email protected]>; [email protected]
Subject: Re: [PATCH 7/9] drm/amdgpu:block kms open during gpu_reset
NAK, why the heck should we do this? It would just block all new processes from
using the device.
Christian.
Am 25.10.2017 um 11:22 schrieb Monk Liu:
Change-Id: Ibdb0ea9e3769d572fbbc13bbf1ef73f1af2ab7be
Signed-off-by: Monk Liu <[email protected]>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 4a9f749..c155ce4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -813,6 +813,9 @@ int amdgpu_driver_open_kms(struct drm_device *dev, struct
drm_file *file_priv)
if (r < 0)
return r;
+ if (adev->in_gpu_reset)
+ return -ENODEV;
+
fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
if (unlikely(!fpriv)) {
r = -ENOMEM;
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
