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@xxxxxxxxxxxxxxx wrote: > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > 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@xxxxxxxxxxxxxxx> > > > --- > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
