[PATCH] drm/amdgpu: fix a kcq hang issue for SRIOV

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 27, 2018 at 12:30 PM, Christian König
<christian.koenig at amd.com> wrote:
> Am 27.03.2018 um 17:52 schrieb Alex Deucher:
>>
>> [SNIP]
>>>>
>>>> 2. add the new callback implementation to gfx9 and gfx8 (I think gfx8
>>>> will need this as well since we support sr-iov there too)
>>>
>>>
>>> gfx8 doesn't have the hardware bug which seems to make this necessary,
>>> not
>>> does it have the same VMHUB design as gfx9.
>>
>> Oh, right, in this case it's the req/ack engines which were new for
>> soc15.  We may want the same fix for sdma4 though.
>
>
> And exactly that is one of the reasons why this workaround doesn't work
> correctly.
>
> The SDMA is not directly connected to the GFXHUB, so even if the SDMA would
> provide a single command for this the write/wait would still be executed as
> two operations.

I'm not sure I follow.  I think there are two issues: the hw bug you
are referring to and the SR-IOV requirement that the req and the ack
can't be split by a world switch.  I believe the world switch happens
at at least packet granularity so I think for the SR-IOV requirement
using a single packet should handle it.

>
> In other words we can again run into the problem and the same thing applies
> for CPU based updates.

yeah, CPU based updates could indeed be an issue for the SR-IOV
requirement, but in that case it's easier to read back and retry.

Alex


>
> The only real workaround would be to write the request, read the register
> back and if the write didn't succeeded write it again.
>
> But seriously remember that this issue is not limited to the VMHUB
> registers. Do you want to write and read back every register to make sure
> the write succeeded?
>
> Regards,
> Christian.


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux