[PATCH] drm/amdgpu: fix the ib test hang when gfx is in "idle" state

[Huang Rui]

On Mon, Apr 23, 2018 at 05:57:06PM +0800, Koenig, Christian wrote:
> Hi Ray,
> 
> Am 23.04.2018 11:47 schrieb Huang Rui <ray.huang at amd.com>:
> 
>     On Fri, Apr 20, 2018 at 05:59:16PM +0800, Koenig, Christian wrote:
>     > Am 20.04.2018 um 11:40 schrieb Huang Rui:
>     > > "aaabaf4   drm/amdgpu: defer test IBs on the rings at boot (V3)"
>     > > Above patch defers the execution of gfx/compute ib tests. However, at
>     that time,
>     > > the gfx may already go into idle state. If "idle" gfx receives command
>     > > submission, it will get hang in the system. So we must add is_gfx_on
>     checking at
>     > > start of ib tests.
>     >
>     > Do I see that right that you just skip the IB test when the GFX block is
>     > already turned of? In this case that would be a clear NAK.
>     >
>     > BTW: How do you detect that we need to turn GFX on again?
> 
>     Christian, I know point. But there is a hang issue if we would like try to
>     disable/enable gfxoff with SMC message at runtime. Actually, I am trying to
>     find a good sequence to fix it. After that, I can even expose an debugfs
>     interface to configure that. So I have to skip the test for the moment when
>     gfx is in "idle".
> 
> 
> Working around that issue for the moment is ok, but please note that explicitly
> in both the commit message and a code comment.

OK. Will add it at V2.

> 
> But don't you run into the same problem when the UMD starts to submit commands?

When UMD starts, RLC firmware will detect the "draw" command, then it will
power up gfx. So it won't have problem at that time. The mainly state
machine doesn't expose to driver side yet.

> 
> I mean the idea of the IB test is that you "simulate" an userspace command
> submission and see if it works.
> 

Yes, agree. Any idea to "simulate" the "draw" command? Or please wait for
my fix for enabling/disabling gfxoff at runtime.

Thanks,
Ray