[Intel-gfx] [PATCH 12/12] drm/i915: Disable DDR DVFS on CHV

[Daniel Vetter]

On Mon, Mar 09, 2015 at 05:00:09PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 10:14:05AM +0530, Arun R Murthy wrote:
> > 
> > On Friday 06 March 2015 12:49 AM, ville.syrjala at linux.intel.com 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>
> > > ---
> > 
> > Since this patch disabled DDR DVFS in the driver, can this be done
> > once. Here I assume that DDR DVFS gets disabled on each update
> > watermark call.
> 
> Yeah it did occur to me that we could get away with disabling just once,
> but once we get the DDR DVFS enabled we're going to be changing it more,
> potentially at every watermark update (although having to do it every
> time is rather unlikely).
> 
> In any case, you may have noticed that I skip the entire WM programming
> if the calculated watermarks didn't change from the old values, so we
> won't be frobbing the Punit unless something in the WM values has actually
> changed. So I figured that's good enough for now.
> 
> My plan is to optimize away redundant Punit communication (for both PM5
> and DDR DVFS) eventually, but that is part of the task to get DDR DVFS
> enabled in the first place.

Yeah I think this plan makes sense long-term. Generally I'd like to move
the wm code towards always recomputing everything and optimizing out no-op
updates afterwards. Atm we have have a split between the code that decides
when to recompute wm and the code that recomputes them, and that tends to
be a bit fragile. Especially since we add a lot more complexity to the wm
code with new features like Y-tiling or atomic updates.
-Daneil
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch