[Intel-gfx] [PATCH 1/2] drm/i915: Disable DDR DVFS on CHV
Ville Syrjälä
ville.syrjala at linux.intel.com
Thu Mar 5 09:32:08 PST 2015
On Tue, Mar 03, 2015 at 01:27:17PM +0530, Arun R Murthy wrote:
>
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >
> > DDR DVFS introduces massive memory latencies which can't be handled by the PND deadline stuff. Instead the watermarks will need to be programmed to compensate for the latency and the deadlines will need to be programmed to tight fixed values. That means DDR DVFS can only be enabled if the display FIFOs are large enough, and that pretty much means we have to manually repartition them to suit the needs of the moment.
> >
> > That's a lot of change, so in the meantime let's just disable DDR DVFS to get the display(s) to be stable.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 5 +++++ drivers/gpu/drm/i915/intel_pm.c | 34 ++++++++++++++++++++++++++++++++++
> > 2 files changed, 39 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 581813e..f67be5d 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -630,6 +630,11 @@ enum skl_disp_power_wells {
> > #define FB_GFX_FMIN_AT_VMIN_FUSE 0x137
> > #define FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT 8
> >
> > +#define PUNIT_REG_DDR_SETUP2 0x139
> > +#define FORCE_DDR_FREQ_REQ_ACK (1 << 8)
> > +#define FORCE_DDR_LOW_FREQ (1 << 1)
> > +#define FORCE_DDR_HIGH_FREQ (1 << 0)
> > +
> > #define PUNIT_GPU_STATUS_REG 0xdb
> > #define PUNIT_GPU_STATUS_MAX_FREQ_SHIFT 16
> > #define PUNIT_GPU_STATUS_MAX_FREQ_MASK 0xff
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index f603dac..f43d77c 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -235,6 +235,28 @@ static const struct cxsr_latency *intel_get_cxsr_latency(int is_desktop,
> > return NULL;
> > }
> >
> > +static void chv_set_memory_dvfs(struct drm_i915_private *dev_priv, bool
> > +enable) {
> > + u32 val;
> > +
> > + mutex_lock(&dev_priv->rps.hw_lock);
> > +
> > + val = vlv_punit_read(dev_priv, PUNIT_REG_DDR_SETUP2);
> > + if (enable)
> > + val &= ~FORCE_DDR_HIGH_FREQ;
> > + else
> > + val |= FORCE_DDR_HIGH_FREQ;
> > + val &= ~FORCE_DDR_LOW_FREQ;
> > + val |= FORCE_DDR_FREQ_REQ_ACK;
> > + vlv_punit_write(dev_priv, PUNIT_REG_DDR_SETUP2, val);
> > +
> > + if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DDR_SETUP2) &
> > + FORCE_DDR_FREQ_REQ_ACK) == 0, 3))
> > + DRM_ERROR("timed out waiting for Punit DDR DVFS request\n");
> > +
> > + mutex_unlock(&dev_priv->rps.hw_lock);
> > +}
> > +
> > static void chv_set_memory_pm5(struct drm_i915_private *dev_priv, bool enable) {
> > u32 val;
> > @@ -281,6 +303,7 @@ void intel_set_memory_cxsr(struct drm_i915_private *dev_priv, bool enable)
> > enable ? "enabled" : "disabled"); }
> >
> > +
> > /*
> > * Latency for FIFO fetches is dependent on several factors:
> > * - memory configuration (speed, channels)
> > @@ -1000,6 +1023,17 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
> > wm.pipe[pipe].primary, wm.pipe[pipe].cursor,
> > wm.sr.plane, wm.sr.cursor);
> >
> > + /*
> > + * FIXME DDR DVFS introduces massive memory latencies which
> > + * are not known to system agent so any deadline specified
> > + * by the display may not be respected. To support DDR DVFS
> > + * the watermark code needs to be rewritten to essentially
> > + * bypass deadline mechanism and rely solely on the
> > + * watermarks. For now disable DDR DVFS.
> > + */
> > + if (IS_CHERRYVIEW(dev_priv))
> > + chv_set_memory_dvfs(dev_priv, false);
>
> DDR DVFS should be enabled only when we are in single plane,|
> single pipe mode, i.e ideally in maxfifo mode.
As stated it's going to take a bit of work to get the code into proper
shape especially as we want to change the FIFO partitioning to maximize
the chances of getting DVFS working. Relying on maxfifo alone won't work
since we can't force the hardware to use it, it'll make that decision on
its own.
--
Ville Syrjälä
Intel OTC
More information about the Intel-gfx
mailing list