Re: [PATCH 10/12] drm/i915: Support maxfifo with two planes on CHV

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 04, 2015 at 07:34:50PM +0530, Purushothaman, Vijay A wrote:
> On 2/10/2015 6:58 PM, ville.syrjala@xxxxxxxxxxxxxxx wrote:
> > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> >
> > CHV supposedly does maxfifo mode even with two enabled
> > (primary/sprite) planes. Lets try to support that by halving the FIFO
> > size for the calculations and picking the smallest calculcated
> > watermark from the enabled planes.
> Where is this mentioned in the spec? My understanding is MaxFIFO can be 
> enabled when only one plane is active (either ARGB or YUV). I do 
> remember some TR task that was talking about enabling MaxFIFO for two 
> planes. But i didn't get any confirmation that this can be enabled.

It was mentioned in the display cluster HAS (also maybe some version of 
the PUNIT HAS), but I wasn't sure it's actually there. IIRC the answer
I got in one DDR DVFS meeting was that yes it does exit. But I've not
actually confirmed whether it seems to work on real hardware. The
annoying thing is that there doesn't seem to be any kind of status bit
to tell me if it has entered maxfifo or not, so it would need to be
deduced from some other facts.

Anyway, we can just skip this patch as it's still somewhat unclear if
this can be used or not.

> We 
> have not enabled this for CHT in any other OS (Windows / Android).
> 
> Other features like PM2 / PM5 / DVFS can be enabled for multi plane 
> scenarios

As far as I know we can't even control PM2. So the only thing we can
influence is whether it will enter PM2 or PM5 when things are
sufficiently idle. So we must always tolerate the PM2 latency, and
if we can tolerate the extra PM5 latency we can then choose PM5 over
PM2.

Previously I thought the something would check if the display is in
maxfifo or not before entering PM2/PM5, but now I can't see anything to
back that up. So I suppose we must always verify that even the
non-maxfifo FIFO sizes can tolerate the latency, whether or not we have
enable maxfifo or not (since we can't force maxfifo entry, and instead
the hardware just decides that by itself).

> 
> Thanks,
> Vijay
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > ---
> >   drivers/gpu/drm/i915/intel_pm.c | 22 +++++++++++++++++-----
> >   1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index d29c02c..e6cbc24 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -907,6 +907,8 @@ static bool vlv_compute_sr_wm(struct drm_device *dev,
> >   	int num_planes = 0;
> >   	int fifo_size = 0;
> >   	struct intel_plane *plane;
> > +	/* CHV supports max fifo with two planes (1:1 split) */
> > +	int max_planes = IS_CHERRYVIEW(dev) ? 2 : 1;
> >   
> >   	wm->sr.cursor = wm->sr.plane = 0;
> >   
> > @@ -920,23 +922,33 @@ static bool vlv_compute_sr_wm(struct drm_device *dev,
> >   		fifo_size = INTEL_INFO(dev_priv)->num_pipes * 512 - 1;
> >   	}
> >   
> > -	if (fifo_size == 0 || num_planes > 1)
> > +	if (fifo_size == 0 || num_planes > max_planes)
> >   		return false;
> >   
> > +	if (num_planes)
> > +		fifo_size /= num_planes;
> > +
> >   	wm->sr.cursor = vlv_compute_wm(to_intel_crtc(crtc),
> >   				       to_intel_plane(crtc->cursor), 0x3f);
> >   
> >   	list_for_each_entry(plane, &dev->mode_config.plane_list, base.head) {
> > +		uint16_t sr_wm;
> > +
> >   		if (plane->base.type == DRM_PLANE_TYPE_CURSOR)
> >   			continue;
> >   
> >   		if (plane->pipe != pipe)
> >   			continue;
> >   
> > -		wm->sr.plane = vlv_compute_wm(to_intel_crtc(crtc),
> > -					      plane, fifo_size);
> > -		if (wm->sr.plane != 0)
> > -			break;
> > +		sr_wm = vlv_compute_wm(to_intel_crtc(crtc),
> > +				       plane, fifo_size);
> > +		if (sr_wm == 0)
> > +			continue;
> > +
> > +		if (wm->sr.plane == 0)
> > +			wm->sr.plane = sr_wm;
> > +		else
> > +			wm->sr.plane = min(wm->sr.plane, sr_wm);
> >   	}
> >   
> >   	return true;
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux