RE: [PATCH] drm/amdgpu: refine kiq access register
Hi Christian
Thanks, I got it. I will send another patch for the KIQ overrun problem
Best Regards
Yintian Tao
-Original Message-
From: Koenig, Christian
Sent: 2020年4月22日 20:33
To: Tao, Yintian ; Liu, Monk ; Kuehling,
Felix
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 14:20 schrieb Tao, Yintian:
> Hi Christian
>
>
> Please see inline commetns.
> -Original Message-
> From: Koenig, Christian
> Sent: 2020年4月22日 19:57
> To: Tao, Yintian ; Liu, Monk ;
> Kuehling, Felix
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
>
> Am 22.04.20 um 13:49 schrieb Tao, Yintian:
>> Hi Christian
>>
>>
>> Can you help answer the questions below? Thanks in advance.
>> -Original Message-
>> From: Koenig, Christian
>> Sent: 2020年4月22日 19:03
>> To: Tao, Yintian ; Liu, Monk ;
>> Kuehling, Felix
>> Cc: amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
>>
>> Am 22.04.20 um 11:29 schrieb Yintian Tao:
>>> According to the current kiq access register method, there will be
>>> race condition when using KIQ to read register if multiple clients
>>> want to read at same time just like the expample below:
>>> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the
>>> seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll
>>> the seqno-1 5. the kiq complete these two read operation 6. client-A
>>> to read the register at the wb buffer and
>>> get REG-1 value
>>>
>>> And if there are multiple clients to frequently write registers
>>> through KIQ which may raise the KIQ ring buffer overwritten problem.
>>>
>>> Therefore, allocate fixed number wb slot for rreg use and limit the
>>> submit number which depends on the kiq ring_size in order to prevent
>>> the overwritten problem.
>>>
>>> v2: directly use amdgpu_device_wb_get() for each read instead
>>>of to reserve fixde number slot.
>>>if there is no enough kiq ring buffer or rreg slot then
>>>directly print error log and return instead of busy waiting
>> I would split that into three patches. One for each problem we have here:
>>
>> 1. Fix kgd_hiq_mqd_load() and maybe other occasions to use
>> spin_lock_irqsave().
>> [yttao]: Do you mean that we need to use spin_lock_irqsave for the functions
>> just like kgd_hiq_mqd_load()?
> Yes, I strongly think so.
>
> See when you have one spin lock you either need always need to lock it with
> irqs disabled or never.
>
> In other words we always need to either use spin_lock() or
> spin_lock_irqsave(), but never mix them with the same lock.
>
> The only exception to this rule is when you take multiple locks, e.g.
> you can do:
>
> spin_lock_irqsave(&a, flags);
> spin_lock(&b, flags);
> spin_lock(&c, flags);
>
> spin_unlock_irqsave(&a, flags);
>
> Here you don't need to use spin_lock_irqsave for b and c. But we rarely have
> that case in the code.
> [yttao]: thanks , I got it. I will submit another patch for it.
>
>> 2. Prevent the overrung of the KIQ. Please drop the approach with the
>> atomic here. Instead just add a amdgpu_fence_wait_polling() into
>> amdgpu_fence_emit_polling() as I discussed with Monk.
>> [yttao]: Sorry, I can't get your original idea for the
>> amdgpu_fence_wait_polling(). Can you give more details about it? Thanks in
>> advance.
>>
>> "That is actually only a problem because the KIQ uses polling waits.
>>
>> See amdgpu_fence_emit() waits for the oldest possible fence to be signaled
>> before emitting a new one.
>>
>> I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner
>> like the following should be enough:
>>
>> amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask,
>> timeout);"
>> [yttao]: there is no usage of num_fences_mask at kiq fence polling, the
>> num_fences_mask is only effective at dma_fence architecture.
>> If I understand correctly, do you want the protype code below?
>> If the protype code is wrong, can you help give one sample? Thanks in
>> advance.
>>
>> int amdgpu_fence_emit_polling(struct amdgpu_ring *ring, uint32_t *s) {
>> uint32_t seq;
>>
>> if (!s)
>> return -EINVAL;
>> +amdgpu_fence_wait_polling(ring, seq, timeout);
>> seq =
Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 14:20 schrieb Tao, Yintian:
Hi Christian
Please see inline commetns.
-Original Message-
From: Koenig, Christian
Sent: 2020年4月22日 19:57
To: Tao, Yintian ; Liu, Monk ; Kuehling, Felix
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 13:49 schrieb Tao, Yintian:
Hi Christian
Can you help answer the questions below? Thanks in advance.
-Original Message-
From: Koenig, Christian
Sent: 2020年4月22日 19:03
To: Tao, Yintian ; Liu, Monk ;
Kuehling, Felix
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 11:29 schrieb Yintian Tao:
According to the current kiq access register method, there will be
race condition when using KIQ to read register if multiple clients
want to read at same time just like the expample below:
1. client-A start to read REG-0 throguh KIQ 2. client-A poll the
seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll
the seqno-1 5. the kiq complete these two read operation 6. client-A
to read the register at the wb buffer and
get REG-1 value
And if there are multiple clients to frequently write registers
through KIQ which may raise the KIQ ring buffer overwritten problem.
Therefore, allocate fixed number wb slot for rreg use and limit the
submit number which depends on the kiq ring_size in order to prevent
the overwritten problem.
v2: directly use amdgpu_device_wb_get() for each read instead
of to reserve fixde number slot.
if there is no enough kiq ring buffer or rreg slot then
directly print error log and return instead of busy waiting
I would split that into three patches. One for each problem we have here:
1. Fix kgd_hiq_mqd_load() and maybe other occasions to use spin_lock_irqsave().
[yttao]: Do you mean that we need to use spin_lock_irqsave for the functions
just like kgd_hiq_mqd_load()?
Yes, I strongly think so.
See when you have one spin lock you either need always need to lock it with
irqs disabled or never.
In other words we always need to either use spin_lock() or spin_lock_irqsave(),
but never mix them with the same lock.
The only exception to this rule is when you take multiple locks, e.g.
you can do:
spin_lock_irqsave(&a, flags);
spin_lock(&b, flags);
spin_lock(&c, flags);
spin_unlock_irqsave(&a, flags);
Here you don't need to use spin_lock_irqsave for b and c. But we rarely have
that case in the code.
[yttao]: thanks , I got it. I will submit another patch for it.
2. Prevent the overrung of the KIQ. Please drop the approach with the
atomic here. Instead just add a amdgpu_fence_wait_polling() into
amdgpu_fence_emit_polling() as I discussed with Monk.
[yttao]: Sorry, I can't get your original idea for the
amdgpu_fence_wait_polling(). Can you give more details about it? Thanks in
advance.
"That is actually only a problem because the KIQ uses polling waits.
See amdgpu_fence_emit() waits for the oldest possible fence to be signaled
before emitting a new one.
I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner like
the following should be enough:
amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask,
timeout);"
[yttao]: there is no usage of num_fences_mask at kiq fence polling, the
num_fences_mask is only effective at dma_fence architecture.
If I understand correctly, do you want the protype code below?
If the protype code is wrong, can you help give one sample? Thanks in advance.
int amdgpu_fence_emit_polling(struct amdgpu_ring *ring, uint32_t *s) {
uint32_t seq;
if (!s)
return -EINVAL;
+ amdgpu_fence_wait_polling(ring, seq, timeout);
seq = ++ring->fence_drv.sync_seq;
Your understanding sounds more or less correct. The code should look something
like this:
seq = ++ring->fence_drv.sync_seq;
amdgpu_fence_wait_polling(ring, seq -
number_of_allowed_submissions_to_the_kiq, timeout);
[yttao]: whether we need directly wait at the first just like below? Otherwise,
amdgpu_ring_emit_wreg may overwrite the KIQ ring buffer.
There should always be room for at least one more submission.
As long as we always submit a fence checking the free room there should
be fine.
Regards,
Christian.
+ amdgpu_fence_wait_polling(ring, seq -
number_of_allowed_submissions_to_the_kiq, timeout);
spin_lock_irqsave(&kiq->ring_lock, flags);
amdgpu_ring_alloc(ring, 32);
amdgpu_ring_emit_wreg(ring, reg, v);
amdgpu_fence_emit_polling(ring, &seq); /* wait */
amdgpu_ring_commit(ring);
spin_unlock_irqrestore(&kiq->ring_lock, flags);
I just used num_fences_mask as number_of_allowed_submissions_to_the_kiq
because it is probably a good value to start with.
But you could give that as parameter as well if you think that
RE: [PATCH] drm/amdgpu: refine kiq access register
Hi Christian
Please see inline commetns.
-Original Message-
From: Koenig, Christian
Sent: 2020年4月22日 19:57
To: Tao, Yintian ; Liu, Monk ; Kuehling,
Felix
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 13:49 schrieb Tao, Yintian:
> Hi Christian
>
>
> Can you help answer the questions below? Thanks in advance.
> -Original Message-
> From: Koenig, Christian
> Sent: 2020年4月22日 19:03
> To: Tao, Yintian ; Liu, Monk ;
> Kuehling, Felix
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
>
> Am 22.04.20 um 11:29 schrieb Yintian Tao:
>> According to the current kiq access register method, there will be
>> race condition when using KIQ to read register if multiple clients
>> want to read at same time just like the expample below:
>> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the
>> seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll
>> the seqno-1 5. the kiq complete these two read operation 6. client-A
>> to read the register at the wb buffer and
>> get REG-1 value
>>
>> And if there are multiple clients to frequently write registers
>> through KIQ which may raise the KIQ ring buffer overwritten problem.
>>
>> Therefore, allocate fixed number wb slot for rreg use and limit the
>> submit number which depends on the kiq ring_size in order to prevent
>> the overwritten problem.
>>
>> v2: directly use amdgpu_device_wb_get() for each read instead
>> of to reserve fixde number slot.
>> if there is no enough kiq ring buffer or rreg slot then
>> directly print error log and return instead of busy waiting
> I would split that into three patches. One for each problem we have here:
>
> 1. Fix kgd_hiq_mqd_load() and maybe other occasions to use
> spin_lock_irqsave().
> [yttao]: Do you mean that we need to use spin_lock_irqsave for the functions
> just like kgd_hiq_mqd_load()?
Yes, I strongly think so.
See when you have one spin lock you either need always need to lock it with
irqs disabled or never.
In other words we always need to either use spin_lock() or spin_lock_irqsave(),
but never mix them with the same lock.
The only exception to this rule is when you take multiple locks, e.g.
you can do:
spin_lock_irqsave(&a, flags);
spin_lock(&b, flags);
spin_lock(&c, flags);
spin_unlock_irqsave(&a, flags);
Here you don't need to use spin_lock_irqsave for b and c. But we rarely have
that case in the code.
[yttao]: thanks , I got it. I will submit another patch for it.
> 2. Prevent the overrung of the KIQ. Please drop the approach with the
> atomic here. Instead just add a amdgpu_fence_wait_polling() into
> amdgpu_fence_emit_polling() as I discussed with Monk.
> [yttao]: Sorry, I can't get your original idea for the
> amdgpu_fence_wait_polling(). Can you give more details about it? Thanks in
> advance.
>
> "That is actually only a problem because the KIQ uses polling waits.
>
> See amdgpu_fence_emit() waits for the oldest possible fence to be signaled
> before emitting a new one.
>
> I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner
> like the following should be enough:
>
> amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask,
> timeout);"
> [yttao]: there is no usage of num_fences_mask at kiq fence polling, the
> num_fences_mask is only effective at dma_fence architecture.
> If I understand correctly, do you want the protype code below?
> If the protype code is wrong, can you help give one sample? Thanks in advance.
>
> int amdgpu_fence_emit_polling(struct amdgpu_ring *ring, uint32_t *s) {
> uint32_t seq;
>
> if (!s)
> return -EINVAL;
> + amdgpu_fence_wait_polling(ring, seq, timeout);
> seq = ++ring->fence_drv.sync_seq;
Your understanding sounds more or less correct. The code should look something
like this:
seq = ++ring->fence_drv.sync_seq;
amdgpu_fence_wait_polling(ring, seq -
number_of_allowed_submissions_to_the_kiq, timeout);
[yttao]: whether we need directly wait at the first just like below? Otherwise,
amdgpu_ring_emit_wreg may overwrite the KIQ ring buffer.
+ amdgpu_fence_wait_polling(ring, seq -
number_of_allowed_submissions_to_the_kiq, timeout);
spin_lock_irqsave(&kiq->ring_lock, flags);
amdgpu_ring_alloc(ring, 32);
amdgpu_ring_emit_wreg(ring, reg, v);
amdgpu_fence_emit_polling(ring, &seq); /* wait */
amdgpu_ring_commit(ring);
spin_unlock_irqrestore(&kiq->ring_lock, flags);
I just us
Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 13:49 schrieb Tao, Yintian:
Hi Christian
Can you help answer the questions below? Thanks in advance.
-Original Message-
From: Koenig, Christian
Sent: 2020年4月22日 19:03
To: Tao, Yintian ; Liu, Monk ; Kuehling, Felix
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 11:29 schrieb Yintian Tao:
According to the current kiq access register method, there will be
race condition when using KIQ to read register if multiple clients
want to read at same time just like the expample below:
1. client-A start to read REG-0 throguh KIQ 2. client-A poll the
seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll
the seqno-1 5. the kiq complete these two read operation 6. client-A
to read the register at the wb buffer and
get REG-1 value
And if there are multiple clients to frequently write registers
through KIQ which may raise the KIQ ring buffer overwritten problem.
Therefore, allocate fixed number wb slot for rreg use and limit the
submit number which depends on the kiq ring_size in order to prevent
the overwritten problem.
v2: directly use amdgpu_device_wb_get() for each read instead
of to reserve fixde number slot.
if there is no enough kiq ring buffer or rreg slot then
directly print error log and return instead of busy waiting
I would split that into three patches. One for each problem we have here:
1. Fix kgd_hiq_mqd_load() and maybe other occasions to use spin_lock_irqsave().
[yttao]: Do you mean that we need to use spin_lock_irqsave for the functions
just like kgd_hiq_mqd_load()?
Yes, I strongly think so.
See when you have one spin lock you either need always need to lock it
with irqs disabled or never.
In other words we always need to either use spin_lock() or
spin_lock_irqsave(), but never mix them with the same lock.
The only exception to this rule is when you take multiple locks, e.g.
you can do:
spin_lock_irqsave(&a, flags);
spin_lock(&b, flags);
spin_lock(&c, flags);
spin_unlock_irqsave(&a, flags);
Here you don't need to use spin_lock_irqsave for b and c. But we rarely
have that case in the code.
2. Prevent the overrung of the KIQ. Please drop the approach with the atomic
here. Instead just add a amdgpu_fence_wait_polling() into
amdgpu_fence_emit_polling() as I discussed with Monk.
[yttao]: Sorry, I can't get your original idea for the
amdgpu_fence_wait_polling(). Can you give more details about it? Thanks in
advance.
"That is actually only a problem because the KIQ uses polling waits.
See amdgpu_fence_emit() waits for the oldest possible fence to be signaled
before emitting a new one.
I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner like
the following should be enough:
amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask,
timeout);"
[yttao]: there is no usage of num_fences_mask at kiq fence polling, the
num_fences_mask is only effective at dma_fence architecture.
If I understand correctly, do you want the protype code below?
If the protype code is wrong, can you help give one sample? Thanks in advance.
int amdgpu_fence_emit_polling(struct amdgpu_ring *ring, uint32_t *s)
{
uint32_t seq;
if (!s)
return -EINVAL;
+ amdgpu_fence_wait_polling(ring, seq, timeout);
seq = ++ring->fence_drv.sync_seq;
Your understanding sounds more or less correct. The code should look
something like this:
seq = ++ring->fence_drv.sync_seq;
amdgpu_fence_wait_polling(ring, seq -
number_of_allowed_submissions_to_the_kiq, timeout);
I just used num_fences_mask as number_of_allowed_submissions_to_the_kiq
because it is probably a good value to start with.
But you could give that as parameter as well if you think that makes
more sense.
amdgpu_ring_emit_fence(ring, ring->fence_drv.gpu_addr,
¦ seq, 0);
*s = seq;
return 0;
}
3. Use amdgpu_device_wb_get() each time we need to submit a read.
[yttao]: yes, I will do it.
Thanks,
Christian.
Regards,
Christian.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 8 +-
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 13 ++-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 13 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 83 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 13 ++-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 8 +-
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 35 +---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c| 13 ++-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 13 ++-
12 files changed, 167 insertions(+), 48 delet
RE: [PATCH] drm/amdgpu: refine kiq access register
Hi Christian
Can you help answer the questions below? Thanks in advance.
-Original Message-
From: Koenig, Christian
Sent: 2020年4月22日 19:03
To: Tao, Yintian ; Liu, Monk ; Kuehling,
Felix
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 11:29 schrieb Yintian Tao:
> According to the current kiq access register method, there will be
> race condition when using KIQ to read register if multiple clients
> want to read at same time just like the expample below:
> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the
> seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll
> the seqno-1 5. the kiq complete these two read operation 6. client-A
> to read the register at the wb buffer and
> get REG-1 value
>
> And if there are multiple clients to frequently write registers
> through KIQ which may raise the KIQ ring buffer overwritten problem.
>
> Therefore, allocate fixed number wb slot for rreg use and limit the
> submit number which depends on the kiq ring_size in order to prevent
> the overwritten problem.
>
> v2: directly use amdgpu_device_wb_get() for each read instead
> of to reserve fixde number slot.
> if there is no enough kiq ring buffer or rreg slot then
> directly print error log and return instead of busy waiting
I would split that into three patches. One for each problem we have here:
1. Fix kgd_hiq_mqd_load() and maybe other occasions to use spin_lock_irqsave().
[yttao]: Do you mean that we need to use spin_lock_irqsave for the functions
just like kgd_hiq_mqd_load()?
2. Prevent the overrung of the KIQ. Please drop the approach with the atomic
here. Instead just add a amdgpu_fence_wait_polling() into
amdgpu_fence_emit_polling() as I discussed with Monk.
[yttao]: Sorry, I can't get your original idea for the
amdgpu_fence_wait_polling(). Can you give more details about it? Thanks in
advance.
"That is actually only a problem because the KIQ uses polling waits.
See amdgpu_fence_emit() waits for the oldest possible fence to be signaled
before emitting a new one.
I suggest that we do the same in amdgpu_fence_emit_polling(). A one liner like
the following should be enough:
amdgpu_fence_wait_polling(ring, seq - ring->fence_drv.num_fences_mask,
timeout);"
[yttao]: there is no usage of num_fences_mask at kiq fence polling, the
num_fences_mask is only effective at dma_fence architecture.
If I understand correctly, do you want the protype code below?
If the protype code is wrong, can you help give one sample? Thanks in advance.
int amdgpu_fence_emit_polling(struct amdgpu_ring *ring, uint32_t *s)
{
uint32_t seq;
if (!s)
return -EINVAL;
+ amdgpu_fence_wait_polling(ring, seq, timeout);
seq = ++ring->fence_drv.sync_seq;
amdgpu_ring_emit_fence(ring, ring->fence_drv.gpu_addr,
¦ seq, 0);
*s = seq;
return 0;
}
3. Use amdgpu_device_wb_get() each time we need to submit a read.
[yttao]: yes, I will do it.
Regards,
Christian.
>
> Signed-off-by: Yintian Tao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 8 +-
> .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 13 ++-
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 13 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 83 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 3 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 13 ++-
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 8 +-
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 35 +---
> drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c| 13 ++-
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 13 ++-
> 12 files changed, 167 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 4e1d4cfe7a9f..1157c1a0b888 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -526,7 +526,7 @@ static inline void amdgpu_set_ib_value(struct
> amdgpu_cs_parser *p,
> /*
>* Writeback
>*/
> -#define AMDGPU_MAX_WB 128/* Reserve at most 128 WB slots for
> amdgpu-owned rings. */
> +#define AMDGPU_MAX_WB 256/* Reserve at most 256 WB slots for
> amdgpu-owned rings. */
>
> struct amdgpu_wb {
> struct amdgpu_bo*wb_obj;
> @@ -1028,6 +1028,12 @@ bool amdgpu_device_has_dc_support(struct
> amdgpu_device *adev);
>
> int emu_soc_asic_init(struct amdgpu_device *adev);
>
> +int amdgpu_gfx_kiq_lock(struct amdgpu_kiq *kiq, bool read,
> +
Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 11:29 schrieb Yintian Tao:
According to the current kiq access register method,
there will be race condition when using KIQ to read
register if multiple clients want to read at same time
just like the expample below:
1. client-A start to read REG-0 throguh KIQ
2. client-A poll the seqno-0
3. client-B start to read REG-1 through KIQ
4. client-B poll the seqno-1
5. the kiq complete these two read operation
6. client-A to read the register at the wb buffer and
get REG-1 value
And if there are multiple clients to frequently write
registers through KIQ which may raise the KIQ ring buffer
overwritten problem.
Therefore, allocate fixed number wb slot for rreg use
and limit the submit number which depends on the kiq
ring_size in order to prevent the overwritten problem.
v2: directly use amdgpu_device_wb_get() for each read instead
of to reserve fixde number slot.
if there is no enough kiq ring buffer or rreg slot then
directly print error log and return instead of busy waiting
I would split that into three patches. One for each problem we have here:
1. Fix kgd_hiq_mqd_load() and maybe other occasions to use
spin_lock_irqsave().
2. Prevent the overrung of the KIQ. Please drop the approach with the
atomic here. Instead just add a amdgpu_fence_wait_polling() into
amdgpu_fence_emit_polling() as I discussed with Monk.
3. Use amdgpu_device_wb_get() each time we need to submit a read.
Regards,
Christian.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 8 +-
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 13 ++-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 13 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 83 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 13 ++-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 8 +-
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 35 +---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c| 13 ++-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 13 ++-
12 files changed, 167 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4e1d4cfe7a9f..1157c1a0b888 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -526,7 +526,7 @@ static inline void amdgpu_set_ib_value(struct
amdgpu_cs_parser *p,
/*
* Writeback
*/
-#define AMDGPU_MAX_WB 128 /* Reserve at most 128 WB slots for
amdgpu-owned rings. */
+#define AMDGPU_MAX_WB 256 /* Reserve at most 256 WB slots for
amdgpu-owned rings. */
struct amdgpu_wb {
struct amdgpu_bo*wb_obj;
@@ -1028,6 +1028,12 @@ bool amdgpu_device_has_dc_support(struct amdgpu_device
*adev);
int emu_soc_asic_init(struct amdgpu_device *adev);
+int amdgpu_gfx_kiq_lock(struct amdgpu_kiq *kiq, bool read,
+ unsigned long *flags);
+void amdgpu_gfx_kiq_unlock(struct amdgpu_kiq *kiq, unsigned long *flags);
+
+void amdgpu_gfx_kiq_consume(struct amdgpu_kiq *kiq, uint32_t *offs);
+void amdgpu_gfx_kiq_restore(struct amdgpu_kiq *kiq, uint32_t *offs);
/*
* Registers read & write functions.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index 691c89705bcd..a65d6a1abc04 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -309,9 +309,11 @@ static int kgd_hiq_mqd_load(struct kgd_dev *kgd, void *mqd,
uint32_t doorbell_off)
{
struct amdgpu_device *adev = get_amdgpu_device(kgd);
+ struct amdgpu_kiq *kiq = &adev->gfx.kiq;
struct amdgpu_ring *kiq_ring = &adev->gfx.kiq.ring;
struct v10_compute_mqd *m;
uint32_t mec, pipe;
+ unsigned long flags = 0;
int r;
m = get_mqd(mqd);
@@ -324,13 +326,19 @@ static int kgd_hiq_mqd_load(struct kgd_dev *kgd, void
*mqd,
pr_debug("kfd: set HIQ, mec:%d, pipe:%d, queue:%d.\n",
mec, pipe, queue_id);
- spin_lock(&adev->gfx.kiq.ring_lock);
+ r = amdgpu_gfx_kiq_lock(kiq, false, &flags);
+ if (r) {
+ pr_err("failed to lock kiq\n");
+ goto out_unlock;
+ }
+
r = amdgpu_ring_alloc(kiq_ring, 7);
if (r) {
pr_err("Failed to alloc KIQ (%d).\n", r);
goto out_unlock;
}
+ amdgpu_gfx_kiq_consume(kiq, NULL);
amdgpu_ring_write(kiq_ring, PACKET3(PACKET3_MAP_QUEUES, 5));
amdgpu_ring_write(kiq_ring,
PACKET3_MAP_QUEUES_QUEUE_SEL(0) | /* Queue_Sel */
@@ -350,8 +358,9 @@ static int kgd_hiq_mqd_load(struct kgd_dev *kgd, void *mqd,
amdgpu_ring_write(kiq_ring, m->cp_hqd_pq_wptr_poll_addr_hi);
am
RE: [PATCH] drm/amdgpu: refine kiq access register
Hi Christian Please see inline comments. -Original Message- From: Koenig, Christian Sent: 2020年4月22日 16:23 To: Tao, Yintian ; Liu, Monk ; Liu, Shaoyun ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq access register Am 22.04.20 um 10:06 schrieb Tao, Yintian: > Hi Christian > > Please see inline comments > > -Original Message- > From: Koenig, Christian > Sent: 2020年4月22日 15:54 > To: Tao, Yintian ; Liu, Monk ; > Liu, Shaoyun ; Kuehling, Felix > > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: refine kiq access register > > Am 22.04.20 um 09:49 schrieb Tao, Yintian: >> Hi Christian >> >> >> Please see inline comments. >> -Original Message- >> From: Christian König >> Sent: 2020年4月22日 15:40 >> To: Tao, Yintian ; Koenig, Christian >> ; Liu, Monk ; Liu, >> Shaoyun ; Kuehling, Felix >> >> Cc: amd-gfx@lists.freedesktop.org >> Subject: Re: [PATCH] drm/amdgpu: refine kiq access register >> >> Am 22.04.20 um 09:35 schrieb Tao, Yintian: >>> Hi Christian >>> >>> >>>> BUG_ON(in_interrupt()); >>> That won't work like this. The KIQ is also used in interrupt context in the >>> driver, that's why we used spin_lock_irqsave(). >>> [yttao]: According to the current drm-next code, I have not find where to >>> access register through KIQ. >>> And you need to wait for the free kiq ring buffer space if >>> there is no free kiq ring buffer, here, you wait at interrupt context is >>> illegal. >> Waiting in atomic context is illegal as well, but we don't have much other >> choice. >> [yttao]: no, there is no sleep in atomic context at my patch. > I'm not talking about a sleeping, but busy waiting. > >> We just need to make sure that waiting never happens by making the buffers >> large enough and if it still happens print and error. >> [yttao]: this is not the good choice because KMD need to protect it instead >> of hoping user not frequently invoke KIQ acess. > The only other choice we have is busy waiting, e.g. loop until we get a free > slot. > [yttao]: Yes, now may patch use msleep() to busy waiting. Or you means need > to use udelay()? If we use udelay(), it will be the nightmare under multi-VF. > Because it is assumed that there are 16VF within world-switch > 6ms, the bad situation is that one VF will udelay(16*6ms = 96ms) to get one > free slot. You can't use msleep() here since sleeping in atomic or interrupt context is forbidden. The trick is that in atomic context the CPU can't switch to a different process, so we have a very limited number of concurrent KIQ reads which can happen. With a MAX_WB of 256 we can easily have 128 CPUs and don't run into problems. [yttao]: fine, this is a good idea. But it seems current drm-next code, KIQ access still use msleep to wait the fence which is not correct according to your comments. I think we need submit another patch to add one more condition "in_atomic()" to prevent it but this function cannot know about held spinlocks in non-preemptible kernels. Regards, Christian. > > > Regards, > Christian. > >>> And I would either say that we should use the trick with the NOP to reserve >>> space on the ring buffer or call amdgpu_device_wb_get() for each read. >>> amdgpu_device_wb_get() also uses find_first_zero_bit() and should work >>> equally well. >>> [yttao]: sorry, can you give me more details about how to use NOP to >>> reserve space? I will use amdgpu_device_wb_get() for the read operation. >> We could use the NOP PM4 command as Felix suggested, this command has >> a >> header+length and says that the next X dw should be ignore on the >> header+ring >> buffer. >> >> But I think using amdgpu_device_wb_get() is better anyway. >> [yttao]: yes, I agreed with amdgpu_device_wb_get() method because it >> will fix prevent potential read race condition but NOP method will >> not prevent it >> >> Regards, >> Christian. >> >>> >>> -Original Message- >>> From: Koenig, Christian >>> Sent: 2020年4月22日 15:23 >>> To: Tao, Yintian ; Liu, Monk >>> ; Liu, Shaoyun ; Kuehling, >>> Felix >>> Cc: amd-gfx@lists.freedesktop.org >>> Subject: Re: [PATCH] drm/amdgpu: refine kiq access register >>> >>>> BUG_ON(in_interrupt()); >>> That won't work like this. The KIQ is also used in interrupt context in t
Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 10:06 schrieb Tao, Yintian: Hi Christian Please see inline comments -Original Message- From: Koenig, Christian Sent: 2020年4月22日 15:54 To: Tao, Yintian ; Liu, Monk ; Liu, Shaoyun ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq access register Am 22.04.20 um 09:49 schrieb Tao, Yintian: Hi Christian Please see inline comments. -Original Message- From: Christian König Sent: 2020年4月22日 15:40 To: Tao, Yintian ; Koenig, Christian ; Liu, Monk ; Liu, Shaoyun ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq access register Am 22.04.20 um 09:35 schrieb Tao, Yintian: Hi Christian BUG_ON(in_interrupt()); That won't work like this. The KIQ is also used in interrupt context in the driver, that's why we used spin_lock_irqsave(). [yttao]: According to the current drm-next code, I have not find where to access register through KIQ. And you need to wait for the free kiq ring buffer space if there is no free kiq ring buffer, here, you wait at interrupt context is illegal. Waiting in atomic context is illegal as well, but we don't have much other choice. [yttao]: no, there is no sleep in atomic context at my patch. I'm not talking about a sleeping, but busy waiting. We just need to make sure that waiting never happens by making the buffers large enough and if it still happens print and error. [yttao]: this is not the good choice because KMD need to protect it instead of hoping user not frequently invoke KIQ acess. The only other choice we have is busy waiting, e.g. loop until we get a free slot. [yttao]: Yes, now may patch use msleep() to busy waiting. Or you means need to use udelay()? If we use udelay(), it will be the nightmare under multi-VF. Because it is assumed that there are 16VF within world-switch 6ms, the bad situation is that one VF will udelay(16*6ms = 96ms) to get one free slot. You can't use msleep() here since sleeping in atomic or interrupt context is forbidden. The trick is that in atomic context the CPU can't switch to a different process, so we have a very limited number of concurrent KIQ reads which can happen. With a MAX_WB of 256 we can easily have 128 CPUs and don't run into problems. Regards, Christian. Regards, Christian. And I would either say that we should use the trick with the NOP to reserve space on the ring buffer or call amdgpu_device_wb_get() for each read. amdgpu_device_wb_get() also uses find_first_zero_bit() and should work equally well. [yttao]: sorry, can you give me more details about how to use NOP to reserve space? I will use amdgpu_device_wb_get() for the read operation. We could use the NOP PM4 command as Felix suggested, this command has a header+length and says that the next X dw should be ignore on the ring buffer. But I think using amdgpu_device_wb_get() is better anyway. [yttao]: yes, I agreed with amdgpu_device_wb_get() method because it will fix prevent potential read race condition but NOP method will not prevent it Regards, Christian. -Original Message- From: Koenig, Christian Sent: 2020年4月22日 15:23 To: Tao, Yintian ; Liu, Monk ; Liu, Shaoyun ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq access register BUG_ON(in_interrupt()); That won't work like this. The KIQ is also used in interrupt context in the driver, that's why we used spin_lock_irqsave(). And I would either say that we should use the trick with the NOP to reserve space on the ring buffer or call amdgpu_device_wb_get() for each read. amdgpu_device_wb_get() also uses find_first_zero_bit() and should work equally well. You also don't need to worry to much about overflowing the wb area. Since we run in an atomic context we can have at most the number of CPU in the system + interrupt context here. Regards, Christian. Am 22.04.20 um 09:11 schrieb Tao, Yintian: Add Felix and Shaoyun -Original Message- From: Yintian Tao Sent: 2020年4月22日 12:42 To: Koenig, Christian ; Liu, Monk Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian Subject: [PATCH] drm/amdgpu: refine kiq access register According to the current kiq access register method, there will be race condition when using KIQ to read register if multiple clients want to read at same time just like the expample below: 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the kiq complete these two read operation 6. client-A to read the register at the wb buffer and get REG-1 value And if there are multiple clients to frequently write registers through KIQ which may raise the KIQ ring buffer overwritten problem. Therefore, allocate fixed number wb slot for rreg use and limit the submit number which depends on the
RE: [PATCH] drm/amdgpu: refine kiq access register
Hi Christian Please see inline comments -Original Message- From: Koenig, Christian Sent: 2020年4月22日 15:54 To: Tao, Yintian ; Liu, Monk ; Liu, Shaoyun ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq access register Am 22.04.20 um 09:49 schrieb Tao, Yintian: > Hi Christian > > > Please see inline comments. > -Original Message- > From: Christian König > Sent: 2020年4月22日 15:40 > To: Tao, Yintian ; Koenig, Christian > ; Liu, Monk ; Liu, Shaoyun > ; Kuehling, Felix > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: refine kiq access register > > Am 22.04.20 um 09:35 schrieb Tao, Yintian: >> Hi Christian >> >> >>> BUG_ON(in_interrupt()); >> That won't work like this. The KIQ is also used in interrupt context in the >> driver, that's why we used spin_lock_irqsave(). >> [yttao]: According to the current drm-next code, I have not find where to >> access register through KIQ. >> And you need to wait for the free kiq ring buffer space if >> there is no free kiq ring buffer, here, you wait at interrupt context is >> illegal. > Waiting in atomic context is illegal as well, but we don't have much other > choice. > [yttao]: no, there is no sleep in atomic context at my patch. I'm not talking about a sleeping, but busy waiting. > We just need to make sure that waiting never happens by making the buffers > large enough and if it still happens print and error. > [yttao]: this is not the good choice because KMD need to protect it instead > of hoping user not frequently invoke KIQ acess. The only other choice we have is busy waiting, e.g. loop until we get a free slot. [yttao]: Yes, now may patch use msleep() to busy waiting. Or you means need to use udelay()? If we use udelay(), it will be the nightmare under multi-VF. Because it is assumed that there are 16VF within world-switch 6ms, the bad situation is that one VF will udelay(16*6ms = 96ms) to get one free slot. Regards, Christian. > >> And I would either say that we should use the trick with the NOP to reserve >> space on the ring buffer or call amdgpu_device_wb_get() for each read. >> amdgpu_device_wb_get() also uses find_first_zero_bit() and should work >> equally well. >> [yttao]: sorry, can you give me more details about how to use NOP to reserve >> space? I will use amdgpu_device_wb_get() for the read operation. > We could use the NOP PM4 command as Felix suggested, this command has > a > header+length and says that the next X dw should be ignore on the ring > buffer. > > But I think using amdgpu_device_wb_get() is better anyway. > [yttao]: yes, I agreed with amdgpu_device_wb_get() method because it > will fix prevent potential read race condition but NOP method will not > prevent it > > Regards, > Christian. > >> >> >> -Original Message- >> From: Koenig, Christian >> Sent: 2020年4月22日 15:23 >> To: Tao, Yintian ; Liu, Monk ; >> Liu, Shaoyun ; Kuehling, Felix >> >> Cc: amd-gfx@lists.freedesktop.org >> Subject: Re: [PATCH] drm/amdgpu: refine kiq access register >> >>> BUG_ON(in_interrupt()); >> That won't work like this. The KIQ is also used in interrupt context in the >> driver, that's why we used spin_lock_irqsave(). >> >> And I would either say that we should use the trick with the NOP to reserve >> space on the ring buffer or call amdgpu_device_wb_get() for each read. >> amdgpu_device_wb_get() also uses find_first_zero_bit() and should work >> equally well. >> >> You also don't need to worry to much about overflowing the wb area. >> Since we run in an atomic context we can have at most the number of CPU in >> the system + interrupt context here. >> >> Regards, >> Christian. >> >> Am 22.04.20 um 09:11 schrieb Tao, Yintian: >>> Add Felix and Shaoyun >>> >>> -Original Message- >>> From: Yintian Tao >>> Sent: 2020年4月22日 12:42 >>> To: Koenig, Christian ; Liu, Monk >>> >>> Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian >>> >>> Subject: [PATCH] drm/amdgpu: refine kiq access register >>> >>> According to the current kiq access register method, there will be race >>> condition when using KIQ to read register if multiple clients want to read >>> at same time just like the expample below: >>> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3. >>> client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5.
Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 09:49 schrieb Tao, Yintian: Hi Christian Please see inline comments. -Original Message- From: Christian König Sent: 2020年4月22日 15:40 To: Tao, Yintian ; Koenig, Christian ; Liu, Monk ; Liu, Shaoyun ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq access register Am 22.04.20 um 09:35 schrieb Tao, Yintian: Hi Christian BUG_ON(in_interrupt()); That won't work like this. The KIQ is also used in interrupt context in the driver, that's why we used spin_lock_irqsave(). [yttao]: According to the current drm-next code, I have not find where to access register through KIQ. And you need to wait for the free kiq ring buffer space if there is no free kiq ring buffer, here, you wait at interrupt context is illegal. Waiting in atomic context is illegal as well, but we don't have much other choice. [yttao]: no, there is no sleep in atomic context at my patch. I'm not talking about a sleeping, but busy waiting. We just need to make sure that waiting never happens by making the buffers large enough and if it still happens print and error. [yttao]: this is not the good choice because KMD need to protect it instead of hoping user not frequently invoke KIQ acess. The only other choice we have is busy waiting, e.g. loop until we get a free slot. Regards, Christian. And I would either say that we should use the trick with the NOP to reserve space on the ring buffer or call amdgpu_device_wb_get() for each read. amdgpu_device_wb_get() also uses find_first_zero_bit() and should work equally well. [yttao]: sorry, can you give me more details about how to use NOP to reserve space? I will use amdgpu_device_wb_get() for the read operation. We could use the NOP PM4 command as Felix suggested, this command has a header+length and says that the next X dw should be ignore on the ring buffer. But I think using amdgpu_device_wb_get() is better anyway. [yttao]: yes, I agreed with amdgpu_device_wb_get() method because it will fix prevent potential read race condition but NOP method will not prevent it Regards, Christian. -Original Message- From: Koenig, Christian Sent: 2020年4月22日 15:23 To: Tao, Yintian ; Liu, Monk ; Liu, Shaoyun ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq access register BUG_ON(in_interrupt()); That won't work like this. The KIQ is also used in interrupt context in the driver, that's why we used spin_lock_irqsave(). And I would either say that we should use the trick with the NOP to reserve space on the ring buffer or call amdgpu_device_wb_get() for each read. amdgpu_device_wb_get() also uses find_first_zero_bit() and should work equally well. You also don't need to worry to much about overflowing the wb area. Since we run in an atomic context we can have at most the number of CPU in the system + interrupt context here. Regards, Christian. Am 22.04.20 um 09:11 schrieb Tao, Yintian: Add Felix and Shaoyun -Original Message- From: Yintian Tao Sent: 2020年4月22日 12:42 To: Koenig, Christian ; Liu, Monk Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian Subject: [PATCH] drm/amdgpu: refine kiq access register According to the current kiq access register method, there will be race condition when using KIQ to read register if multiple clients want to read at same time just like the expample below: 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3. client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the kiq complete these two read operation 6. client-A to read the register at the wb buffer and get REG-1 value And if there are multiple clients to frequently write registers through KIQ which may raise the KIQ ring buffer overwritten problem. Therefore, allocate fixed number wb slot for rreg use and limit the submit number which depends on the kiq ring_size in order to prevent the overwritten problem. Signed-off-by: Yintian Tao --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 7 +- .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 12 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 12 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 129 -- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 13 +- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 8 +- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 34 +++-- drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c| 12 +- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 12 +- 12 files changed, 211 insertions(+), 48 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 4e1d4cfe7a9f..4530e0de4257 1006
RE: [PATCH] drm/amdgpu: refine kiq access register
Hi Christian Please see inline comments. -Original Message- From: Christian König Sent: 2020年4月22日 15:40 To: Tao, Yintian ; Koenig, Christian ; Liu, Monk ; Liu, Shaoyun ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: refine kiq access register Am 22.04.20 um 09:35 schrieb Tao, Yintian: > Hi Christian > > >> BUG_ON(in_interrupt()); > That won't work like this. The KIQ is also used in interrupt context in the > driver, that's why we used spin_lock_irqsave(). > [yttao]: According to the current drm-next code, I have not find where to > access register through KIQ. > And you need to wait for the free kiq ring buffer space if > there is no free kiq ring buffer, here, you wait at interrupt context is > illegal. Waiting in atomic context is illegal as well, but we don't have much other choice. [yttao]: no, there is no sleep in atomic context at my patch. We just need to make sure that waiting never happens by making the buffers large enough and if it still happens print and error. [yttao]: this is not the good choice because KMD need to protect it instead of hoping user not frequently invoke KIQ acess. > And I would either say that we should use the trick with the NOP to reserve > space on the ring buffer or call amdgpu_device_wb_get() for each read. > amdgpu_device_wb_get() also uses find_first_zero_bit() and should work > equally well. > [yttao]: sorry, can you give me more details about how to use NOP to reserve > space? I will use amdgpu_device_wb_get() for the read operation. We could use the NOP PM4 command as Felix suggested, this command has a header+length and says that the next X dw should be ignore on the ring buffer. But I think using amdgpu_device_wb_get() is better anyway. [yttao]: yes, I agreed with amdgpu_device_wb_get() method because it will fix prevent potential read race condition but NOP method will not prevent it Regards, Christian. > > > > -Original Message- > From: Koenig, Christian > Sent: 2020年4月22日 15:23 > To: Tao, Yintian ; Liu, Monk ; Liu, > Shaoyun ; Kuehling, Felix > Cc: amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: refine kiq access register > >> BUG_ON(in_interrupt()); > That won't work like this. The KIQ is also used in interrupt context in the > driver, that's why we used spin_lock_irqsave(). > > And I would either say that we should use the trick with the NOP to reserve > space on the ring buffer or call amdgpu_device_wb_get() for each read. > amdgpu_device_wb_get() also uses find_first_zero_bit() and should work > equally well. > > You also don't need to worry to much about overflowing the wb area. > Since we run in an atomic context we can have at most the number of CPU in > the system + interrupt context here. > > Regards, > Christian. > > Am 22.04.20 um 09:11 schrieb Tao, Yintian: >> Add Felix and Shaoyun >> >> -Original Message- >> From: Yintian Tao >> Sent: 2020年4月22日 12:42 >> To: Koenig, Christian ; Liu, Monk >> >> Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian >> Subject: [PATCH] drm/amdgpu: refine kiq access register >> >> According to the current kiq access register method, there will be race >> condition when using KIQ to read register if multiple clients want to read >> at same time just like the expample below: >> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3. >> client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the >> kiq complete these two read operation 6. client-A to read the register at >> the wb buffer and >> get REG-1 value >> >> And if there are multiple clients to frequently write registers through KIQ >> which may raise the KIQ ring buffer overwritten problem. >> >> Therefore, allocate fixed number wb slot for rreg use and limit the submit >> number which depends on the kiq ring_size in order to prevent the >> overwritten problem. >> >> Signed-off-by: Yintian Tao >> --- >>drivers/gpu/drm/amd/amdgpu/amdgpu.h | 7 +- >>.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 12 +- >>.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 12 +- >>drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 129 -- >>drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 6 +- >>drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 6 +- >>drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 13 +- >>drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 8 +- >>drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +- >>drivers/gpu/drm/amd/amdgpu/gfx_v
Re: [PATCH] drm/amdgpu: refine kiq access register
Am 22.04.20 um 09:35 schrieb Tao, Yintian:
Hi Christian
BUG_ON(in_interrupt());
That won't work like this. The KIQ is also used in interrupt context in the
driver, that's why we used spin_lock_irqsave().
[yttao]: According to the current drm-next code, I have not find where to
access register through KIQ.
And you need to wait for the free kiq ring buffer space if
there is no free kiq ring buffer, here, you wait at interrupt context is
illegal.
Waiting in atomic context is illegal as well, but we don't have much
other choice.
We just need to make sure that waiting never happens by making the
buffers large enough and if it still happens print and error.
And I would either say that we should use the trick with the NOP to reserve
space on the ring buffer or call amdgpu_device_wb_get() for each read.
amdgpu_device_wb_get() also uses find_first_zero_bit() and should work equally
well.
[yttao]: sorry, can you give me more details about how to use NOP to reserve
space? I will use amdgpu_device_wb_get() for the read operation.
We could use the NOP PM4 command as Felix suggested, this command has a
header+length and says that the next X dw should be ignore on the ring
buffer.
But I think using amdgpu_device_wb_get() is better anyway.
Regards,
Christian.
-Original Message-
From: Koenig, Christian
Sent: 2020年4月22日 15:23
To: Tao, Yintian ; Liu, Monk ; Liu, Shaoyun
; Kuehling, Felix
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
BUG_ON(in_interrupt());
That won't work like this. The KIQ is also used in interrupt context in the
driver, that's why we used spin_lock_irqsave().
And I would either say that we should use the trick with the NOP to reserve
space on the ring buffer or call amdgpu_device_wb_get() for each read.
amdgpu_device_wb_get() also uses find_first_zero_bit() and should work equally
well.
You also don't need to worry to much about overflowing the wb area.
Since we run in an atomic context we can have at most the number of CPU in the
system + interrupt context here.
Regards,
Christian.
Am 22.04.20 um 09:11 schrieb Tao, Yintian:
Add Felix and Shaoyun
-Original Message-
From: Yintian Tao
Sent: 2020年4月22日 12:42
To: Koenig, Christian ; Liu, Monk
Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
Subject: [PATCH] drm/amdgpu: refine kiq access register
According to the current kiq access register method, there will be race
condition when using KIQ to read register if multiple clients want to read at
same time just like the expample below:
1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3.
client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the
kiq complete these two read operation 6. client-A to read the register at the
wb buffer and
get REG-1 value
And if there are multiple clients to frequently write registers through KIQ
which may raise the KIQ ring buffer overwritten problem.
Therefore, allocate fixed number wb slot for rreg use and limit the submit
number which depends on the kiq ring_size in order to prevent the overwritten
problem.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 7 +-
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 12 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 12 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 129 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 13 +-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 8 +-
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 34 +++--
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c| 12 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 12 +-
12 files changed, 211 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4e1d4cfe7a9f..4530e0de4257 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -526,7 +526,7 @@ static inline void amdgpu_set_ib_value(struct
amdgpu_cs_parser *p,
/*
* Writeback
*/
-#define AMDGPU_MAX_WB 128 /* Reserve at most 128 WB slots for
amdgpu-owned rings. */
+#define AMDGPU_MAX_WB 256 /* Reserve at most 256 WB slots for
amdgpu-owned rings. */
struct amdgpu_wb {
struct amdgpu_bo*wb_obj;
@@ -1028,6 +1028,11 @@ bool amdgpu_device_has_dc_support(struct
amdgpu_device *adev);
int emu_soc_asic_init(struct amdgpu_device *adev);
+int amdgpu_gfx_kiq_lock(struct amdgpu_kiq *kiq, bool read); void
+amdgpu_gfx_kiq_unlock(struct amdgpu_kiq *kiq);
+
+void amdgpu_gfx_kiq_consume(struct amdgpu_kiq *kiq, uint32_t *offs);
+void amdgpu_gfx_kiq_restore(struct amdgpu_kiq *kiq, uint32_t *off
RE: [PATCH] drm/amdgpu: refine kiq access register
Hi Christian
> BUG_ON(in_interrupt());
That won't work like this. The KIQ is also used in interrupt context in the
driver, that's why we used spin_lock_irqsave().
[yttao]: According to the current drm-next code, I have not find where to
access register through KIQ.
And you need to wait for the free kiq ring buffer space if
there is no free kiq ring buffer, here, you wait at interrupt context is
illegal.
And I would either say that we should use the trick with the NOP to reserve
space on the ring buffer or call amdgpu_device_wb_get() for each read.
amdgpu_device_wb_get() also uses find_first_zero_bit() and should work equally
well.
[yttao]: sorry, can you give me more details about how to use NOP to reserve
space? I will use amdgpu_device_wb_get() for the read operation.
-Original Message-
From: Koenig, Christian
Sent: 2020年4月22日 15:23
To: Tao, Yintian ; Liu, Monk ; Liu,
Shaoyun ; Kuehling, Felix
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine kiq access register
> BUG_ON(in_interrupt());
That won't work like this. The KIQ is also used in interrupt context in the
driver, that's why we used spin_lock_irqsave().
And I would either say that we should use the trick with the NOP to reserve
space on the ring buffer or call amdgpu_device_wb_get() for each read.
amdgpu_device_wb_get() also uses find_first_zero_bit() and should work equally
well.
You also don't need to worry to much about overflowing the wb area.
Since we run in an atomic context we can have at most the number of CPU in the
system + interrupt context here.
Regards,
Christian.
Am 22.04.20 um 09:11 schrieb Tao, Yintian:
> Add Felix and Shaoyun
>
> -Original Message-
> From: Yintian Tao
> Sent: 2020年4月22日 12:42
> To: Koenig, Christian ; Liu, Monk
>
> Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
> Subject: [PATCH] drm/amdgpu: refine kiq access register
>
> According to the current kiq access register method, there will be race
> condition when using KIQ to read register if multiple clients want to read at
> same time just like the expample below:
> 1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3.
> client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the
> kiq complete these two read operation 6. client-A to read the register at the
> wb buffer and
> get REG-1 value
>
> And if there are multiple clients to frequently write registers through KIQ
> which may raise the KIQ ring buffer overwritten problem.
>
> Therefore, allocate fixed number wb slot for rreg use and limit the submit
> number which depends on the kiq ring_size in order to prevent the overwritten
> problem.
>
> Signed-off-by: Yintian Tao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 7 +-
> .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 12 +-
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 12 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 129 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 13 +-
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 8 +-
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 34 +++--
> drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c| 12 +-
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 12 +-
> 12 files changed, 211 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 4e1d4cfe7a9f..4530e0de4257 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -526,7 +526,7 @@ static inline void amdgpu_set_ib_value(struct
> amdgpu_cs_parser *p,
> /*
>* Writeback
>*/
> -#define AMDGPU_MAX_WB 128/* Reserve at most 128 WB slots for
> amdgpu-owned rings. */
> +#define AMDGPU_MAX_WB 256/* Reserve at most 256 WB slots for
> amdgpu-owned rings. */
>
> struct amdgpu_wb {
> struct amdgpu_bo*wb_obj;
> @@ -1028,6 +1028,11 @@ bool amdgpu_device_has_dc_support(struct
> amdgpu_device *adev);
>
> int emu_soc_asic_init(struct amdgpu_device *adev);
>
> +int amdgpu_gfx_kiq_lock(struct amdgpu_kiq *kiq, bool read); void
> +amdgpu_gfx_kiq_unlock(struct amdgpu_kiq *kiq);
> +
> +void amdgpu_gfx_kiq_consume(struct amdgpu_kiq *kiq, uint32_t *offs);
> +void amdgpu_gfx_kiq_restore(struct amdgpu_kiq *kiq, uint32_t *offs);
> /*
>* Registers read & write functions.
>*/
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amd
Re: [PATCH] drm/amdgpu: refine kiq access register
BUG_ON(in_interrupt());
That won't work like this. The KIQ is also used in interrupt context in
the driver, that's why we used spin_lock_irqsave().
And I would either say that we should use the trick with the NOP to
reserve space on the ring buffer or call amdgpu_device_wb_get() for each
read. amdgpu_device_wb_get() also uses find_first_zero_bit() and should
work equally well.
You also don't need to worry to much about overflowing the wb area.
Since we run in an atomic context we can have at most the number of CPU
in the system + interrupt context here.
Regards,
Christian.
Am 22.04.20 um 09:11 schrieb Tao, Yintian:
Add Felix and Shaoyun
-Original Message-
From: Yintian Tao
Sent: 2020年4月22日 12:42
To: Koenig, Christian ; Liu, Monk
Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
Subject: [PATCH] drm/amdgpu: refine kiq access register
According to the current kiq access register method, there will be race
condition when using KIQ to read register if multiple clients want to read at
same time just like the expample below:
1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3.
client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the
kiq complete these two read operation 6. client-A to read the register at the
wb buffer and
get REG-1 value
And if there are multiple clients to frequently write registers through KIQ
which may raise the KIQ ring buffer overwritten problem.
Therefore, allocate fixed number wb slot for rreg use and limit the submit
number which depends on the kiq ring_size in order to prevent the overwritten
problem.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 7 +-
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 12 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 12 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 129 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 13 +-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 8 +-
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 34 +++--
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c| 12 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 12 +-
12 files changed, 211 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4e1d4cfe7a9f..4530e0de4257 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -526,7 +526,7 @@ static inline void amdgpu_set_ib_value(struct
amdgpu_cs_parser *p,
/*
* Writeback
*/
-#define AMDGPU_MAX_WB 128 /* Reserve at most 128 WB slots for
amdgpu-owned rings. */
+#define AMDGPU_MAX_WB 256 /* Reserve at most 256 WB slots for
amdgpu-owned rings. */
struct amdgpu_wb {
struct amdgpu_bo*wb_obj;
@@ -1028,6 +1028,11 @@ bool amdgpu_device_has_dc_support(struct amdgpu_device
*adev);
int emu_soc_asic_init(struct amdgpu_device *adev);
+int amdgpu_gfx_kiq_lock(struct amdgpu_kiq *kiq, bool read); void
+amdgpu_gfx_kiq_unlock(struct amdgpu_kiq *kiq);
+
+void amdgpu_gfx_kiq_consume(struct amdgpu_kiq *kiq, uint32_t *offs);
+void amdgpu_gfx_kiq_restore(struct amdgpu_kiq *kiq, uint32_t *offs);
/*
* Registers read & write functions.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index 691c89705bcd..034c9f416499 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -309,6 +309,7 @@ static int kgd_hiq_mqd_load(struct kgd_dev *kgd, void *mqd,
uint32_t doorbell_off)
{
struct amdgpu_device *adev = get_amdgpu_device(kgd);
+ struct amdgpu_kiq *kiq = &adev->gfx.kiq;
struct amdgpu_ring *kiq_ring = &adev->gfx.kiq.ring;
struct v10_compute_mqd *m;
uint32_t mec, pipe;
@@ -324,13 +325,19 @@ static int kgd_hiq_mqd_load(struct kgd_dev *kgd, void
*mqd,
pr_debug("kfd: set HIQ, mec:%d, pipe:%d, queue:%d.\n",
mec, pipe, queue_id);
- spin_lock(&adev->gfx.kiq.ring_lock);
+ r = amdgpu_gfx_kiq_lock(kiq, false);
+ if (r) {
+ pr_err("failed to lock kiq\n");
+ goto out_unlock;
+ }
+
r = amdgpu_ring_alloc(kiq_ring, 7);
if (r) {
pr_err("Failed to alloc KIQ (%d).\n", r);
goto out_unlock;
}
+ amdgpu_gfx_kiq_consume(kiq, NULL);
amdgpu_ring_write(kiq_ring, PACKET3(PACKET3_MAP_QUEUES, 5));
amdgpu_ring_write(kiq_ring,
PACKET3_MAP_QUEUES_QUEUE_SEL(0) | /* Queue_Sel */ @@
-350,8 +357,9 @@ static int kgd_hiq_mqd_load(struct kgd_dev *kgd, void *mqd,
amdgpu_ring_write(kiq_ring, m->cp_hqd_pq_wptr_poll_
RE: [PATCH] drm/amdgpu: refine kiq access register
Add Felix and Shaoyun
-Original Message-
From: Yintian Tao
Sent: 2020年4月22日 12:42
To: Koenig, Christian ; Liu, Monk
Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
Subject: [PATCH] drm/amdgpu: refine kiq access register
According to the current kiq access register method, there will be race
condition when using KIQ to read register if multiple clients want to read at
same time just like the expample below:
1. client-A start to read REG-0 throguh KIQ 2. client-A poll the seqno-0 3.
client-B start to read REG-1 through KIQ 4. client-B poll the seqno-1 5. the
kiq complete these two read operation 6. client-A to read the register at the
wb buffer and
get REG-1 value
And if there are multiple clients to frequently write registers through KIQ
which may raise the KIQ ring buffer overwritten problem.
Therefore, allocate fixed number wb slot for rreg use and limit the submit
number which depends on the kiq ring_size in order to prevent the overwritten
problem.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 7 +-
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 12 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 12 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 129 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 13 +-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 8 +-
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 8 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 34 +++--
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c| 12 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 12 +-
12 files changed, 211 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4e1d4cfe7a9f..4530e0de4257 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -526,7 +526,7 @@ static inline void amdgpu_set_ib_value(struct
amdgpu_cs_parser *p,
/*
* Writeback
*/
-#define AMDGPU_MAX_WB 128 /* Reserve at most 128 WB slots for
amdgpu-owned rings. */
+#define AMDGPU_MAX_WB 256 /* Reserve at most 256 WB slots for
amdgpu-owned rings. */
struct amdgpu_wb {
struct amdgpu_bo*wb_obj;
@@ -1028,6 +1028,11 @@ bool amdgpu_device_has_dc_support(struct amdgpu_device
*adev);
int emu_soc_asic_init(struct amdgpu_device *adev);
+int amdgpu_gfx_kiq_lock(struct amdgpu_kiq *kiq, bool read); void
+amdgpu_gfx_kiq_unlock(struct amdgpu_kiq *kiq);
+
+void amdgpu_gfx_kiq_consume(struct amdgpu_kiq *kiq, uint32_t *offs);
+void amdgpu_gfx_kiq_restore(struct amdgpu_kiq *kiq, uint32_t *offs);
/*
* Registers read & write functions.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index 691c89705bcd..034c9f416499 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -309,6 +309,7 @@ static int kgd_hiq_mqd_load(struct kgd_dev *kgd, void *mqd,
uint32_t doorbell_off)
{
struct amdgpu_device *adev = get_amdgpu_device(kgd);
+ struct amdgpu_kiq *kiq = &adev->gfx.kiq;
struct amdgpu_ring *kiq_ring = &adev->gfx.kiq.ring;
struct v10_compute_mqd *m;
uint32_t mec, pipe;
@@ -324,13 +325,19 @@ static int kgd_hiq_mqd_load(struct kgd_dev *kgd, void
*mqd,
pr_debug("kfd: set HIQ, mec:%d, pipe:%d, queue:%d.\n",
mec, pipe, queue_id);
- spin_lock(&adev->gfx.kiq.ring_lock);
+ r = amdgpu_gfx_kiq_lock(kiq, false);
+ if (r) {
+ pr_err("failed to lock kiq\n");
+ goto out_unlock;
+ }
+
r = amdgpu_ring_alloc(kiq_ring, 7);
if (r) {
pr_err("Failed to alloc KIQ (%d).\n", r);
goto out_unlock;
}
+ amdgpu_gfx_kiq_consume(kiq, NULL);
amdgpu_ring_write(kiq_ring, PACKET3(PACKET3_MAP_QUEUES, 5));
amdgpu_ring_write(kiq_ring,
PACKET3_MAP_QUEUES_QUEUE_SEL(0) | /* Queue_Sel */ @@
-350,8 +357,9 @@ static int kgd_hiq_mqd_load(struct kgd_dev *kgd, void *mqd,
amdgpu_ring_write(kiq_ring, m->cp_hqd_pq_wptr_poll_addr_hi);
amdgpu_ring_commit(kiq_ring);
+ amdgpu_gfx_kiq_restore(kiq, NULL);
out_unlock:
- spin_unlock(&adev->gfx.kiq.ring_lock);
+ amdgpu_gfx_kiq_unlock(&adev->gfx.kiq);
release_queue(kgd);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
index df841c2ac5e7..f243d9990ced 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
@@ -307,6 +307,7 @@ int kgd_gfx_v9_hiq_mqd_load(struct kgd_dev *kgd, void *mqd,
uint32_t doorbell_off)
{
