From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@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] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
Date: Fri, 18 Mar 2022 16:22:52 +0200 [thread overview]
Message-ID: <20220318142252.GA8522@intel.com> (raw)
In-Reply-To: <f60950ea65708dc7f093f5939efb164225b186c6.camel@intel.com>
On Fri, Mar 18, 2022 at 02:27:53PM +0200, Souza, Jose wrote:
> On Fri, 2022-03-18 at 05:22 -0700, José Roberto de Souza wrote:
> > On Fri, 2022-03-18 at 10:52 +0200, Stanislav Lisovskiy wrote:
> > > We are currently getting FIFO underruns, in particular
> > > when PSR2 is enabled. There seem to be no existing workaround
> > > or patches, which can fix that issue(were expecting some recent
> > > selective fetch update and DBuf bw/SAGV fixes to help,
> > > which unfortunately didn't).
> > > Current idea is that it looks like for some reason the
> > > DBuf prefill time isn't enough once we exit PSR2, despite its
> > > theoretically correct.
> > > So bump it up a bit by 15%(minimum experimental amount required
> > > to get it working), if PSR2 is enabled.
> > > For PSR1 there is no need in this hack, so we limit it only
> > > to PSR2 and Alderlake.
> >
> > It this workaround meant to be permanent? If yes we should file a HSD and get hardware folks feedback.
> >
> > >
> > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index 8888fda8b701..095b79950788 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> > > dev_priv->max_cdclk_freq));
> > > }
> > >
> >
> > Please add some comment in the code about this workaround.
> >
> >
> > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > + struct intel_encoder *encoder;
> > > +
> > > + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > +
> > > + if (intel_dp->psr.psr2_enabled) {
> >
> > You should check the has_psr2 in the crtc_state, PSR2 could be disabled when this state is committed.
>
> Ah and if a remember correctly those underruns only happens in a scenario with 4 pipes enabled? or it also happens with 2 and 3 pipes?
> Anyways would be better to narrow down the cases where the workaround is applied.
> So for at least in a case with a single pipe enabled we can have the lowest cdclk as possible.
I was thinking the same initially, but this underrun is observed in lesser pipe cases, when PSR2
is enabled.
Stan
>
> >
> > > + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
> >
> > This is not increasing by 15%.
> >
> > min_cdclk = 500
> > 500 * 100 = 50000
> > 50000 / 85 = 588.235294118
> >
> > While 15% of 500 is 75.
> >
> > Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
> >
> > > + break;
> > > + }
> > > + }
> > > + }
> > > +
> > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > drm_dbg_kms(&dev_priv->drm,
> > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> >
>
next prev parent reply other threads:[~2022-03-18 14:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-18 8:52 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
2022-03-18 11:18 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-03-18 12:21 ` [Intel-gfx] [PATCH] " Souza, Jose
2022-03-18 12:27 ` Souza, Jose
2022-03-18 14:22 ` Lisovskiy, Stanislav [this message]
2022-03-18 14:40 ` Souza, Jose
2022-03-18 14:19 ` Lisovskiy, Stanislav
2022-03-18 14:38 ` Souza, Jose
2022-03-18 14:45 ` Lisovskiy, Stanislav
2022-03-18 12:30 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2022-03-21 10:49 [Intel-gfx] [PATCH] " Stanislav Lisovskiy
2022-03-21 16:58 ` Souza, Jose
2022-03-22 7:48 ` Lisovskiy, Stanislav
2022-03-22 13:16 ` Souza, Jose
2022-03-22 13:30 ` Lisovskiy, Stanislav
2022-03-22 13:34 ` Souza, Jose
2022-03-21 17:01 ` Souza, Jose
2022-03-22 7:49 ` Lisovskiy, Stanislav
2022-03-22 13:36 ` Souza, Jose
2022-03-29 13:10 ` Lisovskiy, Stanislav
2022-03-29 13:24 ` Souza, Jose
2022-03-29 13:53 ` Lisovskiy, Stanislav
2022-01-24 9:06 [Intel-gfx] [PATCH 4/4] drm/i915: Don't allocate extra ddb during async flip for DG2 Stanislav Lisovskiy
2022-03-18 8:48 ` [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
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=20220318142252.GA8522@intel.com \
--to=stanislav.lisovskiy@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox