From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 1/3] drm/i915: Wait for pending flips in intel_pipe_set_base() Date: Fri, 02 Nov 2012 14:28:39 +0000 Message-ID: <453bf0$6armao@azsmga001.ch.intel.com> References: <1351793163-8542-1-git-send-email-ville.syrjala@linux.intel.com> <1351793163-8542-2-git-send-email-ville.syrjala@linux.intel.com> <453bf0$6aqv89@azsmga001.ch.intel.com> <20121102140239.GU3791@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1133992402==" Return-path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by gabe.freedesktop.org (Postfix) with ESMTP id 8D3B69E8B4 for ; Fri, 2 Nov 2012 07:29:25 -0700 (PDT) In-Reply-To: <20121102140239.GU3791@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1133992402== Content-Type: text/plain On Fri, 2 Nov 2012 16:02:39 +0200, Ville Syrjälä wrote: > On Fri, Nov 02, 2012 at 01:26:56PM +0000, Chris Wilson wrote: > > On Thu, 1 Nov 2012 20:06:00 +0200, ville.syrjala@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > > > intel_pipe_set_base() never actually waited for any pending page flips > > > on the CRTC. It looks like it tried to, by calling intel_finish_fb() on > > > the current front buffer. But the pending flips were actually tracked > > > in the BO of the previous front buffer, so the call to intel_finish_fb() > > > never did anything useful. > > > > > > Now even the pending_flip counter is gone, so we should just > > > use intel_crtc_wait_for_pending_flips(), but since we're already holding > > > struct_mutex when we would call that function, we need another version > > > of it, that itself doesn't lock struct_mutex. > > > > > > Signed-off-by: Ville Syrjälä > > > > Your earlier point was that intel_finish_fb() is being called in the wrong > > place, if you fix that first you should not need the major surgery. > > I don't think it's the wrong place as such. We do need it for the > panning case. The only issue with the current place is that we end up > calling it twice in the full modeset path; once in crtc_disable(), > and then later in intel_pipe_set_base(). > > I could move the call up from intel_pipe_set_base() to intel_crtc_set_config() > so that it only gets called for panning. This would also solve the > locking issue, but it doesn't seem as efficient as the current > sequence, because we'd end up pinning the new buffer after waiting > for page flips. With the current sequence the flip can complete in > parallel while we're doing the pin operation. Oh well, I thought we could arrange the code such that we only had a single place were we needed to wait. The simplicity of that was appealing. In light of that, your approach looks reasonable. -Chris -- Chris Wilson, Intel Open Source Technology Centre --===============1133992402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1133992402==--