[Intel-gfx] [PATCH 6/6] drm/i915: calculate pfit changes in set_config v2

Jesse Barnes jbarnes at virtuousgeek.org
Mon Nov 10 17:32:38 CET 2014


On Mon, 10 Nov 2014 18:20:56 +0200
Ander Conselvan de Oliveira <conselvan2 at gmail.com> wrote:

> On 11/06/2014 12:26 AM, Jesse Barnes wrote:
> > This should allow us to avoid mode sets for some panel fitter config
> > changes.
> >
> > v2:
> >    - fixup pfit comment (Ander)
> >
> > Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> > ---
> >   drivers/gpu/drm/i915/intel_display.c | 61 +++++++++++++++++++++++++++++-------
> >   1 file changed, 50 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 3f1515d..49281d7 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2835,17 +2835,8 @@ static void intel_update_pipe_size(struct intel_crtc *crtc)
> >   		return;
> >
> >   	/*
> > -	 * Update pipe size and adjust fitter if needed: the reason for this is
> > -	 * that in compute_mode_changes we check the native mode (not the pfit
> > -	 * mode) to see if we can flip rather than do a full mode set. In the
> > -	 * fastboot case, we'll flip, but if we don't update the pipesrc and
> > -	 * pfit state, we'll end up with a big fb scanned out into the wrong
> > -	 * sized surface.
> > -	 *
> > -	 * To fix this properly, we need to hoist the checks up into
> > -	 * compute_mode_changes (or above), check the actual pfit state and
> > -	 * whether the platform allows pfit disable with pipe active, and only
> > -	 * then update the pipesrc and pfit state, even on the flip path.
> > +	 * See intel_pfit_changed for info on when we're allowed to
> > +	 * do this w/o a pipe shutdown.
> >   	 */
> >
> >   	adjusted_mode = &crtc->config.adjusted_mode;
> > @@ -11171,6 +11162,50 @@ static void disable_crtc_nofb(struct intel_crtc *crtc)
> >   	crtc->new_config = NULL;
> >   }
> >
> > +/* Do we need a mode set due to pfit changes? */
> > +static bool intel_pfit_changed(struct drm_device *dev,
> > +			       struct intel_crtc_config *new_config,
> > +			       struct intel_crtc_config *cur_config)
> > +{
> > +	bool ret = false;
> > +
> > +	if (HAS_DDI(dev) || HAS_PCH_SPLIT(dev)) {
> > +		/*
> > +		 * On PCH platforms we can disable pfit w/o a pipe shutdown,
> > +		 * otherwise we'll need a mode set.
> > +		 */
> > +		if (new_config->pch_pfit.enabled &&
> > +		    cur_config->pch_pfit.enabled)
> > +			ret = false;
> > +		else if (new_config->pch_pfit.enabled &&
> > +			 !cur_config->pch_pfit.enabled)
> > +			ret = true;
> > +		else if (!new_config->pch_pfit.enabled &&
> > +			 cur_config->pch_pfit.enabled)
> > +			ret = false;
> > +		else if (!new_config->pch_pfit.enabled &&
> > +			 !cur_config->pch_pfit.enabled)
> > +			ret = false;
> > +	} else {
> > +		bool new_enabled, old_enabled;
> > +
> > +		new_enabled = !!(new_config->gmch_pfit.control & PFIT_ENABLE);
> > +		old_enabled = !!(cur_config->gmch_pfit.control & PFIT_ENABLE);
> > +
> > +		/* 9xx only needs a shutdown to disable pfit */
> > +		if (new_enabled && old_enabled)
> > +			ret = false;
> > +		else if (new_enabled && !old_enabled)
> > +			ret = false;
> > +		else if (!new_enabled && old_enabled)
> > +			ret = true;
> > +		else if (!new_enabled && !old_enabled)
> > +			ret = false;
> > +	}
> 
> Maybe I missed something, but I couldn't find anything in the 
> documentation the supports the claim above.  However, [1] and [2] read 
> that "[p]anel fitting should be enabled or disabled before the pipe is 
> enabled" on the documentation for the PFIT_CONTROL.
> 
> 
> [1] 
> https://01.org/linuxgraphics/sites/default/files/documentation/g45_vol_3_register_0_0.pdf
> [2] 
> https://01.org/linuxgraphics/sites/default/files/documentation/965_g35_vol_3_display_registers_updated_1.pdf

Yeah the docs are extra conservative on this.  But from memory, this is
what 965 allowed.  It would be good to do some extra testing though;
915/945 may allow both pfit enable and disable without a pipe shutdown.

-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list