From: Imre Deak <imre.deak@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl+: Fix DP MST ACT status handling
Date: Thu, 11 Jun 2020 19:31:57 +0300 [thread overview]
Message-ID: <20200611163157.GJ17512@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <20200611153811.GZ6112@intel.com>
On Thu, Jun 11, 2020 at 06:38:11PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 10, 2020 at 09:31:31PM +0300, Imre Deak wrote:
> > On TGL+ the master transcoder's DP_TP_STATUS register should be used for
> > the MST ACT status handling, so make sure we do that even in case of
> > mulitple streams.
> >
> > This fixes an ACT timeout problem during disabling when using multiple
> > streams. Not sure why this was not a problem during enabling (even the
> > slave's DP_TP_STATUS signaled ACT correctly), but following the spec
> > works in that case too, so let's do that.
> >
> > There is one more place using DP_TP_STATUS, FEC enabling, but I haven't
> > found in BSpec which register to use in that case, so I leave the
> > clarification of that for later.
> >
> > BSpec: 49190
> >
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 47 +++++++++++++++++----
> > 1 file changed, 39 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index d18b406f2a7d..1c3654a117a9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -316,6 +316,40 @@ intel_dp_mst_atomic_check(struct drm_connector *connector,
> > return ret;
> > }
> >
> > +static i915_reg_t
> > +master_dp_tp_status_reg(const struct intel_crtc_state *crtc_state,
> > + const struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> > +
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + return TGL_DP_TP_STATUS(crtc_state->mst_master_transcoder);
>
> Was going to say this needs a mst check, but then I noticed you're only
> changing the mst paths. So this looks like a partial take on
> https://patchwork.freedesktop.org/patch/364549/?series=76993&rev=2
> Granted, my patch would require the crtc_state plumbing everywhere
> so not really bug fix material.
Yes, this would fix the problem.
> The main question I have is why are regs.dp_tp* not being populated
> correctly? Pretty sure they were supposed to be.
Yea, the real problem is in intel_ddi_get_config() corrupting those
regs. So an alternative would be to fix that instead..
> Also there are a bunch of places where we poke DP_TP_CTL in
> intel_ddi.c. Why aren't those a problem?
Those happened to be correct for the actual port enabling/disabling.
Only the non-primary streams were screwed up after a get_config() call.
I was also a bit confused about which places need the master transcoder
version of the dp_tp regs, since the spec requires this explicitly only
for the ACT sent status check. But I guess we need to use the master
version in all cases.
>
> > +
> > + return intel_dp->regs.dp_tp_status;
> > +}
> > +
> > +static void clear_act_sent(const struct intel_crtc_state *crtc_state,
> > + const struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> > + i915_reg_t dp_tp_status_reg =
> > + master_dp_tp_status_reg(crtc_state, intel_dp);
> > +
> > + intel_de_write(i915, dp_tp_status_reg,
> > + intel_de_read(i915, dp_tp_status_reg));
> > +}
> > +
> > +static bool wait_for_act_sent(const struct intel_crtc_state *crtc_state,
> > + const struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> > + i915_reg_t dp_tp_status_reg =
> > + master_dp_tp_status_reg(crtc_state, intel_dp);
> > +
> > + return intel_de_wait_for_set(i915, dp_tp_status_reg,
> > + DP_TP_STATUS_ACT_SENT, 1) == 0;
> > +}
> > +
> > static void intel_mst_disable_dp(struct intel_atomic_state *state,
> > struct intel_encoder *encoder,
> > const struct intel_crtc_state *old_crtc_state,
> > @@ -376,8 +410,7 @@ static void intel_mst_post_disable_dp(struct intel_atomic_state *state,
> > TRANS_DDI_FUNC_CTL(old_crtc_state->cpu_transcoder),
> > val);
> >
> > - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> > - DP_TP_STATUS_ACT_SENT, 1))
> > + if (!wait_for_act_sent(old_crtc_state, intel_dp))
> > drm_err(&dev_priv->drm,
> > "Timed out waiting for ACT sent when disabling\n");
> > drm_dp_check_act_status(&intel_dp->mst_mgr);
> > @@ -443,7 +476,6 @@ static void intel_mst_pre_enable_dp(struct intel_atomic_state *state,
> > struct intel_connector *connector =
> > to_intel_connector(conn_state->connector);
> > int ret;
> > - u32 temp;
> > bool first_mst_stream;
> >
> > /* MST encoders are bound to a crtc, not to a connector,
> > @@ -476,8 +508,8 @@ static void intel_mst_pre_enable_dp(struct intel_atomic_state *state,
> > drm_err(&dev_priv->drm, "failed to allocate vcpi\n");
> >
> > intel_dp->active_mst_links++;
> > - temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_status);
> > - intel_de_write(dev_priv, intel_dp->regs.dp_tp_status, temp);
> > +
> > + clear_act_sent(pipe_config, intel_dp);
> >
> > ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> >
> > @@ -513,9 +545,8 @@ static void intel_mst_enable_dp(struct intel_atomic_state *state,
> > drm_dbg_kms(&dev_priv->drm, "active links %d\n",
> > intel_dp->active_mst_links);
> >
> > - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> > - DP_TP_STATUS_ACT_SENT, 1))
> > - drm_err(&dev_priv->drm, "Timed out waiting for ACT sent\n");
> > + if (!wait_for_act_sent(pipe_config, intel_dp))
> > + drm_err(&dev_priv->drm, "Timed out waiting for ACT sent when enabling\n");
> >
> > drm_dp_check_act_status(&intel_dp->mst_mgr);
> >
> > --
> > 2.23.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> 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-06-11 16:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 18:31 [Intel-gfx] [PATCH 1/2] drm/i915/tgl+: Fix DP MST ACT status handling Imre Deak
2020-06-10 18:31 ` [Intel-gfx] [PATCH 2/2] drm/i915/dp_mst: Clear ACT sent flag before waiting for it Imre Deak
2020-06-10 19:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/tgl+: Fix DP MST ACT status handling Patchwork
2020-06-11 11:00 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-06-11 15:38 ` [Intel-gfx] [PATCH 1/2] " Ville Syrjälä
2020-06-11 16:31 ` Imre Deak [this message]
2020-06-11 15:39 ` Ville Syrjälä
2020-06-11 16:37 ` Imre Deak
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=20200611163157.GJ17512@ideak-desk.fi.intel.com \
--to=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.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