| Message ID | 20180127024923.3093-1-dhinakaran.pandiyan@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Jan 27, 2018 at 02:49:15AM +0000, Dhinakaran Pandiyan wrote: > There is no corresponding invalidate call before the buffer is written > to, this results in screen freezing sometime after switching to console > mode with PSR enabled. Invalidating the front buffer in the fbdev call > backs won't work either as some of them are called in atomic contexts and > {drrs, fbc, psr}_invalidate all sleep. So don't activate PSR for now. > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> > --- > drivers/gpu/drm/i915/intel_psr.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c > index e9feffdea899..c12af1118647 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -881,6 +881,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv, > if (!CAN_PSR(dev_priv)) > return; > > + if (origin == ORIGIN_DIRTYFB) > + return; > + I'd like Paulo to take a look here. What I'm confused now is who (what fbt bit) is actually blocking PSR to work on fbdev. And what would be the risks of other corner cases or the risk of this not getting psr re-enabled until next reboot... > mutex_lock(&dev_priv->psr.lock); > if (!dev_priv->psr.enabled) { > mutex_unlock(&dev_priv->psr.lock); > -- > 2.14.1 >
On Wed, 2018-01-31 at 22:56 -0800, Rodrigo Vivi wrote: > On Sat, Jan 27, 2018 at 02:49:15AM +0000, Dhinakaran Pandiyan wrote: > > There is no corresponding invalidate call before the buffer is written > > to, this results in screen freezing sometime after switching to console > > mode with PSR enabled. Invalidating the front buffer in the fbdev call > > backs won't work either as some of them are called in atomic contexts and > > {drrs, fbc, psr}_invalidate all sleep. So don't activate PSR for now. > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> > > --- > > drivers/gpu/drm/i915/intel_psr.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c > > index e9feffdea899..c12af1118647 100644 > > --- a/drivers/gpu/drm/i915/intel_psr.c > > +++ b/drivers/gpu/drm/i915/intel_psr.c > > @@ -881,6 +881,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv, > > if (!CAN_PSR(dev_priv)) > > return; > > > > + if (origin == ORIGIN_DIRTYFB) > > + return; > > + > > I'd like Paulo to take a look here. > > What I'm confused now is who (what fbt bit) is actually blocking PSR to work > on fbdev. intel_psr_flush()->intel_psr_exit() does get called as expected, so it's not the frontbuffer bit that is preventing PSR from exiting. I don't fully understand why exactly intel_psr_flush() is insufficient (without psr_invalidate()). One thing that might be of interest is the gem object has write domain as zero. I am wondering if we are missing some initialization. But, that does not explain why the screen freezes only with PSR > > And what would be the risks of other corner cases or the risk of this > not getting psr re-enabled until next reboot... > > > mutex_lock(&dev_priv->psr.lock); > > if (!dev_priv->psr.enabled) { > > mutex_unlock(&dev_priv->psr.lock); > > -- > > 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 e9feffdea899..c12af1118647 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -881,6 +881,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv, if (!CAN_PSR(dev_priv)) return; + if (origin == ORIGIN_DIRTYFB) + return; + mutex_lock(&dev_priv->psr.lock); if (!dev_priv->psr.enabled) { mutex_unlock(&dev_priv->psr.lock);
There is no corresponding invalidate call before the buffer is written to, this results in screen freezing sometime after switching to console mode with PSR enabled. Invalidating the front buffer in the fbdev call backs won't work either as some of them are called in atomic contexts and {drrs, fbc, psr}_invalidate all sleep. So don't activate PSR for now. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> --- drivers/gpu/drm/i915/intel_psr.c | 3 +++ 1 file changed, 3 insertions(+)