All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Lyude Paul <lyude@redhat.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Manasi Navare <manasi.d.navare@intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies
Date: Mon, 12 Mar 2018 23:05:55 +0200	[thread overview]
Message-ID: <20180312210555.GS5453@intel.com> (raw)
In-Reply-To: <20180309213232.19855-2-lyude@redhat.com>

On Fri, Mar 09, 2018 at 04:32:28PM -0500, Lyude Paul wrote:
> When a DP MST link needs retraining, sometimes the hub will detect that
> the current link bw config is impossible and will update it's RX caps in
> the DPCD to reflect the new maximum link rate. Currently, we make the
> assumption that the RX caps in the dpcd will never change like this.
> This means if the sink changes it's RX caps after we've already set up
> an MST link and we attempt to add or remove another sink from the
> topology, we could put ourselves into an invalid state where we've tried
> to configure different sinks on the same MST topology with different
> link rates. We could also run into this situation if a sink reports a
> higher link rate after suspend, usually from us having trained it with a
> fallback bw configuration before suspending.
> 
> So: "lock" the bw config by only using the max DP link rate/lane count
> on the first modeset for an MST topology. For every modeset following,
> we instead use the last configured link bw for this topology. We only
> unlock the bw config when we've detected a new MST sink.
> 
> Signed-off-by: Lyude Paul <lyude@redhat.com>
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c     | 11 +++++++++--
>  drivers/gpu/drm/i915/intel_dp_mst.c | 22 +++++++++++++++-------
>  drivers/gpu/drm/i915/intel_drv.h    |  6 ++++++
>  3 files changed, 30 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5abf0c95725a..5645a194de92 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3871,18 +3871,25 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>  static void
>  intel_dp_configure_mst(struct intel_dp *intel_dp)
>  {
> +	bool was_mst;
> +
>  	if (!i915_modparams.enable_dp_mst)
>  		return;
>  
>  	if (!intel_dp->can_mst)
>  		return;
>  
> +	was_mst = intel_dp->is_mst;
>  	intel_dp->is_mst = intel_dp_can_mst(intel_dp);
>  
> -	if (intel_dp->is_mst)
> +	if (intel_dp->is_mst) {
>  		DRM_DEBUG_KMS("Sink is MST capable\n");
> -	else
> +
> +		if (!was_mst)
> +			intel_dp->mst_bw_locked = false;
> +	} else {
>  		DRM_DEBUG_KMS("Sink is not MST capable\n");
> +	}
>  
>  	drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
>  					intel_dp->is_mst);
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> index c3de0918ee13..c0553456b18e 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
>  		to_intel_connector(conn_state->connector);
>  	struct drm_atomic_state *state = pipe_config->base.state;
>  	int bpp;
> -	int lane_count, slots;
> +	int lane_count, link_rate, slots;
>  	const struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
>  	int mst_pbn;
>  	bool reduce_m_n = drm_dp_has_quirk(&intel_dp->desc,
> @@ -56,16 +56,22 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
>  			      bpp);
>  	}
>  	/*
> -	 * for MST we always configure max link bw - the spec doesn't
> -	 * seem to suggest we should do otherwise.
> +	 * for MST we always configure max link bw if we don't know better -
> +	 * the spec doesn't seem to suggest we should do otherwise. But,
> +	 * ensure it always stays consistent with the rest of this hub's
> +	 * state.
>  	 */
> -	lane_count = intel_dp_max_lane_count(intel_dp);
> +	if (intel_dp->mst_bw_locked) {
> +		lane_count = intel_dp->lane_count;
> +		link_rate = intel_dp->link_rate;

This feels like something we should be tracking in the MST state.

> +	} else {
> +		lane_count = intel_dp_max_lane_count(intel_dp);
> +		link_rate = intel_dp_max_link_rate(intel_dp);
> +	}
>  
>  	pipe_config->lane_count = lane_count;
> -
>  	pipe_config->pipe_bpp = bpp;
> -
> -	pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
> +	pipe_config->port_clock = link_rate;
>  
>  	if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, connector->port))
>  		pipe_config->has_audio = true;
> @@ -221,6 +227,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
>  	connector->encoder = encoder;
>  	intel_mst->connector = connector;
>  
> +	intel_dp->mst_bw_locked = true;
> +
>  	DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
>  
>  	drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 3f19dc80997f..fc338529e918 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1107,6 +1107,12 @@ struct intel_dp {
>  	bool can_mst; /* this port supports mst */
>  	bool is_mst;
>  	int active_mst_links;
> +	/* Set when we've already decided on a link bw for mst, to prevent us
> +	 * from setting different link bandwiths if the hub tries to confuse
> +	 * us by changing it later
> +	 */
> +	bool mst_bw_locked;
> +
>  	/* connector directly attached - won't be use for modeset in mst world */
>  	struct intel_connector *attached_connector;
>  
> -- 
> 2.14.3

-- 
Ville Syrjälä
Intel OTC

  parent reply	other threads:[~2018-03-12 21:06 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08 23:24 [PATCH 0/6] Implement proper MST fallback retraining in i915 Lyude Paul
2018-03-08 23:24 ` Lyude Paul
2018-03-08 23:24 ` [PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT Lyude Paul
2018-03-08 23:24   ` Lyude Paul
2018-03-09  6:59   ` Manasi Navare
2018-03-08 23:24 ` [PATCH 2/6] drm/i915: Move DP modeset retry work into intel_dp Lyude Paul
2018-03-08 23:24   ` Lyude Paul
2018-03-08 23:41   ` [PATCH v2 " Lyude Paul
2018-03-08 23:41     ` Lyude Paul
2018-03-09  7:25     ` Manasi Navare
2018-03-09  7:25       ` Manasi Navare
2018-03-08 23:24 ` [PATCH 3/6] drm/i915: Only use one link bw config for MST topologies Lyude Paul
2018-03-08 23:24   ` Lyude Paul
2018-03-08 23:24 ` [PATCH 4/6] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate() Lyude Paul
2018-03-08 23:24   ` Lyude Paul
2018-03-08 23:24 ` [PATCH 5/6] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology() Lyude Paul
2018-03-08 23:24   ` Lyude Paul
2018-03-08 23:24 ` [PATCH 6/6] drm/i915: Implement proper fallback training for MST Lyude Paul
2018-03-08 23:24   ` Lyude Paul
2018-03-09 21:32 ` [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp Lyude Paul
2018-03-09 21:32   ` Lyude Paul
2018-03-09 21:32   ` [PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies Lyude Paul
2018-03-09 21:32     ` Lyude Paul
2018-03-12 20:45     ` Manasi Navare
2018-03-12 20:45       ` Manasi Navare
2018-03-13 23:18       ` Lyude Paul
2018-03-12 21:05     ` Ville Syrjälä [this message]
2018-03-09 21:32   ` [PATCH v3 3/5] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate() Lyude Paul
2018-03-09 21:32     ` Lyude Paul
2018-03-12 21:28     ` Manasi Navare
2018-03-12 21:28       ` Manasi Navare
2018-03-09 21:32   ` [PATCH v3 4/5] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology() Lyude Paul
2018-03-09 21:32   ` [PATCH v3 5/5] drm/i915: Implement proper fallback training for MST Lyude Paul
2018-03-09 21:32     ` Lyude Paul
2018-03-12 21:12     ` Ville Syrjälä
2018-03-12 21:12       ` Ville Syrjälä
2018-03-12 22:05     ` Manasi Navare
2018-03-12 22:05       ` Manasi Navare
2018-03-12 22:16       ` Lyude Paul
2018-03-12 22:16         ` Lyude Paul
2018-03-12 21:01   ` [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp Ville Syrjälä
2018-03-12 21:01     ` Ville Syrjälä
2018-03-13 23:24     ` Lyude Paul
2018-03-13 23:24       ` Lyude Paul
2018-03-14 17:28       ` Ville Syrjälä
2018-03-14 17:28         ` Ville Syrjälä

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=20180312210555.GS5453@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=manasi.d.navare@intel.com \
    --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 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.