public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/i915: Fix wm latency==0 disable on skl+
Date: Tue, 5 Feb 2019 15:35:19 +0200	[thread overview]
Message-ID: <20190205133519.GO20097@intel.com> (raw)
In-Reply-To: <20190204230750.GK25534@mdroper-desk.amr.corp.intel.com>

On Mon, Feb 04, 2019 at 03:07:50PM -0800, Matt Roper wrote:
> On Mon, Feb 04, 2019 at 08:45:20PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > When adding the early latency==0 check back I neglected to
> > realize that we no longer have a way to return a failure
> > from the wm computation like we had in the past (since we
> > now calculate wms before ddb allocations). Also plane_en
> > being false doesn't actually indicate that the level is
> > invalid as it wil also happen when the plane is not
> > enabled.
> > 
> > skl_allocate_pipe_ddb() starts scanning from the maximum
> > watermark level and it stops as soon as it finds a level
> > that is deemed viable. The assumption being that if level
> > n+1 is valid then level n is valid as well. Thus if we
> > now disable any watermark level by zeroing its latency
> > the code will think that level to be actually valid
> > and won't confirm whether the actually enabled lower
> > watermark level(s) actually fit into the allotted ddb
> > space. This results in hilarious watermark values that
> > exceed the ddb allocation of the plane.
> > 
> > The way we must now indicate a failure is to assign an
> > unreasoanbly big value to min_ddb_alloc which will then
> > make skl_allocate_pipe_ddb() reject the entire level.
> > 
> > Cc: Matt Roper <matthew.d.roper@intel.com>
> > Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Similarly, isn't the
> 
>         if (res_lines > 31)
>                 return;
> 
> farther down the function going to also cause a problem?  If we fail the
> line requirement then result->min_ddb_alloc and such never get set for
> this plane, which screws up the block sum at block allocation time.

Hmm. Yes, that does seem to be the case. I'll respin.

> 
> 
> Matt
> 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index ed9786241307..d6186c90bc10 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4694,8 +4694,11 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *cstate,
> >  	uint_fixed_16_16_t selected_result;
> >  	u32 res_blocks, res_lines, min_ddb_alloc = 0;
> >  
> > -	if (latency == 0)
> > +	if (latency == 0) {
> > +		/* reject it */
> > +		result->min_ddb_alloc = U16_MAX;
> >  		return;
> > +	}
> >  
> >  	/* Display WA #1141: kbl,cfl */
> >  	if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
> > -- 
> > 2.19.2
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795

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

  reply	other threads:[~2019-02-05 13:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-04 18:45 [PATCH 1/4] drm/i915: Fix wm latency==0 disable on skl+ Ville Syrjala
2019-02-04 18:45 ` [PATCH 2/4] drm/i915: Extract skl_set_pipe_chicken() Ville Syrjala
2019-02-04 20:21   ` [PATCH v2 2/4] drm/i915: Extract icl_set_pipe_chicken() Ville Syrjala
2019-02-04 23:28     ` Matt Roper
2019-02-04 18:45 ` [PATCH 3/4] drm/i915: Setup PIPE_CHICKEN for fastsets too Ville Syrjala
2019-02-04 20:22   ` [PATCH v2 " Ville Syrjala
2019-02-04 23:28     ` Matt Roper
2019-02-05 11:21     ` Maarten Lankhorst
2019-02-05 13:39       ` Ville Syrjälä
2019-02-05 14:49         ` Maarten Lankhorst
2019-02-05 18:30           ` Ville Syrjälä
2019-02-04 18:45 ` [PATCH 4/4] drm/i915: W/A for underruns with WM1+ disabled on icl Ville Syrjala
2019-02-04 20:22   ` [PATCH v2 " Ville Syrjala
2019-02-04 23:29     ` Matt Roper
2019-02-04 19:22 ` ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Fix wm latency==0 disable on skl+ Patchwork
2019-02-04 21:08 ` ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Fix wm latency==0 disable on skl+ (rev4) Patchwork
2019-02-04 21:58 ` ✓ Fi.CI.IGT: " Patchwork
2019-02-04 23:07 ` [PATCH 1/4] drm/i915: Fix wm latency==0 disable on skl+ Matt Roper
2019-02-05 13:35   ` Ville Syrjälä [this message]
2019-02-05 13:42 ` [PATCH v2 " Ville Syrjala
2019-02-05 15:32   ` Matt Roper
2019-02-05 15:50 ` [PATCH v3 " Ville Syrjala
2019-02-05 16:46 ` ✓ Fi.CI.BAT: success for series starting with [v3,1/4] drm/i915: Fix wm latency==0 disable on skl+ (rev6) Patchwork
2019-02-05 19:47 ` ✓ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190205133519.GO20097@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox