Am 15.05.2018 um 17:10 schrieb Rafael J. Wysocki:
Before applying anything like this I need to understand the failure in the first place.
Since direct_complete is optional anyway and it should be safe to call pm_runtime_suspended() at any time, I'm suspecting a bug in a driver that is exposed by the commit turned up by bisection.
Where's the code I need to look at?
Hello,
thanks for looking into this. To answer the question I need your expertise. I couldn't find out which device causes it. Since the freeze only happens of amdgpu is loaded I naturally thought the problematic device(s) would be bound to amdgpu. So I assumed the amdgpu-bound devices would be affected by your change, i.e. not have direct_complete set anymore. But I could not confirm this evidence during testing (I basically restricted my patch to devices which pass !strcmp(dev->driver->name, "amdgpu", and the system was still frozen upon resume).
Then I printed a list which pass "dev->direct_complete && !pm_runtime_suspended(dev)" (with this patch applied), and the list was *very* long (maybe 100+). I can perform this again if you find the list useful.
The sheer number of devices which pass "dev->direct_complete && !pm_runtime_suspended(dev)" made me think that your change should be re-considered, hence my patch.
So, please give me advice on how I can point you to the code that you'd like to look at. I assume key information which device(s) pass "dev->direct_complete && !pm_runtime_suspended(dev)" AND cause the freeze on !dev->direct_complete? I'm afraid that will take a very long time to find out.
Best regards.