Skip to contentSkip to conversation

drm/amdgpu: give more chance for tlb flush if failed

PATCH In review Emily Deng 3 participants 5 messages Mar 20, 2018 – Mar 23, 2018 4 messages not in the archive

Subsystems (2)
lore
Share & tools
lore

Emily Deng

author
#0 lore raw

PATCH 1/1 drm/amdgpu: give more chance for tlb flush if failed

under SR-IOV sometimes CPU based tlb flush would timeout within the given 100ms period, instead let it fail and continue we can give it more chance to repeat the tlb flush on the failed VMHUB

this could fix the massive "Timeout waiting for VM flush ACK" error during vk_encoder test.

---
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +19 -5
index a70cbc4..517712b 100644
@@ -329,13 +329,18 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,
 {
 	/* Use register 17 for GART */
 	const unsigned eng = 17;
-	unsigned i, j;
+	unsigned i, j, loop = 0;
+	unsigned flush_done = 0;
+
+retry:
 
 	spin_lock(&adev->gmc.invalidate_lock);
 
 	for (i = 0; i < AMDGPU_MAX_VMHUBS; ++i) {
 		struct amdgpu_vmhub *hub = &adev->vmhub[i];
 		u32 tmp = gmc_v9_0_get_invalidate_req(vmid);
+		if (flush_done & (1 << i)) /* this vmhub flushed */
+			continue;
 
 		WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);
 
@@ -347,8 +352,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,
 				break;
 			cpu_relax();
 		}
-		if (j < 100)
+		if (j < 100) {
+			flush_done |= (1 << i);
 			continue;
+		}
 
 		/* Wait for ACK with a delay.*/
 		for (j = 0; j < adev->usec_timeout; j++) {
@@ -358,15 +365,22 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,
 				break;
 			udelay(1);
 		}
-		if (j < adev->usec_timeout)
+		if (j < adev->usec_timeout) {
+			flush_done |= (1 << i);
 			continue;
-
-		DRM_ERROR("Timeout waiting for VM flush ACK!\n");
+		}
 	}
 
 	spin_unlock(&adev->gmc.invalidate_lock);
+	if (flush_done != 3) {
+		if (loop++ < 3)
+			goto retry;
+		else
+			DRM_ERROR("Timeout waiting for VM flush ACK!\n");
+	}
 }
 
+
 static uint64_t gmc_v9_0_emit_flush_gpu_tlb(struct amdgpu_ring *ring,
 					    unsigned vmid, uint64_t pd_addr)
 {
Signature · 6 lines
2.7.4

_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

A message that is not in the archive (sent off-list or not yet received): 1521527344-25641-1-git-send-email-Emily.Deng-5C7GfCeVMHo@public.gmane.org

#2 lore raw

Am 20.03.2018 um 07:29 schrieb Emily Deng:

Quoted 7 lines

under SR-IOV sometimes CPU based tlb flush would timeout within the given 100ms period, instead let it fail and continue we can give it more chance to repeat the tlb flush on the failed VMHUB

this could fix the massive "Timeout waiting for VM flush ACK" error during vk_encoder test.

Well that one is a big NAK since it once more just hides the real problem that we sometimes drop register writes.

What we did during debugging to avoid the problem is the following:

Quoted 15 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +4 -0
index a70cbc45c4c1..3536d50375fa 100644
@@ -338,6 +338,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct 
 amdgpu_device *adev,
                 u32 tmp = gmc_v9_0_get_invalidate_req(vmid);
 
                 WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);
+               while (RREG32_NO_KIQ(hub->vm_inv_eng0_req + eng) != tmp) {
+                       DRM_ERROR("Need one more try to write the 
 VMHUB flush request!");
+                       WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);
+               }
 
Quoted 2 lines

                /* Busy wait for ACK.*/
                for (j = 0; j < 100; j++) {

But that can only be a temporary workaround as well.

The question is rather can you reliable reproduce this issue with the vk_encoder test?

Thanks,
Christian.

Quoted 58 lines
---
  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 24 +++++++++++++++++++-----
  1 file changed, 19 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +14 -5
index a70cbc4..517712b 100644
@@ -329,13 +329,18 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,
  {
  	/* Use register 17 for GART */
  	const unsigned eng = 17;
-	unsigned i, j;
+	unsigned i, j, loop = 0;
+	unsigned flush_done = 0;
+
+retry:
 
  	spin_lock(&adev->gmc.invalidate_lock);
 
  	for (i = 0; i < AMDGPU_MAX_VMHUBS; ++i) {
  		struct amdgpu_vmhub *hub = &adev->vmhub[i];
  		u32 tmp = gmc_v9_0_get_invalidate_req(vmid);
+		if (flush_done & (1 << i)) /* this vmhub flushed */
+			continue;
 
  		WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);
 
@@ -347,8 +352,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,
  				break;
  			cpu_relax();
  		}
-		if (j < 100)
+		if (j < 100) {
+			flush_done |= (1 << i);
  			continue;
+		}
 
  		/* Wait for ACK with a delay.*/
  		for (j = 0; j < adev->usec_timeout; j++) {
@@ -358,15 +365,22 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,
  				break;
  			udelay(1);
  		}
-		if (j < adev->usec_timeout)
+		if (j < adev->usec_timeout) {
+			flush_done |= (1 << i);
  			continue;
-
-		DRM_ERROR("Timeout waiting for VM flush ACK!\n");
+		}
  	}
 
  	spin_unlock(&adev->gmc.invalidate_lock);
+	if (flush_done != 3) {
+		if (loop++ < 3)

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev, · line 386

Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +5 -0
+			goto retry;
+		else
+			DRM_ERROR("Timeout waiting for VM flush ACK!\n");
+	}
  }
 
+
  static uint64_t gmc_v9_0_emit_flush_gpu_tlb(struct amdgpu_ring *ring,
  					    unsigned vmid, uint64_t pd_addr)
  {

_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

A message that is not in the archive (sent off-list or not yet received): 1a54a624-2816-c03f-bc75-da30be2ae48e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

#4 lore raw

Hi Christian,
I agree with that the patch will hide the real problem, it is just a workaround, I will change the patch as you suggest.
as the sriov has lots of issues on the staging, maybe we could first submit the two workarounds, later, I will spend some time to find out the root cause.
I think the issue reproduce is reliable.

Best Wishes,
Emily Deng

Quoted 117 lines

-----Original Message-----
From: Christian König [mailto:[email protected]]
Sent: Tuesday, March 20, 2018 6:24 PM
To: Deng, Emily <[email protected]>; [email protected]
Cc: Liu, Monk <[email protected]>
Subject: Re: [PATCH] drm/amdgpu: give more chance for tlb flush if failed

Am 20.03.2018 um 07:29 schrieb Emily Deng:

Quoted 6 lines

under SR-IOV sometimes CPU based tlb flush would timeout within the given 100ms period, instead let it fail and continue we can give it more chance to repeat the tlb flush on the failed VMHUB

this could fix the massive "Timeout waiting for VM flush ACK" error during vk_encoder test.

Well that one is a big NAK since it once more just hides the real problem that we sometimes drop register writes.

What we did during debugging to avoid the problem is the following:

Quoted 18 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6 -0
index a70cbc45c4c1..3536d50375fa 100644
@@ -338,6 +338,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct
 amdgpu_device *adev,
                 u32 tmp = gmc_v9_0_get_invalidate_req(vmid);
 
                 WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);
+               while (RREG32_NO_KIQ(hub->vm_inv_eng0_req + eng) !=
+tmp) {
+                       DRM_ERROR("Need one more try to write the
 VMHUB flush request!");
+                       WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng,
+tmp);
+               }
Quoted 2 lines

                /* Busy wait for ACK.*/
                for (j = 0; j < 100; j++) {

But that can only be a temporary workaround as well.

The question is rather can you reliable reproduce this issue with the vk_encoder test?

Thanks,
Christian.

Quoted 4 lines
---
  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 24 +++++++++++++++++++--

---

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct

Quoted 8 lines
  1 file changed, 19 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +0 -0
index a70cbc4..517712b 100644
@@ -329,13 +329,18 @@ static void gmc_v9_0_flush_gpu_tlb(struct

amdgpu_device *adev,

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct

Quoted 20 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6 -1
  {
  	/* Use register 17 for GART */
  	const unsigned eng = 17;
-	unsigned i, j;
+	unsigned i, j, loop = 0;
+	unsigned flush_done = 0;
+
+retry:
 
  	spin_lock(&adev->gmc.invalidate_lock);
 
  	for (i = 0; i < AMDGPU_MAX_VMHUBS; ++i) {
  		struct amdgpu_vmhub *hub = &adev->vmhub[i];
  		u32 tmp = gmc_v9_0_get_invalidate_req(vmid);
+		if (flush_done & (1 << i)) /* this vmhub flushed */
+			continue;
 
  		WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);
 
@@ -347,8 +352,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct

amdgpu_device *adev,

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,

Quoted 11 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +3 -1
  				break;
  			cpu_relax();
  		}
-		if (j < 100)
+		if (j < 100) {
+			flush_done |= (1 << i);
  			continue;
+		}
 
  		/* Wait for ACK with a delay.*/
  		for (j = 0; j < adev->usec_timeout; j++) { @@ -358,15 +365,22

@@

Quoted 22 lines

static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,
break;
udelay(1);
}

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +9 -3
-		if (j < adev->usec_timeout)
+		if (j < adev->usec_timeout) {
+			flush_done |= (1 << i);
  			continue;
-
-		DRM_ERROR("Timeout waiting for VM flush ACK!\n");
+		}
  	}
 
  	spin_unlock(&adev->gmc.invalidate_lock);
+	if (flush_done != 3) {
+		if (loop++ < 3)
+			goto retry;
+		else
+			DRM_ERROR("Timeout waiting for VM flush ACK!\n");
+	}
  }
Quoted 4 lines
Quoted 4 lines

