[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