Quoting Tvrtko Ursulin (2018-05-30 17:56:20) > > On 29/05/2018 14:29, Chris Wilson wrote: > > During testing we encounter a conflict between SUSPEND_TEST_DEVICES and > > disabling reset (gem_eio/suspend). This results in the device continuing > > on without being reset, but since it has gone through HW sanitization to > > Has some test been failing because of this and since when? gem_eio/suspend? Yes. It will fail in the future because we'll remove all mmio from the process_csb(); it fails right now because we lose track of what interrupts we process across the suspend and may double handle CSB events. E.g. https://bugs.freedesktop.org/show_bug.cgi?id=106702 > > account for the suspend/resume cycle, we have to assume the device has > > been reset to its defaults. A simple way around this is to skip the > > sanitize phase for SUSPEND_TEST_DEVICES by moving it to suspend-late. > > So suspend_late is not called when suspending via SUSPEND_TEST_DEVICES? > Sounds weird to me that core allows a "half-way" suspend mode. But I am > not familiar with that code so don't know. Yes, weird is one way to describe it. > Either way, if we skip it, that only skips the reset which is skipped > anyway in gem_eio/suspend so I did not figure out the difference. We then also skip the call to reset->reset which we need after a real resume (when the device is powered up) and/or after the reset in sanitization. It's fiddly. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
