From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH] drm/i915: push commit_output_state past the
 crtc/encoder preparing
Date: Thu, 6 Sep 2012 13:46:58 -0700
Message-ID: <20120906134658.45dc1b7b@jbarnes-desktop>
References: <1346436730-22889-1-git-send-email-daniel.vetter@ffwll.ch>
	<1346787148-2564-1-git-send-email-daniel.vetter@ffwll.ch>
	<20120905112808.1feac430@jbarnes-desktop>
	<CAKMK7uGhYXs+V-2Gza_ChV5JusFyLA22Mo9M-3gyVVbWLcvmcA@mail.gmail.com>
	<20120905125026.01b92006@jbarnes-desktop>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com
	[50.87.16.10])
	by gabe.freedesktop.org (Postfix) with SMTP id 571DA9E793
	for <intel-gfx@lists.freedesktop.org>;
	Thu,  6 Sep 2012 13:46:58 -0700 (PDT)
In-Reply-To: <20120905125026.01b92006@jbarnes-desktop>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=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
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, Intel Graphics Development <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Wed, 5 Sep 2012 12:50:26 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Wed, 5 Sep 2012 21:48:52 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> 
> > On Wed, Sep 5, 2012 at 8:28 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > >
> > > The variables have me confused a little... I would have expected
> > > update_state to take modeset_pipes rather than prepare_pipes.  Could
> > > you use either?  Or will that not catch cases where we updated a pipe
> > > that was already on?
> > 
> > The abstract idea for these masks was the following: Any pipe that
> > changes anything goes into prepare_pipes. For any pipe that also
> > changes the mode, it goes in addition into the modeset_pipes mask, so
> > the later is a subset of prepare pipes. The idea here was to avoid the
> > modeset step where not necessary (e.g. when disabling the 2nd output
> > of a cloned crtc we only need to disable/enable, not change anything
> > with the mode or clocks). But after some in-depth discussion with
> > Paulo Zanoni I think we'll move large parts of the mode_set step into
> > the enable function (at least for hsw due to funky ordering
> > requirements), so I think this disdinction doesn't make sense.
> > 
> > The disable mask just contains those pipes that get fully disable (and
> > which then also get removed from the prepares/modset masks).
> > 
> > Hence I pass the prepares mask into update_states, not just the modeset mask.
> 
> Ok, that makes some sense.  Hopefully we can preserve the full mode set
> vs simple update behavior even after the refactoring for HSW.
> 

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

-- 
Jesse Barnes, Intel Open Source Technology Center