On Tue, Jun 17, 2014 at 08:07:28AM +0100, Chris Wilson wrote: > On Mon, Jun 16, 2014 at 07:51:35PM +0200, Daniel Vetter wrote: > > +void intel_edp_psr_invalidate(struct drm_device *dev, > > + unsigned frontbuffer_bits) > > +{ > > + struct drm_i915_private *dev_priv = dev->dev_private; > > + struct drm_crtc *crtc; > > + enum pipe pipe; > > + > > + if (!HAS_PSR(dev)) > > + return; > > if (!psr.enabled) > return; Already fixed. > > > + > > + > > + mutex_lock(&dev_priv->psr.lock); > > + crtc = dp_to_dig_port(dev_priv->psr.enabled)->base.base.crtc; > > + pipe = to_intel_crtc(crtc)->pipe; > > + > > + intel_edp_psr_do_exit(dev); > > + > > + frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe); > > + > > + dev_priv->psr.busy_frontbuffer_bits |= frontbuffer_bits; > > + mutex_unlock(&dev_priv->psr.lock); > > +} > > + > > +void intel_edp_psr_flush(struct drm_device *dev, > > + unsigned frontbuffer_bits) > > +{ > > + struct drm_i915_private *dev_priv = dev->dev_private; > > + struct drm_crtc *crtc; > > + enum pipe pipe; > > + > > + if (!HAS_PSR(dev)) > > + return; > > if (!psr.enabled) > return; > > > + > > + > > + mutex_lock(&dev_priv->psr.lock); > > + crtc = dp_to_dig_port(dev_priv->psr.enabled)->base.base.crtc; > > + pipe = to_intel_crtc(crtc)->pipe; > > + dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits; > > + > > + if (IS_HASWELL(dev) && > > + (frontbuffer_bits & INTEL_FRONTBUFFER_SPRITE(pipe))) > > + intel_edp_psr_do_exit(dev); > > This deserves comment explaining/referencing the discrepancy. Agreed. > > > + if (!dev_priv->psr.busy_frontbuffer_bits) > > + schedule_delayed_work(&dev_priv->psr.work, > > + msecs_to_jiffies(100)); > > 100ms made sense when queueing the task at the start of the write cycle, > but on flush, it only wants to be ~2frames. As we know we have an active > pipe here we could queue it for exactly N frames... Well I don't have real hw to test so figured I'll leave the actual hw touching code unchanged. What we really want is a function which uploads 1 final frame (starting from the next vblank) and then goes into psr immediately. But getting there is a 2nd step. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx