| Message ID | 20180625054741.3919-1-dhinakaran.pandiyan@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Jun 24, 2018 at 10:47:40PM -0700, Dhinakaran Pandiyan wrote: > Commit 5422b37c907e ("drm/i915/psr: Kill delays when activating psr > back.") switched from delayed work to the plain variant and while doing so > removed 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 the two psr_activate() calls, warning messages get printed. > 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. :( my bad again, sorry... Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Fixes: 5422b37c907e ("drm/i915/psr: Kill delays when activating psr back.") > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106948 > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Cc: José Roberto de Souza <jose.souza@intel.com> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> > --- > drivers/gpu/drm/i915/intel_psr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c > index aea81ace854b..7aa324f0d1f7 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -811,7 +811,7 @@ static void intel_psr_work(struct work_struct *work) > * recheck. Since psr_flush first clears this and then reschedules we > * won't ever miss a flush when bailing out here. > */ > - if (dev_priv->psr.busy_frontbuffer_bits) > + if (dev_priv->psr.busy_frontbuffer_bits || dev_priv->psr.active) > goto unlock; > > intel_psr_activate(dev_priv->psr.enabled); > -- > 2.14.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index aea81ace854b..7aa324f0d1f7 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -811,7 +811,7 @@ static void intel_psr_work(struct work_struct *work) * recheck. Since psr_flush first clears this and then reschedules we * won't ever miss a flush when bailing out here. */ - if (dev_priv->psr.busy_frontbuffer_bits) + if (dev_priv->psr.busy_frontbuffer_bits || dev_priv->psr.active) goto unlock; intel_psr_activate(dev_priv->psr.enabled);
Commit 5422b37c907e ("drm/i915/psr: Kill delays when activating psr back.") switched from delayed work to the plain variant and while doing so removed 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 the two psr_activate() calls, warning messages get printed. 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. Fixes: 5422b37c907e ("drm/i915/psr: Kill delays when activating psr back.") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106948 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/intel_psr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)