All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/5] Handle link training failure during modeset
@ 2016-11-15  3:13 Manasi Navare
  2016-11-15  3:13 ` [PATCH 1/5] drm: Add a new connector property for link status Manasi Navare
                   ` (6 more replies)
  0 siblings, 7 replies; 31+ messages in thread
From: Manasi Navare @ 2016-11-15  3:13 UTC (permalink / raw)
  To: intel-gfx, dri-devel; +Cc: Manasi Navare

Submitting new series that adds proper commit messages/cover letter
and kernel documentation. It also moved the set_link_status function
to drm core so other kernel drivers can make use of it.

The idea presented in these patches is to address link training failure
in a way that:
a) changes the current happy day scenario as little as possible, to avoid
regressions, b) can be implemented the same way by all drm drivers, c)
is still opt-in for the drivers and userspace, and opting out doesn't
regress the user experience, d) doesn't prevent drivers from
implementing better or alternate approaches, possibly without userspace
involvement. And, of course, handles all the issues presented.

The solution is to add a "link status" connector property. In the usual
happy day scenario, this is always "good". If something fails during or
after a mode set, the kernel driver can set the link status to "bad",
prune the mode list based on new information as necessary, and send a
hotplug uevent for userspace to have it re-check the valid modes through
getconnector, and try again. If the theoretical capabilities of the link
can't be reached, the mode list is trimmed based on that.

If the userspace is not aware of the property, the user experience is
the same as it currently is. If the userspace is aware of the property,
it has a chance to improve user experience. If a drm driver does not
modify the property (it stays "good"), the user experience is the same
as it currently is. A drm driver can also choose to try to handle more
of the failures in kernel, hardware not limiting, or it can choose to
involve userspace more. Up to the drivers.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

Finally, while DP CTS compliance is advertized (which is great, and
could be made to work similarly for all drm drivers), this can be used
for the more important goal of improving user experience on link
training failures, by avoiding black screens.

Acked-by: Tony Cheng <tony.cheng@amd.com>
Acked-by: Harry Wentland <Harry.wentland@amd.com>

Manasi Navare (5):
  drm: Add a new connector property for link status
  drm: Set DRM connector link status property
  drm/i915: Update CRTC state if connector link status property changed
  drm/i915: Find fallback link rate/lane count
  drm/i915: Implement Link Rate fallback on Link training failure

 drivers/gpu/drm/drm_atomic_helper.c           |   7 ++
 drivers/gpu/drm/drm_connector.c               |  55 ++++++++++
 drivers/gpu/drm/i915/intel_ddi.c              |  21 +++-
 drivers/gpu/drm/i915/intel_dp.c               | 144 +++++++++++++++++++++++++-
 drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
 drivers/gpu/drm/i915/intel_drv.h              |  10 +-
 include/drm/drm_connector.h                   |   9 +-
 include/drm/drm_crtc.h                        |   5 +
 include/uapi/drm/drm_mode.h                   |   4 +
 9 files changed, 257 insertions(+), 10 deletions(-)

-- 
1.9.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 31+ messages in thread
* [PATCH 0/5] Clean series for Link training failure handling
@ 2016-11-19  2:58 Manasi Navare
  2016-11-19  2:59 ` [PATCH 4/5] drm/i915: Find fallback link rate/lane count Manasi Navare
  0 siblings, 1 reply; 31+ messages in thread
From: Manasi Navare @ 2016-11-19  2:58 UTC (permalink / raw)
  To: intel-gfx, dri-devel

The idea presented in these patches is to address link training failure
in a way that:
a) changes the current happy day scenario as little as possible, to avoid
regressions, b) can be implemented the same way by all drm drivers, c)
is still opt-in for the drivers and userspace, and opting out doesn't
regress the user experience, d) doesn't prevent drivers from
implementing better or alternate approaches, possibly without userspace
involvement. And, of course, handles all the issues presented.

The solution is to add a "link status" connector property. In the usual
happy day scenario, this is always "good". If something fails during or
after a mode set, the kernel driver can set the link status to "bad",
prune the mode list based on new information as necessary, and send a
hotplug uevent for userspace to have it re-check the valid modes through
getconnector, and try again. If the theoretical capabilities of the link
can't be reached, the mode list is trimmed based on that.

If the userspace is not aware of the property, the user experience is
the same as it currently is. If the userspace is aware of the property,
it has a chance to improve user experience. If a drm driver does not
modify the property (it stays "good"), the user experience is the same
as it currently is. A drm driver can also choose to try to handle more
of the failures in kernel, hardware not limiting, or it can choose to
involve userspace more. Up to the drivers.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

Finally, while DP CTS compliance is advertized (which is great, and
could be made to work similarly for all drm drivers), this can be used
for the more important goal of improving user experience on link
training failures, by avoiding black screens.


Manasi Navare (5):
  drm: Add a new connector property for link status
  drm: Set DRM connector link status property
  drm/i915: Update CRTC state if connector link status property changed
  drm/i915: Find fallback link rate/lane count
  drm/i915: Implement Link Rate fallback on Link training failure

 drivers/gpu/drm/drm_atomic_helper.c           |   7 ++
 drivers/gpu/drm/drm_connector.c               |  65 +++++++++++++++-
 drivers/gpu/drm/i915/intel_dp.c               | 103 +++++++++++++++++++++++++-
 drivers/gpu/drm/i915/intel_dp_link_training.c |  28 ++++++-
 drivers/gpu/drm/i915/intel_drv.h              |   7 ++
 include/drm/drm_connector.h                   |   9 ++-
 include/drm/drm_mode_config.h                 |   5 ++
 include/uapi/drm/drm_mode.h                   |   4 +
 8 files changed, 221 insertions(+), 7 deletions(-)

-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 31+ messages in thread
* [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure
@ 2016-11-18  7:29 Manasi Navare
  0 siblings, 0 replies; 31+ messages in thread
From: Manasi Navare @ 2016-11-18  7:29 UTC (permalink / raw)
  To: dri-devel, intel-gfx; +Cc: Daniel Vetter

If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes. It will redo
the modeset on the current mode at lower link rate or if the current
mode gets pruned due to lower link constraints then, it will send a
hotplug uevent for userspace to handle it.

This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.

v7:
Remove the redundant variable in previous patch itself
v6:
* Obtain link rate index from fallback_link_rate using
the helper intel_dp_link_rate_index (Jani Nikula)
* Include fallback within intel_dp_start_link_train (Jani Nikula)
v5:
* Move set link status to drm core (Daniel Vetter, Jani Nikula)
v4:
* Add fallback support for non DDI platforms too
* Set connector->link status inside set_link_status function
(Jani Nikula)
v3:
* Set link status property to BAd unconditionally (Jani Nikula)
* Dont use two separate variables link_train_failed and link_status
to indicate same thing (Jani Nikula)
v2:
* Squashed a few patches (Jani Nikula)

Acked-by: Tony Cheng <tony.cheng@amd.com>
Acked-by: Harry Wentland <Harry.wentland@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c               | 63 ++++++++++++++++++++++++++-
 drivers/gpu/drm/i915/intel_dp_link_training.c | 28 +++++++++++-
 drivers/gpu/drm/i915/intel_drv.h              |  3 ++
 3 files changed, 90 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4fb89e1..a56a34d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -351,8 +351,14 @@ int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
 		target_clock = fixed_mode->clock;
 	}
 
-	max_link_clock = intel_dp_max_link_rate(intel_dp);
-	max_lanes = intel_dp_max_lane_count(intel_dp);
+	/* Prune the modes using the fallback link rate/lane count */
+	if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
+		max_link_clock = intel_dp->fallback_link_rate;
+		max_lanes = intel_dp->fallback_lane_count;
+	} else {
+		max_link_clock = intel_dp_max_link_rate(intel_dp);
+		max_lanes = intel_dp_max_lane_count(intel_dp);
+	}
 
 	max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
 	mode_rate = intel_dp_link_required(target_clock, 18);
@@ -1588,6 +1594,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
 	enum port port = dp_to_dig_port(intel_dp)->port;
 	struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
 	struct intel_connector *intel_connector = intel_dp->attached_connector;
+	struct drm_connector *connector = &intel_connector->base;
 	int lane_count, clock;
 	int min_lane_count = 1;
 	int max_lane_count = intel_dp_max_lane_count(intel_dp);
@@ -1635,6 +1642,14 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
 	if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
 		return false;
 
+	/* Fall back to lower link rate in case of failure in previous modeset */
+	if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
+		min_lane_count = max_lane_count = intel_dp->fallback_lane_count;
+		min_clock = max_clock = intel_dp_link_rate_index(intel_dp,
+								 common_rates,
+								 intel_dp->fallback_link_rate);
+	}
+
 	DRM_DEBUG_KMS("DP link computation with max lane count %i "
 		      "max bw %d pixel clock %iKHz\n",
 		      max_lane_count, common_rates[max_clock],
@@ -4415,6 +4430,10 @@ static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
 		intel_dp->compliance_test_active = 0;
 		intel_dp->compliance_test_type = 0;
 		intel_dp->compliance_test_data = 0;
+		intel_dp->fallback_link_rate = 0;
+		intel_dp->fallback_lane_count = 0;
+		drm_mode_connector_set_link_status_property(connector,
+							    DRM_MODE_LINK_STATUS_GOOD);
 
 		if (intel_dp->is_mst) {
 			DRM_DEBUG_KMS("MST device may have disappeared %d vs %d\n",
@@ -4506,6 +4525,11 @@ static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
 	DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
 		      connector->base.id, connector->name);
 
+	/* If this is a retry due to link trianing failure */
+	if (status == connector_status_connected &&
+	    connector->link_status == DRM_MODE_LINK_STATUS_BAD)
+		return status;
+
 	/* If full detect is not performed yet, do a full detect */
 	if (!intel_dp->detect_done)
 		status = intel_dp_long_pulse(intel_dp->attached_connector);
@@ -5671,6 +5695,37 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 	return false;
 }
 
+static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
+{
+	struct intel_connector *intel_connector;
+	struct drm_connector *connector;
+	struct drm_display_mode *mode;
+	bool verbose_prune = true;
+
+	intel_connector = container_of(work, typeof(*intel_connector),
+				       modeset_retry_work);
+	connector = &intel_connector->base;
+
+	/* Grab the locks before changing connector property*/
+	mutex_lock(&connector->dev->mode_config.mutex);
+	DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
+		      connector->name);
+	list_for_each_entry(mode, &connector->modes, head) {
+		mode->status = intel_dp_mode_valid(connector,
+						   mode);
+	}
+	drm_mode_prune_invalid(connector->dev, &connector->modes,
+			       verbose_prune);
+	/* Set connector link status to BAD and send a Uevent to notify
+	 * userspace to do a modeset.
+	 */
+	drm_mode_connector_set_link_status_property(connector,
+						    DRM_MODE_LINK_STATUS_BAD);
+	mutex_unlock(&connector->dev->mode_config.mutex);
+	/* Send Hotplug uevent so userspace can reprobe */
+	drm_kms_helper_hotplug_event(connector->dev);
+}
+
 bool
 intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 			struct intel_connector *intel_connector)
@@ -5683,6 +5738,10 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 	enum port port = intel_dig_port->port;
 	int type;
 
+	/* Initialize the work for modeset in case of link train failure */
+	INIT_WORK(&intel_connector->modeset_retry_work,
+		  intel_dp_modeset_retry_work_fn);
+
 	if (WARN(intel_dig_port->max_lanes < 1,
 		 "Not enough lanes (%d) for DP on port %c\n",
 		 intel_dig_port->max_lanes, port_name(port)))
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 0048b52..cc243db 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -313,6 +313,30 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
 void
 intel_dp_start_link_train(struct intel_dp *intel_dp)
 {
-	intel_dp_link_training_clock_recovery(intel_dp);
-	intel_dp_link_training_channel_equalization(intel_dp);
+	struct intel_connector *intel_connector = intel_dp->attached_connector;
+	struct drm_connector *connector = &intel_connector->base;
+
+	if (!intel_dp_link_training_clock_recovery(intel_dp))
+		goto failure_handling;
+	if (!intel_dp_link_training_channel_equalization(intel_dp))
+		goto failure_handling;
+
+	/* Reset the Link Train Values */
+	DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
+		      intel_dp->link_rate, intel_dp->lane_count);
+	intel_dp->fallback_link_rate = 0;
+	intel_dp->fallback_lane_count = 0;
+	drm_mode_connector_set_link_status_property(connector,
+						    DRM_MODE_LINK_STATUS_GOOD);
+	return;
+
+ failure_handling:
+	DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
+		      intel_dp->link_rate, intel_dp->lane_count);
+	if (!intel_dp_get_link_train_fallback_values(intel_dp,
+						     intel_dp->link_rate,
+						     intel_dp->lane_count))
+		/* Schedule a Hotplug Uevent to userspace to start modeset */
+		schedule_work(&intel_connector->modeset_retry_work);
+	return;
 }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e1c43a9..33be66f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -315,6 +315,9 @@ struct intel_connector {
 	void *port; /* store this opaque as its illegal to dereference it */
 
 	struct intel_dp *mst_port;
+
+	/* Work struct to schedule a uevent on link train failure */
+	struct work_struct modeset_retry_work;
 };
 
 struct dpll {
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 31+ messages in thread
* [PATCH 0/5] Link Training failure handling during modeset
@ 2016-11-18  7:13 Manasi Navare
  2016-11-18  7:13 ` [PATCH 4/5] drm/i915: Find fallback link rate/lane count Manasi Navare
  0 siblings, 1 reply; 31+ messages in thread