+
static uint64_t gmc_v9_0_emit_flush_gpu_tlb(struct amdgpu_ring *ring,
unsigned vmid, uint64_t pd_addr)
{

_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

A message that is not in the archive (sent off-list or not yet received): CY4PR12MB112582B8413D7323ADCDD97C8FA90-rpdhrqHFk07v2MZdTKcfDgdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org

#6 lore raw
Quoted 1 line

I think the issue reproduce is reliable.

That is the really important thing.

We had the same issues with bare metal and working around them one by one didn't helped at all in the long run (e.g. Vega10 was still horrible unstable).

The only real solution was finding the root cause and eliminating it. For this issue as well as the one Monk investigated it turned out that reading some registers can cause problems when there are concurrent writes going on. E.g. the register read times out and leads to the write being dropped.

If those issues prevail even after eliminating all potential causes on your side we should probably setup a call with some hw people to discuss how to proceed further.

Regards,
Christian.

Am 22.03.2018 um 04:50 schrieb Deng, Emily:

Quoted 124 lines

Hi Christian,
I agree with that the patch will hide the real problem, it is just a workaround, I will change the patch as you suggest.
as the sriov has lots of issues on the staging, maybe we could first submit the two workarounds, later, I will spend some time to find out the root cause.
I think the issue reproduce is reliable.

Best Wishes,
Emily Deng

Quoted 114 lines

-----Original Message-----
From: Christian König [mailto:[email protected]]
Sent: Tuesday, March 20, 2018 6:24 PM
To: Deng, Emily <[email protected]>; [email protected]
Cc: Liu, Monk <[email protected]>
Subject: Re: [PATCH] drm/amdgpu: give more chance for tlb flush if failed

Am 20.03.2018 um 07:29 schrieb Emily Deng:

Quoted 6 lines

under SR-IOV sometimes CPU based tlb flush would timeout within the given 100ms period, instead let it fail and continue we can give it more chance to repeat the tlb flush on the failed VMHUB

this could fix the massive "Timeout waiting for VM flush ACK" error during vk_encoder test.

Well that one is a big NAK since it once more just hides the real problem that we sometimes drop register writes.

What we did during debugging to avoid the problem is the following:

Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +0 -0
index a70cbc45c4c1..3536d50375fa 100644
@@ -338,6 +338,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct
 amdgpu_device *adev,
                 u32 tmp = gmc_v9_0_get_invalidate_req(vmid);
 
                 WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct

Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6 -0
+               while (RREG32_NO_KIQ(hub->vm_inv_eng0_req + eng) !=
+tmp) {
+                       DRM_ERROR("Need one more try to write the
 VMHUB flush request!");
+                       WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng,
+tmp);
+               }
 
                 /* Busy wait for ACK.*/
                 for (j = 0; j < 100; j++) {

But that can only be a temporary workaround as well.

The question is rather can you reliable reproduce this issue with the vk_encoder test?

Thanks,
Christian.

Quoted 3 lines
---
   drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 24 +++++++++++++++++++--

---

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct

Quoted 8 lines
   1 file changed, 19 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +0 -0
index a70cbc4..517712b 100644
@@ -329,13 +329,18 @@ static void gmc_v9_0_flush_gpu_tlb(struct

amdgpu_device *adev,

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct

Quoted 20 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6 -1
   {
   	/* Use register 17 for GART */
   	const unsigned eng = 17;
-	unsigned i, j;
+	unsigned i, j, loop = 0;
+	unsigned flush_done = 0;
+
+retry:
 
   	spin_lock(&adev->gmc.invalidate_lock);
 
   	for (i = 0; i < AMDGPU_MAX_VMHUBS; ++i) {
   		struct amdgpu_vmhub *hub = &adev->vmhub[i];
   		u32 tmp = gmc_v9_0_get_invalidate_req(vmid);
+		if (flush_done & (1 << i)) /* this vmhub flushed */
+			continue;
 
   		WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);
 
@@ -347,8 +352,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct

amdgpu_device *adev,

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,

Quoted 11 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +3 -1
   				break;
   			cpu_relax();
   		}
-		if (j < 100)
+		if (j < 100) {
+			flush_done |= (1 << i);
   			continue;
+		}
 
   		/* Wait for ACK with a delay.*/
   		for (j = 0; j < adev->usec_timeout; j++) { @@ -358,15 +365,22

@@

Quoted 22 lines

static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,

   				break;
   			udelay(1);
   		}
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +9 -3
-		if (j < adev->usec_timeout)
+		if (j < adev->usec_timeout) {
+			flush_done |= (1 << i);
   			continue;
-
-		DRM_ERROR("Timeout waiting for VM flush ACK!\n");
+		}
   	}
 
   	spin_unlock(&adev->gmc.invalidate_lock);
+	if (flush_done != 3) {
+		if (loop++ < 3)
+			goto retry;
+		else
+			DRM_ERROR("Timeout waiting for VM flush ACK!\n");
+	}
   }
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

+
static uint64_t gmc_v9_0_emit_flush_gpu_tlb(struct amdgpu_ring *ring,
unsigned vmid, uint64_t pd_addr)
{

_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

A message that is not in the archive (sent off-list or not yet received): 50377594-10f9-8aec-1b2b-acd974527503-5C7GfCeVMHo@public.gmane.org

#8 lore raw

Hi Christian,
Right, maybe we could learn something from hardware, and find out the root cause.

Best Wishes,
Emily Deng

Quoted 155 lines

-----Original Message-----
From: Koenig, Christian
Sent: Thursday, March 22, 2018 4:54 PM
To: Deng, Emily <[email protected]>; [email protected]
Cc: Liu, Monk <[email protected]>
Subject: Re: [PATCH] drm/amdgpu: give more chance for tlb flush if failed

Quoted 1 line

I think the issue reproduce is reliable.

That is the really important thing.

We had the same issues with bare metal and working around them one by one didn't helped at all in the long run (e.g. Vega10 was still horrible unstable).

The only real solution was finding the root cause and eliminating it. For this issue as well as the one Monk investigated it turned out that reading some registers can cause problems when there are concurrent writes going on. E.g. the register read times out and leads to the write being dropped.

If those issues prevail even after eliminating all potential causes on your side we should probably setup a call with some hw people to discuss how to proceed further.

Regards,
Christian.

Am 22.03.2018 um 04:50 schrieb Deng, Emily:

Quoted 2 lines

Hi Christian,
I agree with that the patch will hide the real problem, it is just a

workaround, I will change the patch as you suggest.

Quoted 2 lines

as the sriov has lots of issues on the staging, maybe we could first submit the two workarounds, later, I will spend some time to find out the

root cause.

Quoted 56 lines

I think the issue reproduce is reliable.

Best Wishes,
Emily Deng

Quoted 50 lines

-----Original Message-----
From: Christian König [mailto:[email protected]]
Sent: Tuesday, March 20, 2018 6:24 PM
To: Deng, Emily <[email protected]>; [email protected]
Cc: Liu, Monk <[email protected]>
Subject: Re: [PATCH] drm/amdgpu: give more chance for tlb flush if failed

Am 20.03.2018 um 07:29 schrieb Emily Deng:

Quoted 6 lines

under SR-IOV sometimes CPU based tlb flush would timeout within the given 100ms period, instead let it fail and continue we can give it more chance to repeat the tlb flush on the failed VMHUB

this could fix the massive "Timeout waiting for VM flush ACK" error during vk_encoder test.

Well that one is a big NAK since it once more just hides the real problem that we sometimes drop register writes.

What we did during debugging to avoid the problem is the following:

Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +0 -0
index a70cbc45c4c1..3536d50375fa 100644
@@ -338,6 +338,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct
 amdgpu_device *adev,
                 u32 tmp = gmc_v9_0_get_invalidate_req(vmid);
 
                 WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct

Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6 -0
+               while (RREG32_NO_KIQ(hub->vm_inv_eng0_req + eng) !=
+tmp) {
+                       DRM_ERROR("Need one more try to write the
 VMHUB flush request!");
+                       WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng,
+tmp);
+               }
 
                 /* Busy wait for ACK.*/
                 for (j = 0; j < 100; j++) {

But that can only be a temporary workaround as well.

The question is rather can you reliable reproduce this issue with the vk_encoder test?

Thanks,
Christian.

Quoted 3 lines
---
   drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 24

+++++++++++++++++++--

Quoted 65 lines
Quoted 65 lines

---

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct

Quoted 8 lines
   1 file changed, 19 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +0 -0
index a70cbc4..517712b 100644
@@ -329,13 +329,18 @@ static void gmc_v9_0_flush_gpu_tlb(struct

amdgpu_device *adev,

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct

Quoted 20 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +6 -1
   {
   	/* Use register 17 for GART */
   	const unsigned eng = 17;
-	unsigned i, j;
+	unsigned i, j, loop = 0;
+	unsigned flush_done = 0;
+
+retry:
 
   	spin_lock(&adev->gmc.invalidate_lock);
 
   	for (i = 0; i < AMDGPU_MAX_VMHUBS; ++i) {
   		struct amdgpu_vmhub *hub = &adev->vmhub[i];
   		u32 tmp = gmc_v9_0_get_invalidate_req(vmid);
+		if (flush_done & (1 << i)) /* this vmhub flushed */
+			continue;
 
   		WREG32_NO_KIQ(hub->vm_inv_eng0_req + eng, tmp);
 
@@ -347,8 +352,10 @@ static void gmc_v9_0_flush_gpu_tlb(struct

amdgpu_device *adev,

drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c static void gmc_v9_0_flush_gpu_tlb(struct · line 361

Quoted 11 lines
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +3 -1
   				break;
   			cpu_relax();
   		}
-		if (j < 100)
+		if (j < 100) {
+			flush_done |= (1 << i);
   			continue;
+		}
 
   		/* Wait for ACK with a delay.*/
   		for (j = 0; j < adev->usec_timeout; j++) { @@ -358,15 +365,22

@@

Quoted 22 lines

static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device *adev,

   				break;
   			udelay(1);
   		}
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +9 -3
-		if (j < adev->usec_timeout)
+		if (j < adev->usec_timeout) {
+			flush_done |= (1 << i);
   			continue;
-
-		DRM_ERROR("Timeout waiting for VM flush ACK!\n");
+		}
   	}
 
   	spin_unlock(&adev->gmc.invalidate_lock);
+	if (flush_done != 3) {
+		if (loop++ < 3)
+			goto retry;
+		else
+			DRM_ERROR("Timeout waiting for VM flush ACK!\n");
+	}
   }
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

+
static uint64_t gmc_v9_0_emit_flush_gpu_tlb(struct amdgpu_ring

*ring,

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
   					    unsigned vmid, uint64_t pd_addr)
   {

_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx