[Intel-gfx] [PATCH 06/40] drm/i915: Add cdclk change support for chv

Jesse Barnes jbarnes at virtuousgeek.org
Tue Jul 29 20:07:09 CEST 2014


On Tue, 29 Jul 2014 19:59:26 +0200
Daniel Vetter <daniel at ffwll.ch> wrote:

> On Tue, Jul 29, 2014 at 09:51:03AM -0700, Jesse Barnes wrote:
> > On Sat, 28 Jun 2014 02:03:57 +0300
> > ville.syrjala at linux.intel.com wrote:
> > 
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > Looks like the Punit is supposed to support the 400MHz cdclk directly on
> > > chv, so we don't need the vlv tricks.
> > > 
> > > FIXME: Punit doesn't seem ready for this yet on current hw
> > > 
> > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h      |  4 +++
> > >  drivers/gpu/drm/i915/intel_display.c | 50 ++++++++++++++++++++++++++++++++++--
> > >  2 files changed, 52 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > > index f156591..e296312 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -491,6 +491,10 @@
> > >  #define BUNIT_REG_BISOC				0x11
> > >  
> > >  #define PUNIT_REG_DSPFREQ			0x36
> > > +#define   DSPFREQSTAT_SHIFT_CHV			24
> > > +#define   DSPFREQSTAT_MASK_CHV			(0x1f << DSPFREQSTAT_SHIFT_CHV)
> > > +#define   DSPFREQGUAR_SHIFT_CHV			8
> > > +#define   DSPFREQGUAR_MASK_CHV			(0x1f << DSPFREQGUAR_SHIFT_CHV)
> > >  #define   DSPFREQSTAT_SHIFT			30
> > >  #define   DSPFREQSTAT_MASK			(0x3 << DSPFREQSTAT_SHIFT)
> > >  #define   DSPFREQGUAR_SHIFT			14
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > index 99c10d1..9af1d13 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -4529,6 +4529,47 @@ static void valleyview_set_cdclk(struct drm_device *dev, int cdclk)
> > >  	vlv_update_cdclk(dev);
> > >  }
> > >  
> > > +static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
> > > +{
> > > +	struct drm_i915_private *dev_priv = dev->dev_private;
> > > +	u32 val, cmd;
> > > +
> > > +	WARN_ON(dev_priv->display.get_display_clock_speed(dev) != dev_priv->vlv_cdclk_freq);
> > > +
> > > +	switch (cdclk) {
> > > +	case 400000:
> > > +		cmd = 3;
> > > +		break;
> > > +	case 333333:
> > > +	case 320000:
> > > +		cmd = 2;
> > > +		break;
> > > +	case 266667:
> > > +		cmd = 1;
> > > +		break;
> > > +	case 200000:
> > > +		cmd = 0;
> > > +		break;
> > > +	default:
> > > +		WARN_ON(1);
> > > +		return;
> > > +	}
> > > +
> > > +	mutex_lock(&dev_priv->rps.hw_lock);
> > > +	val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> > > +	val &= ~DSPFREQGUAR_MASK_CHV;
> > > +	val |= (cmd << DSPFREQGUAR_SHIFT_CHV);
> > > +	vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
> > > +	if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ) &
> > > +		      DSPFREQSTAT_MASK_CHV) == (cmd << DSPFREQSTAT_SHIFT_CHV),
> > > +		     50)) {
> > > +		DRM_ERROR("timed out waiting for CDclk change\n");
> > > +	}
> > > +	mutex_unlock(&dev_priv->rps.hw_lock);
> > > +
> > > +	vlv_update_cdclk(dev);
> > > +}
> > > +
> > >  static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
> > >  				 int max_pixclk)
> > >  {
> > > @@ -4597,8 +4638,13 @@ static void valleyview_modeset_global_resources(struct drm_device *dev)
> > >  	int max_pixclk = intel_mode_max_pixclk(dev_priv);
> > >  	int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
> > >  
> > > -	if (req_cdclk != dev_priv->vlv_cdclk_freq)
> > > -		valleyview_set_cdclk(dev, req_cdclk);
> > > +	if (req_cdclk != dev_priv->vlv_cdclk_freq) {
> > > +		if (IS_CHERRYVIEW(dev))
> > > +			cherryview_set_cdclk(dev, req_cdclk);
> > > +		else
> > > +			valleyview_set_cdclk(dev, req_cdclk);
> > > +	}
> > > +
> > >  	modeset_update_crtc_power_domains(dev);
> > >  }
> > >  
> > 
> > Which doc has these Punit commands?  I'm assuming you have them
> > correct, but a ref would be good if we don't already have one.
> 
> Yeah I think I'll hold off on this until the doc has diffused better. For
> byt this was too much fun with jumping back&forth a few times ...

Well, the next patch disables this until we can test anyway, so it
should be fine to add and fixup/add the doc link later.

-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list