From: Manasi Navare @ 2016-11-18  7:13 UTC (permalink / raw)
  To: dri-devel, intel-gfx; +Cc: Manasi Navare

Submitting this series again since it had to be rebased dur to changes
in drm that got merged.

The idea presented in these patches is to address link training failure
in a way that:
a) changes the current happy day scenario as little as possible, to avoid
regressions, b) can be implemented the same way by all drm drivers, c)
is still opt-in for the drivers and userspace, and opting out doesn't
regress the user experience, d) doesn't prevent drivers from
implementing better or alternate approaches, possibly without userspace
involvement. And, of course, handles all the issues presented.

The solution is to add a "link status" connector property. In the usual
happy day scenario, this is always "good". If something fails during or
after a mode set, the kernel driver can set the link status to "bad",
prune the mode list based on new information as necessary, and send a
hotplug uevent for userspace to have it re-check the valid modes through
getconnector, and try again. If the theoretical capabilities of the link
can't be reached, the mode list is trimmed based on that.

If the userspace is not aware of the property, the user experience is
the same as it currently is. If the userspace is aware of the property,
it has a chance to improve user experience. If a drm driver does not
modify the property (it stays "good"), the user experience is the same
as it currently is. A drm driver can also choose to try to handle more
of the failures in kernel, hardware not limiting, or it can choose to
involve userspace more. Up to the drivers.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

