From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 15/15] drm/i915: Fix up PSR frontbuffer tracking Date: Tue, 17 Jun 2014 10:08:37 +0200 Message-ID: <20140617080837.GB5821@phenom.ffwll.local> References: <1402941095-27879-1-git-send-email-daniel.vetter@ffwll.ch> <1402941095-27879-16-git-send-email-daniel.vetter@ffwll.ch> <20140617070728.GK17744@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by gabe.freedesktop.org (Postfix) with ESMTP id DA6FF8A2A1 for ; Tue, 17 Jun 2014 01:08:44 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so5319009wib.12 for ; Tue, 17 Jun 2014 01:08:44 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140617070728.GK17744@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson , Daniel Vetter , Intel Graphics Development , Rodrigo Vivi List-Id: intel-gfx@lists.freedesktop.org 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