intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
To: Rodrigo Vivi <rodrigo.vivi@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 11:51:40 -0700	[thread overview]
Message-ID: <1532026300.28553.81.camel@intel.com> (raw)
In-Reply-To: <20180719054316.GN2146@intel.com>

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(), 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. My idea was to bring pre_enable/enable in line with
disable/post_disable.


> 
> 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 18:26 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 [this message]
2018-07-19 23:37       ` Rodrigo Vivi
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=1532026300.28553.81.camel@intel.com \
    --to=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@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;
as well as URLs for NNTP newsgroup(s).