Finally, while DP CTS compliance is advertized (which is great, and
could be made to work similarly for all drm drivers), this can be used
for the more important goal of improving user experience on link
training failures, by avoiding black screens.

Manasi Navare (5):
  drm: Add a new connector property for link status
  drm: Set DRM connector link status property
  drm/i915: Update CRTC state if connector link status property changed
  drm/i915: Find fallback link rate/lane count
  drm/i915: Implement Link Rate fallback on Link training failure

 drivers/gpu/drm/drm_atomic_helper.c           |   7 ++
 drivers/gpu/drm/drm_connector.c               |  54 ++++++++++++++
 drivers/gpu/drm/i915/intel_dp.c               | 103 +++++++++++++++++++++++++-
 drivers/gpu/drm/i915/intel_dp_link_training.c |  28 ++++++-
 drivers/gpu/drm/i915/intel_drv.h              |   7 ++
 include/drm/drm_connector.h                   |   9 ++-
 include/drm/drm_mode_config.h                 |   5 ++
 include/uapi/drm/drm_mode.h                   |   4 +
 8 files changed, 212 insertions(+), 5 deletions(-)

-- 
1.9.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 31+ messages in thread
* [PATCH 0/5] Handle Link Training Failure during modeset
@ 2016-11-10  4:42 Manasi Navare
  2016-11-10  4:42 ` [PATCH 4/5] drm/i915: Find fallback link rate/lane count Manasi Navare
  0 siblings, 1 reply; 31+ messages in thread
From: Manasi Navare @ 2016-11-10  4:42 UTC (permalink / raw)
  To: dri-devel, intel-gfx

Link training failure is handled by lowering the link rate first
until it reaches the minimum and keeping the lane count maximum
and then lowering the lane count until it reaches minimim. These
fallback values are saved and hotplug uevent is sent to the userspace
after setting the connector link status property to BAD. Userspace
should triiger another modeset on a uevent and if link status property
is BAD. This will retrain the link at fallback values.
This is repeated until the link is successfully trained.

This has been validated to pass DP compliance.

Manasi Navare (5):
  drm: Add a new connector property for link status
  drm/i915: Set link status property for DP connector
  drm/i915: Update CRTC state if connector link status property changed
  drm/i915: Find fallback link rate/lane count
  drm/i915: Implement Link Rate fallback on Link training failure

 drivers/gpu/drm/drm_atomic_helper.c           |   7 ++
 drivers/gpu/drm/drm_connector.c               |  17 ++++
 drivers/gpu/drm/i915/intel_ddi.c              |  21 +++-
 drivers/gpu/drm/i915/intel_dp.c               | 138 +++++++++++++++++++++++++-
 drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
 drivers/gpu/drm/i915/intel_drv.h              |  12 ++-
 include/drm/drm_connector.h                   |   7 +-
 include/drm/drm_crtc.h                        |   5 +
 include/uapi/drm/drm_mode.h                   |   4 +
 9 files changed, 214 insertions(+), 9 deletions(-)

-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 31+ messages in thread
end of thread, other threads:[~2016-11-19  2:59 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-15  3:13 [PATCH 0/5] Handle link training failure during modeset Manasi Navare
2016-11-15  3:13 ` [PATCH 1/5] drm: Add a new connector property for link status Manasi Navare
2016-11-15  3:13 ` [PATCH 2/5] drm: Set DRM connector link status property Manasi Navare
2016-11-15  3:23   ` Manasi Navare
2016-11-15  7:50     ` Daniel Vetter
2016-11-15  7:49   ` [Intel-gfx] " Daniel Vetter
2016-11-15 23:56     ` Manasi Navare
2016-11-16  7:35       ` [Intel-gfx] " Daniel Vetter
2016-11-15  7:53   ` Daniel Vetter
2016-11-16  1:13     ` Manasi Navare
2016-11-16  7:29       ` Daniel Vetter
2016-11-16  1:58   ` [PATCH v2 " Manasi Navare
2016-11-15  3:13 ` [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed Manasi Navare
2016-11-15  3:13 ` [PATCH 4/5] drm/i915: Find fallback link rate/lane count Manasi Navare
2016-11-16 17:32   ` Manasi Navare
2016-11-17 12:58   ` Jani Nikula
2016-11-17 19:44     ` Manasi Navare
2016-11-15  3:13 ` [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure Manasi Navare
2016-11-16 17:34   ` Manasi Navare
2016-11-17 12:49   ` Jani Nikula
2016-11-17 19:55     ` Manasi Navare
2016-11-15  4:24 ` ✓ Fi.CI.BAT: success for Handle Link Training Failure during modeset (rev2) Patchwork
2016-11-17 12:29 ` [PATCH 0/5] Handle link training failure during modeset Jani Nikula
2016-11-17 19:48   ` Manasi Navare
  -- strict thread matches above, loose matches on Subject: below --
2016-11-19  2:58 [PATCH 0/5] Clean series for Link training failure handling Manasi Navare
2016-11-19  2:59 ` [PATCH 4/5] drm/i915: Find fallback link rate/lane count Manasi Navare
2016-11-18  7:29 [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure Manasi Navare
2016-11-18  7:13 [PATCH 0/5] Link Training failure handling during modeset Manasi Navare
2016-11-18  7:13 ` [PATCH 4/5] drm/i915: Find fallback link rate/lane count Manasi Navare
2016-11-18  7:29   ` Manasi Navare
2016-11-18 13:22     ` Jani Nikula
2016-11-18 15:39       ` Manasi Navare
2016-11-19  2:09         ` Manasi Navare
2016-11-10  4:42 [PATCH 0/5] Handle Link Training Failure during modeset Manasi Navare
2016-11-10  4:42 ` [PATCH 4/5] drm/i915: Find fallback link rate/lane count Manasi Navare

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.