Quoting Dhinakaran Pandiyan (2018-06-23 05:45:06) > commit 5422b37c907e ("drm/i915/psr: Kill delays when activating psr > back.") switched from delayed work to the plain variant and while doing so > remove the check for work_busy() before scheduling a PSR activation. > This appears to cause consecutive executions of psr_activate() in this > scenario - after a worker picks up the PSR work item for execution and > before the work function can acquire the PSR mutex, a psr_flush() can > get hold of the mutex and schedule another PSR work. Without a psr_exit() > between two psr_activate() calls, the warning messages get printed. Ok, that would explain the second work. > Further, since we drop the mutex in the midst of psr_work() to wait for > PSR to idle, another work item can also get scheduled. Fix this by > returning if PSR was already active. > > Note: > I am not 100% sure this is what is going on as I could not reproduce > the bug (https://bugs.freedesktop.org/show_bug.cgi?id=106948) > > This patch sort of defeats the point of the WARN_ON()s in psr_activate() > now, do we still need them? WARN_ON(active), yup. Seems reasonable to keep for the moment. WARN_ON(hw_state) would be worth keeping for some time. Hmm, shouldn't it be checking both PSR_CTL irrespective of intended mode. After switching psr1 to psr2 we should check that psr1 is disabled as well, and vice versa. > Cc: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@xxxxxxxxx> Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx