* [PATCH] drm/amdgpu: limit reg_write_reg_wait workaround to SRIOV
@ 2018-04-17 13:01 Christian König
[not found] ` <20180417130135.1895-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Christian König @ 2018-04-17 13:01 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Turned out that this locks up some bare metal Vega10.
Signed-off-by: Christian König <christian.koenig@amd.com>
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 583f6f616dd3..5329d7e5fb71 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -4144,7 +4144,12 @@ static void gfx_v9_0_ring_emit_reg_write_reg_wait(struct amdgpu_ring *ring,
{
int usepfp = (ring->funcs->type == AMDGPU_RING_TYPE_GFX);
- gfx_v9_0_wait_reg_mem(ring, usepfp, 0, 1, reg0, reg1, ref, mask, 0x20);
+ if (amdgpu_sriov_vf(adev))
+ gfx_v9_0_wait_reg_mem(ring, usepfp, 0, 1, reg0, reg1,
+ ref, mask, 0x20);
+ else
+ amdgpu_ring_emit_reg_write_reg_wait_helper(ring, reg0, reg1,
+ ref, mask);
}
static void gfx_v9_0_set_gfx_eop_interrupt_state(struct amdgpu_device *adev,
--
2.14.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] drm/amdgpu: limit reg_write_reg_wait workaround to SRIOV
[not found] ` <20180417130135.1895-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
@ 2018-04-17 14:02 ` Deucher, Alexander
[not found] ` <DM5PR12MB1820165CD71A527EAA47C5F4F7B70-2J9CzHegvk8qWyLXlBb1HgdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Deucher, Alexander @ 2018-04-17 14:02 UTC (permalink / raw)
To: Christian König, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
Deng, Emily, Liu, Monk
[-- Attachment #1.1: Type: text/plain, Size: 2085 bytes --]
Does this actually work on SR-IOV? Or does it just seem to but nothing bad happens because we get a GPU reset on a world switch? The behavior of this packet should be the same as SDMA and that definitely doesn't work. I don't see why this would be any different.
Acked-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>
Alex
________________________________
From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Tuesday, April 17, 2018 9:01:35 AM
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: [PATCH] drm/amdgpu: limit reg_write_reg_wait workaround to SRIOV
Turned out that this locks up some bare metal Vega10.
Signed-off-by: Christian König <christian.koenig-5C7GfCeVMHo@public.gmane.org>
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 583f6f616dd3..5329d7e5fb71 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -4144,7 +4144,12 @@ static void gfx_v9_0_ring_emit_reg_write_reg_wait(struct amdgpu_ring *ring,
{
int usepfp = (ring->funcs->type == AMDGPU_RING_TYPE_GFX);
- gfx_v9_0_wait_reg_mem(ring, usepfp, 0, 1, reg0, reg1, ref, mask, 0x20);
+ if (amdgpu_sriov_vf(adev))
+ gfx_v9_0_wait_reg_mem(ring, usepfp, 0, 1, reg0, reg1,
+ ref, mask, 0x20);
+ else
+ amdgpu_ring_emit_reg_write_reg_wait_helper(ring, reg0, reg1,
+ ref, mask);
}
static void gfx_v9_0_set_gfx_eop_interrupt_state(struct amdgpu_device *adev,
--
2.14.1
_______________________________________________
amd-gfx mailing list
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[-- Attachment #1.2: Type: text/html, Size: 4099 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] drm/amdgpu: limit reg_write_reg_wait workaround to SRIOV
[not found] ` <DM5PR12MB1820165CD71A527EAA47C5F4F7B70-2J9CzHegvk8qWyLXlBb1HgdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
@ 2018-04-17 15:26 ` Christian König
[not found] ` <0cf6dae0-afae-c858-73af-ab47673a7d8a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Christian König @ 2018-04-17 15:26 UTC (permalink / raw)
To: Deucher, Alexander, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
Deng, Emily, Liu, Monk
[-- Attachment #1.1: Type: text/plain, Size: 2551 bytes --]
> Does this actually work on SR-IOV? Or does it just seem to but nothing
> bad happens because we get a GPU reset on a world switch?
I honestly don't know. I think that SR-IOV uses a specialized firmware
where this packet has a different meaning.
But the real fix would be to get the RLC firmware fix to not
reinitialize those regs to zero on world switch.
Christian.
Am 17.04.2018 um 16:02 schrieb Deucher, Alexander:
>
> Does this actually work on SR-IOV? Or does it just seem to but
> nothing bad happens because we get a GPU reset on a world switch? The
> behavior of this packet should be the same as SDMA and that definitely
> doesn't work. I don't see why this would be any different.
>
>
> Acked-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>
>
>
> Alex
>
> ------------------------------------------------------------------------
> *From:* amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of
> Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> *Sent:* Tuesday, April 17, 2018 9:01:35 AM
> *To:* amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> *Subject:* [PATCH] drm/amdgpu: limit reg_write_reg_wait workaround to
> SRIOV
> Turned out that this locks up some bare metal Vega10.
>
> Signed-off-by: Christian König <christian.koenig-5C7GfCeVMHo@public.gmane.org>
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 583f6f616dd3..5329d7e5fb71 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -4144,7 +4144,12 @@ static void
> gfx_v9_0_ring_emit_reg_write_reg_wait(struct amdgpu_ring *ring,
> {
> int usepfp = (ring->funcs->type == AMDGPU_RING_TYPE_GFX);
>
> - gfx_v9_0_wait_reg_mem(ring, usepfp, 0, 1, reg0, reg1, ref,
> mask, 0x20);
> + if (amdgpu_sriov_vf(adev))
> + gfx_v9_0_wait_reg_mem(ring, usepfp, 0, 1, reg0, reg1,
> + ref, mask, 0x20);
> + else
> + amdgpu_ring_emit_reg_write_reg_wait_helper(ring, reg0, reg1,
> + ref, mask);
> }
>
> static void gfx_v9_0_set_gfx_eop_interrupt_state(struct amdgpu_device
> *adev,
> --
> 2.14.1
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[-- Attachment #1.2: Type: text/html, Size: 5716 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [PATCH] drm/amdgpu: limit reg_write_reg_wait workaround to SRIOV
[not found] ` <0cf6dae0-afae-c858-73af-ab47673a7d8a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2018-04-18 1:59 ` Deng, Emily
0 siblings, 0 replies; 4+ messages in thread
From: Deng, Emily @ 2018-04-18 1:59 UTC (permalink / raw)
To: Koenig, Christian, Deucher, Alexander,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Liu, Monk
[-- Attachment #1.1: Type: text/plain, Size: 3779 bytes --]
Hi all,
Does this actually work on SR-IOV? Or does it just seem to but nothing bad happens because we get a GPU reset on a world switch?
I honestly don't know. I think that SR-IOV uses a specialized firmware where this packet has a different meaning.
But the real fix would be to get the RLC firmware fix to not reinitialize those regs to zero on world switch.
[Emily]Yes, it actually works on SR-IOV, it fixes lots of engine hang issue.
Best Wishes,
Emily Deng
From: Christian König [mailto:ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: Tuesday, April 17, 2018 11:27 PM
To: Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>; amd-gfx-PD4FTy7X32nrcLQh/DF6ew@public.gmane.orgop.org; Deng, Emily <Emily.Deng-5C7GfCeVMHo@public.gmane.org>; Liu, Monk <Monk.Liu-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH] drm/amdgpu: limit reg_write_reg_wait workaround to SRIOV
Does this actually work on SR-IOV? Or does it just seem to but nothing bad happens because we get a GPU reset on a world switch?
I honestly don't know. I think that SR-IOV uses a specialized firmware where this packet has a different meaning.
But the real fix would be to get the RLC firmware fix to not reinitialize those regs to zero on world switch.
Christian.
Am 17.04.2018 um 16:02 schrieb Deucher, Alexander:
Does this actually work on SR-IOV? Or does it just seem to but nothing bad happens because we get a GPU reset on a world switch? The behavior of this packet should be the same as SDMA and that definitely doesn't work. I don't see why this would be any different.
Acked-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org><mailto:alexander.deucher@amd.com>
Alex
________________________________
From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org><mailto:amd-gfx-bounces@lists.freedesktop.org> on behalf of Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org><mailto:ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Tuesday, April 17, 2018 9:01:35 AM
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org<mailto:amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: [PATCH] drm/amdgpu: limit reg_write_reg_wait workaround to SRIOV
Turned out that this locks up some bare metal Vega10.
Signed-off-by: Christian König <christian.koenig-5C7GfCeVMHo@public.gmane.org><mailto:christian.koenig-5C7GfCeVMHo@public.gmane.org>
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 583f6f616dd3..5329d7e5fb71 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -4144,7 +4144,12 @@ static void gfx_v9_0_ring_emit_reg_write_reg_wait(struct amdgpu_ring *ring,
{
int usepfp = (ring->funcs->type == AMDGPU_RING_TYPE_GFX);
- gfx_v9_0_wait_reg_mem(ring, usepfp, 0, 1, reg0, reg1, ref, mask, 0x20);
+ if (amdgpu_sriov_vf(adev))
+ gfx_v9_0_wait_reg_mem(ring, usepfp, 0, 1, reg0, reg1,
+ ref, mask, 0x20);
+ else
+ amdgpu_ring_emit_reg_write_reg_wait_helper(ring, reg0, reg1,
+ ref, mask);
}
static void gfx_v9_0_set_gfx_eop_interrupt_state(struct amdgpu_device *adev,
--
2.14.1
_______________________________________________
amd-gfx mailing list
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org<mailto:amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[-- Attachment #1.2: Type: text/html, Size: 9658 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-04-18 1:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-17 13:01 [PATCH] drm/amdgpu: limit reg_write_reg_wait workaround to SRIOV Christian König
[not found] ` <20180417130135.1895-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2018-04-17 14:02 ` Deucher, Alexander
[not found] ` <DM5PR12MB1820165CD71A527EAA47C5F4F7B70-2J9CzHegvk8qWyLXlBb1HgdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2018-04-17 15:26 ` Christian König
[not found] ` <0cf6dae0-afae-c858-73af-ab47673a7d8a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-04-18 1:59 ` Deng, Emily
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.