From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 2/4] drm/i915: Don't check for wm changes until we've compute the wms fully
Date: Thu, 5 Mar 2020 15:55:24 +0200 [thread overview]
Message-ID: <20200305135524.GM13686@intel.com> (raw)
In-Reply-To: <e8400308a790eb317b345a9164916c7f044a5cd9.camel@intel.com>
On Wed, Mar 04, 2020 at 11:25:42PM +0000, Souza, Jose wrote:
> On Wed, 2020-03-04 at 13:46 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 04, 2020 at 12:21:01AM +0000, Souza, Jose wrote:
> > > On Fri, 2020-02-28 at 22:35 +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > >
> > > > Currently we're comparing the watermarks between the old and new
> > > > states
> > > > before we've fully computed the new watermarks. In particular
> > > > skl_build_pipe_wm() will not account for the amount of ddb space
> > > > we'll
> > > > have. That information is only available during skl_compute_ddb()
> > > > which will proceed to zero out any watermark level exceeding the
> > > > ddb allocation. If we're short on ddb space this will end up
> > > > adding the plane to the state due erronously determining that the
> > > > watermarks have changed. Fix the problem by deferring
> > > > skl_wm_add_affected_planes() until we have the final watermarks
> > > > computed.
> > > >
> > > > Noticed this when trying enable transition watermarks on glk.
> > > > We now computed the trans_wm as 28, but we only had 14 blocks
> > > > of ddb, and thus skl_compute_ddb() ended up disabling the cursor
> > > > trans_wm every time. Thus we ended up adding the cursor to every
> > > > commit that didn't actually affect the cursor at all.
> > > >
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/intel_pm.c | 16 ++++++++++++----
> > > > 1 file changed, 12 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 39299811b650..a3d76e69caae 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -5762,16 +5762,24 @@ skl_compute_wm(struct intel_atomic_state
> > > > *state)
> > > > ret = skl_build_pipe_wm(new_crtc_state);
> > > > if (ret)
> > > > return ret;
> > > > -
> > > > - ret = skl_wm_add_affected_planes(state, crtc);
> > > > - if (ret)
> > > > - return ret;
> > > > }
> > > >
> > > > ret = skl_compute_ddb(state);
> > > > if (ret)
> > > > return ret;
> > > >
> > > > + /*
> > > > + * skl_compute_ddb() will have adjusted the final watermarks
> > > > + * based on how much ddb is available. Now we can actually
> > > > + * check if the final watermarks changed.
> > > > + */
> > > > + for_each_oldnew_intel_crtc_in_state(state, crtc,
> > > > old_crtc_state,
> > > > + new_crtc_state, i) {
> > > > + ret = skl_wm_add_affected_planes(state, crtc);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > >
> > > skl_compute_ddb() is already calling skl_wm_add_affected_planes()
> > > after
> > > do the ddb allocation for each pipe, so we could remove this chunk,
> >
> > skl_compute_ddb() calls skl_*ddb*_add_affected_planes(), which is a
> > different thing..
>
> Thanks
No, thank you for the review. Series pushed to dinq.
>
> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
>
> >
> > > with that:
> > >
> > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > >
> > > > +
> > > > skl_print_wm_changes(state);
> > > >
> > > > return 0;
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-03-05 13:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 20:35 [Intel-gfx] [PATCH 1/4] drm/i915: Don't check uv_wm in skl_plane_wm_equals() Ville Syrjala
2020-02-28 20:35 ` [Intel-gfx] [PATCH 2/4] drm/i915: Don't check for wm changes until we've compute the wms fully Ville Syrjala
2020-03-04 0:21 ` Souza, Jose
2020-03-04 11:46 ` Ville Syrjälä
2020-03-04 23:25 ` Souza, Jose
2020-03-05 13:55 ` Ville Syrjälä [this message]
2020-02-28 20:35 ` [Intel-gfx] [PATCH 3/4] drm/i915: Enable transition watermarks for glk Ville Syrjala
2020-02-28 20:35 ` [Intel-gfx] [PATCH 4/4] drm/i915: Implement display w/a 1140 for glk/cnl Ville Syrjala
2020-02-28 21:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Don't check uv_wm in skl_plane_wm_equals() Patchwork
2020-03-01 18:23 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-03-04 0:14 ` [Intel-gfx] [PATCH 1/4] " Souza, Jose
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=20200305135524.GM13686@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jose.souza@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.