intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 2/2] drm/i915/mst: Continue state updates even if AUX writes fail.
Date: Thu, 19 Jul 2018 16:37:48 -0700	[thread overview]
Message-ID: <20180719233748.GB2184@intel.com> (raw)
In-Reply-To: <1532026300.28553.81.camel@intel.com>

On Thu, Jul 19, 2018 at 11:51:40AM -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-07-18 at 22:43 -0700, Rodrigo Vivi wrote:
> > On Wed, Jul 18, 2018 at 10:19:43AM -0700, Dhinakaran Pandiyan wrote:
> > > 
> > > We are too late in the enabling sequence to back out cleanly, not
> > > updating
> > > state tracking variables, like intel_dp->active_mst_links in this
> > > instance, results in incorrect behaviour further along.
> > I agree with you, although I'm not fully convinced that we need to
> > call the
> > update payload if vcpi allocation failed...
> 
> But there is more payload update code in intel_mst_enable_dp(),

oh... the part2 indeed...

> that
> would get executed regardless of this diff below. We'll have to rewrite
> pre_enable, enable, disable and post_disable if the idea is avoid sink
> transactions after the first failure. It does make sense to do all of
> that as it avoids printing error messages in dmesg when we very well
> know the branch device is disconnected, but this should be a separate
> change.

fair enough...

> My idea was to bring pre_enable/enable in line with
> disable/post_disable.

makes sense... I just saw it is similar on payload update failure.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

> 
> 
> > 
> > so imho this entire function should be reworked to be like this:
> > 
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -217,7 +217,6 @@ static void intel_mst_pre_enable_dp(struct
> > intel_encoder *encoder,
> >         enum port port = intel_dig_port->base.port;
> >         struct intel_connector *connector =
> >                 to_intel_connector(conn_state->connector);
> > -       int ret;
> >         uint32_t temp;
> >  
> >         /* MST encoders are bound to a crtc, not to a connector,
> > @@ -233,25 +232,15 @@ static void intel_mst_pre_enable_dp(struct
> > intel_encoder *encoder,
> >  
> >         drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector-
> > >port, true);
> >  
> > -       if (intel_dp->active_mst_links == 0)
> > +       if (intel_dp->active_mst_links++ == 0)
> >                 intel_dig_port->base.pre_enable(&intel_dig_port-
> > >base,
> >                                                 pipe_config, NULL);
> >  
> > -       ret = drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr,
> > -                                      connector->port,
> > -                                      pipe_config->pbn,
> > -                                      pipe_config->dp_m_n.tu);
> > -       if (ret == false) {
> > +       if (drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr, connector-
> > >port,
> > +                                    pipe_config->pbn, pipe_config-
> > >dp_m_n.tu))
> > +               drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> > +       else
> >                 DRM_ERROR("failed to allocate vcpi\n");
> > -               return;
> > -       }
> > -
> > -
> > -       intel_dp->active_mst_links++;
> > -       temp = I915_READ(DP_TP_STATUS(port));
> > -       I915_WRITE(DP_TP_STATUS(port), temp);
> > -
> > -       ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> > 
> > 
> > probably with
> > -       temp = I915_READ(DP_TP_STATUS(port));
> > -       I915_WRITE(DP_TP_STATUS(port), temp);
> > 
> > in a separated patch. No idea why we read this staus reg and write
> > back.
> It is clearing the ACT status bit by writing a 1. Bspec has this
> under DP_TP_STATUS:24
> 
> -DK
> 
> > I didn't see on spec any indication that this cleans it or that we
> > need that
> > for cleaning or anything else.
> > 
> > > 
> > > 
> > > v2: Fixed int v/s bool comparison
> > > 
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp_mst.c | 5 +----
> > >  1 file changed, 1 insertion(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index 7e3e01607643..110e7ff22ef7 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -241,11 +241,8 @@ static void intel_mst_pre_enable_dp(struct
> > > intel_encoder *encoder,
> > >  				       connector->port,
> > >  				       pipe_config->pbn,
> > >  				       pipe_config->dp_m_n.tu);
> > > -	if (ret == false) {
> > > +	if (!ret)
> > >  		DRM_ERROR("failed to allocate vcpi\n");
> > > -		return;
> > > -	}
> > > -
> > >  
> > >  	intel_dp->active_mst_links++;
> > >  	temp = I915_READ(DP_TP_STATUS(port));
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-07-19 23:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-18 17:19 [PATCH v2 1/2] drm/i915/mst: Do not retrain new links Dhinakaran Pandiyan
2018-07-18 17:19 ` [PATCH v2 2/2] drm/i915/mst: Continue state updates even if AUX writes fail Dhinakaran Pandiyan
2018-07-18 18:04   ` Nathan Ciobanu
2018-07-19  5:43   ` Rodrigo Vivi
2018-07-19 18:51     ` Dhinakaran Pandiyan
2018-07-19 23:37       ` Rodrigo Vivi [this message]
2018-07-25 18:39         ` Dhinakaran Pandiyan
2018-07-26  8:09           ` Dhinakaran Pandiyan
2018-07-18 17:45 ` [PATCH v2 1/2] drm/i915/mst: Do not retrain new links Manasi Navare
2018-07-18 20:34   ` Dhinakaran Pandiyan
2018-07-18 20:31     ` Manasi Navare
2018-07-18 21:30       ` Dhinakaran Pandiyan
2018-07-18 21:22         ` Rodrigo Vivi
2018-07-18 18:03 ` ✓ Fi.CI.BAT: success for series starting with [v2,1/2] " Patchwork
2018-07-18 18:53 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-07-18 20:45 ` [PATCH v2 1/2] " Nathan Ciobanu
2018-07-25 19:05 ` ✓ Fi.CI.BAT: success for series starting with [v2,1/2] " Patchwork
2018-07-25 20:28 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-07-26  4:00   ` Dhinakaran Pandiyan
2018-07-26  4:22 ` ✗ Fi.CI.BAT: " 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=20180719233748.GB2184@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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;
as well as URLs for NNTP newsgroup(s).