> On Fri, Mar 07, 2014 at 10:51:50AM +0100, Landry Breuil wrote: > > [...] > > To everyone experiencing this issue, can you try with this diff: > > [...] > > Seems to work. I get consistent ~60 FPS with glxgears during > suspend/resume cycles where before I'd get ~60 until the first suspend > and after resuming it'd cap at ~15. > > Would there be a downside to doing the thawing and mode restoration both > in DVACT_WAKEUP and DVACT_RESUME?
Somewhat sad. If this is what is causing the problem, it indicates that a bug lies somewhere else. The difference between DVACT_RESUME and DVACT_WAKEUP are as follows: In the resume sequence, after handling some very base or ISA principle parts of the machine, we still have interrupts disabled. We then traverse the device tree telling each driver that now is the time for doing some resume work, we request DVACT_RESUME work. In this phase, they should not call any function which might "sleep", because there will be nothing to wake things up. After that is done, we enable interrupts, and now traverse the device tree again with the second method DVACT_WAKEUP. In this case, any driver which decides to do work may call something which sleeps. This two step operation has managed to get suspend/resume to where it is. Now why was inteldrm changed to use DVACT_RESUME? Well, this driver is imported/modified from KMS upstream, and we have found a quite long code path that is difficult to verify as sleep free. Some tests were run, and DVACT_WAKEUP seemed to work. As a general principle if we can get DVACT_WAKEUP to work, we are better off. There are some big benefits if we can get it working...
