[PATCH 0/5] Link Training failure handling during modeset

[PATCH 0/5] Link Training failure handling during modeset

[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

[PATCH 1/5] drm: Add a new connector property for link status

[Manasi Navare]

At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of the
link, but it's possible we can't reach this in practice. The DP spec
describes how the link should be reduced, but we can't reduce the link
below the requirements of the mode. Black screen follows.

One idea would be to have setcrtc return a failure. However, it
already should not fail as the atomic checks have passed. It would also
conflict with the idea of making setcrtc asynchronous in the future,
returning before the actual mode setting and link training.

Another idea is to train the link "upfront" at hotplug time, before
pruning the mode list, so that we can do the pruning based on practical
not theoretical capabilities. However, the changes for link training are
pretty drastic, all for the sake of error handling and DP compliance,
when the most common happy day scenario is the current approach of link
training at mode setting time, using the optimal parameters for the
mode. It is also not certain all hardware could do this without the pipe
on; not even all our hardware can do this. Some of this can be solved,
but not trivially.

Both of the above ideas also fail to address link degradation *during*
operation.

The solution is to add a new "link-status" connector property in order
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.
In the usual happy day scenario, this is always "good". If something fails
during or after a mode set, the kernel driver can prune the mode list based
on new information as necessary, set the link status to "bad",
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.

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.

v4:
* Rebase on drm-nightly
* Add a detailed commit message (Jani Nikula)
v3:
* Drop "link training" from description since this is
not specific to DP (Jani Nikula)
* Add link status member to store property value locally
(Ville Syrjala)
v2:
* Make this a default connector property (Daniel Vetter)

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
---
 drivers/gpu/drm/drm_connector.c | 17 +++++++++++++++++
 include/drm/drm_connector.h     |  7 ++++++-
 include/drm/drm_mode_config.h   |  5 +++++
 include/uapi/drm/drm_mode.h     |  4 ++++
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b5c6a8e..2b6ee0e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
 	drm_object_attach_property(&connector->base,
 				      config->dpms_property, 0);
 
+	drm_object_attach_property(&connector->base,
+				   config->link_status_property,
+				   0);
+
 	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
 		drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
 	}
@@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum subpixel_order order)
 };
 DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
 
+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+	{ DRM_MODE_LINK_STATUS_GOOD, "Good" },
+	{ DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -622,6 +632,13 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.tile_property = prop;
 
+	prop = drm_property_create_enum(dev, 0, "link-status",
+					drm_link_status_enum_list,
+					ARRAY_SIZE(drm_link_status_enum_list));
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.link_status_property = prop;
+
 	return 0;
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 34f9741..ab564e6 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -695,6 +695,12 @@ struct drm_connector {
 	uint8_t num_h_tile, num_v_tile;
 	uint8_t tile_h_loc, tile_v_loc;
 	uint16_t tile_h_size, tile_v_size;
+
+	/* Connector Link status
+	 * 0: If the link is Good
+	 * 1: If the link is Bad
+	 */
+	int link_status;
 };
 
 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
@@ -767,7 +773,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
-
 int drm_mode_connector_set_path_property(struct drm_connector *connector,
 					 const char *path);
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index bf9991b..86faee4 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -431,6 +431,11 @@ struct drm_mode_config {
 	 */
 	struct drm_property *tile_property;
 	/**
+	 * @link_status_property: Default connector property for link status
+	 * of a connector
+	 */
+	struct drm_property *link_status_property;
+	/**
 	 * @plane_type_property: Default plane property to differentiate
 	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
 	 */
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 728790b..309c478 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -123,6 +123,10 @@
 #define DRM_MODE_DIRTY_ON       1
 #define DRM_MODE_DIRTY_ANNOTATE 2
 
+/* Link Status options */
+#define DRM_MODE_LINK_STATUS_GOOD	0
+#define DRM_MODE_LINK_STATUS_BAD	1
+
 struct drm_mode_modeinfo {
 	__u32 clock;
 	__u16 hdisplay;
-- 
1.9.1

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

[PATCH v5 1/5] drm: Add a new connector property for link status

[Manasi Navare]

At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of the
link, but it's possible we can't reach this in practice. The DP spec
describes how the link should be reduced, but we can't reduce the link
below the requirements of the mode. Black screen follows.

One idea would be to have setcrtc return a failure. However, it
already should not fail as the atomic checks have passed. It would also
conflict with the idea of making setcrtc asynchronous in the future,
returning before the actual mode setting and link training.

Another idea is to train the link "upfront" at hotplug time, before
pruning the mode list, so that we can do the pruning based on practical
not theoretical capabilities. However, the changes for link training are
pretty drastic, all for the sake of error handling and DP compliance,
when the most common happy day scenario is the current approach of link
training at mode setting time, using the optimal parameters for the
mode. It is also not certain all hardware could do this without the pipe
on; not even all our hardware can do this. Some of this can be solved,
but not trivially.

Both of the above ideas also fail to address link degradation *during*
operation.

The solution is to add a new "link-status" connector property in order
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.
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 GET_CONNECTOR IOCTL, and try again. If the theoretical capabilities of
the link can't be reached, the mode list is trimmed based on that.

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.

v5:
* Added kernel doc for connector standard properties (Daniel Vetter)
v4:
* Rebase on drm-nightly
* Add a detailed commit message (Jani Nikula)
v3:
* Drop "link training" from description since this is
not specific to DP (Jani Nikula)
* Add link status member to store property value locally
(Ville Syrjala)
v2:
* Make this a default connector property (Daniel Vetter)

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
---
 drivers/gpu/drm/drm_connector.c | 28 ++++++++++++++++++++++++++--
 include/drm/drm_connector.h     |  7 ++++++-
 include/drm/drm_mode_config.h   |  5 +++++
 include/uapi/drm/drm_mode.h     |  4 ++++
 4 files changed, 41 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5a45262..cfb5cf7 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
 	drm_object_attach_property(&connector->base,
 				      config->dpms_property, 0);
 
+	drm_object_attach_property(&connector->base,
+				   config->link_status_property,
+				   0);
+
 	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
 		drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
 	}
@@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum subpixel_order order)
 };
 DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
 
+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+	{ DRM_MODE_LINK_STATUS_GOOD, "Good" },
+	{ DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -616,7 +626,7 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info,
  * 	path property the MST manager created. Userspace cannot change this
  * 	property.
  * TILE:
- * 	Connector tile group property to indicate how a set of DRM connector
+ *      Connector tile group property to indicate how a set of DRM connector
  * 	compose together into one logical screen. This is used by both high-res
  * 	external screens (often only using a single cable, but exposing multiple
  * 	DP MST sinks), or high-res integrated panels (like dual-link DSI) which
@@ -625,7 +635,14 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info,
  * 	tiling and virtualize both &drm_crtc and &drm_plane if needed. Drivers
  * 	should update this value using drm_mode_connector_set_tile_property().
  * 	Userspace cannot change this property.
- *
+ * link-status:
+ *      Connector link-status property to indicate the status of link during
+ *      the modeset. The default value of link-status is "GOOD". If something
+ *      fails during modeset, the kernel driver can set this to "BAD", prune
+ *      the mode list based on new link parameters and send a hotplug uevent
+ *      to notify userspace to re-check the valid modes through GET_CONNECTOR
+ *      IOCTL and redo a modeset. Drivers should update this value using
+ *      drm_mode_connector_set_link_status_property().
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ -666,6 +683,13 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.tile_property = prop;
 
+	prop = drm_property_create_enum(dev, 0, "link-status",
+					drm_link_status_enum_list,
+					ARRAY_SIZE(drm_link_status_enum_list));
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.link_status_property = prop;
+
 	return 0;
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 34f9741..ab564e6 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -695,6 +695,12 @@ struct drm_connector {
 	uint8_t num_h_tile, num_v_tile;
 	uint8_t tile_h_loc, tile_v_loc;
 	uint16_t tile_h_size, tile_v_size;
+
+	/* Connector Link status
+	 * 0: If the link is Good
+	 * 1: If the link is Bad
+	 */
+	int link_status;
 };
 
 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
@@ -767,7 +773,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
-
 int drm_mode_connector_set_path_property(struct drm_connector *connector,
 					 const char *path);
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index bf9991b..86faee4 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -431,6 +431,11 @@ struct drm_mode_config {
 	 */
 	struct drm_property *tile_property;
 	/**
+	 * @link_status_property: Default connector property for link status
+	 * of a connector
+	 */
+	struct drm_property *link_status_property;
+	/**
 	 * @plane_type_property: Default plane property to differentiate
 	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
 	 */
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 728790b..309c478 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -123,6 +123,10 @@
 #define DRM_MODE_DIRTY_ON       1
 #define DRM_MODE_DIRTY_ANNOTATE 2
 
+/* Link Status options */
+#define DRM_MODE_LINK_STATUS_GOOD	0
+#define DRM_MODE_LINK_STATUS_BAD	1
+
 struct drm_mode_modeinfo {
 	__u32 clock;
 	__u16 hdisplay;
-- 
1.9.1

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

Re: [PATCH v5 1/5] drm: Add a new connector property for link status

[Daniel Vetter]

On Fri, Nov 18, 2016 at 06:50:35PM -0800, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of the
> link, but it's possible we can't reach this in practice. The DP spec
> describes how the link should be reduced, but we can't reduce the link
> below the requirements of the mode. Black screen follows.
> 
> One idea would be to have setcrtc return a failure. However, it
> already should not fail as the atomic checks have passed. It would also
> conflict with the idea of making setcrtc asynchronous in the future,
> returning before the actual mode setting and link training.
> 
> Another idea is to train the link "upfront" at hotplug time, before
> pruning the mode list, so that we can do the pruning based on practical
> not theoretical capabilities. However, the changes for link training are
> pretty drastic, all for the sake of error handling and DP compliance,
> when the most common happy day scenario is the current approach of link
> training at mode setting time, using the optimal parameters for the
> mode. It is also not certain all hardware could do this without the pipe
> on; not even all our hardware can do this. Some of this can be solved,
> but not trivially.
> 
> Both of the above ideas also fail to address link degradation *during*
> operation.
> 
> The solution is to add a new "link-status" connector property in order
> 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.
> 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 GET_CONNECTOR IOCTL, and try again. If the theoretical capabilities of
> the link can't be reached, the mode list is trimmed based on that.
> 
> 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.
> 
> v5:
> * Added kernel doc for connector standard properties (Daniel Vetter)
> v4:
> * Rebase on drm-nightly
> * Add a detailed commit message (Jani Nikula)
> v3:
> * Drop "link training" from description since this is
> not specific to DP (Jani Nikula)
> * Add link status member to store property value locally
> (Ville Syrjala)
> v2:
> * Make this a default connector property (Daniel Vetter)
> 
> Reviewed-by: Harry Wentland <harry.wentland@amd.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 28 ++++++++++++++++++++++++++--
>  include/drm/drm_connector.h     |  7 ++++++-
>  include/drm/drm_mode_config.h   |  5 +++++
>  include/uapi/drm/drm_mode.h     |  4 ++++
>  4 files changed, 41 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 5a45262..cfb5cf7 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
>  	drm_object_attach_property(&connector->base,
>  				      config->dpms_property, 0);
>  
> +	drm_object_attach_property(&connector->base,
> +				   config->link_status_property,
> +				   0);
> +
>  	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>  		drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
>  	}
> @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum subpixel_order order)
>  };
>  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>  
> +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
> +	{ DRM_MODE_LINK_STATUS_GOOD, "Good" },
> +	{ DRM_MODE_LINK_STATUS_BAD, "Bad" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
> +
>  /**
>   * drm_display_info_set_bus_formats - set the supported bus formats
>   * @info: display info to store bus formats in
> @@ -616,7 +626,7 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info,
>   * 	path property the MST manager created. Userspace cannot change this
>   * 	property.
>   * TILE:
> - * 	Connector tile group property to indicate how a set of DRM connector
> + *      Connector tile group property to indicate how a set of DRM connector

Spurious change, pls remove.

>   * 	compose together into one logical screen. This is used by both high-res
>   * 	external screens (often only using a single cable, but exposing multiple
>   * 	DP MST sinks), or high-res integrated panels (like dual-link DSI) which
> @@ -625,7 +635,14 @@ int drm_display_info_set_bus_formats(struct drm_display_info *info,
>   * 	tiling and virtualize both &drm_crtc and &drm_plane if needed. Drivers
>   * 	should update this value using drm_mode_connector_set_tile_property().
>   * 	Userspace cannot change this property.
> - *
> + * link-status:
> + *      Connector link-status property to indicate the status of link during
> + *      the modeset. The default value of link-status is "GOOD". If something
> + *      fails during modeset, the kernel driver can set this to "BAD", prune

Not just during modesets, but also later on. What about "If something
fails (e.g. link training during async modeset, or link re-training later
on, or any downstream reconfiguration), the kernel ..."

> + *      the mode list based on new link parameters and send a hotplug uevent
> + *      to notify userspace to re-check the valid modes through GET_CONNECTOR
> + *      IOCTL and redo a modeset. Drivers should update this value using
> + *      drm_mode_connector_set_link_status_property().

We also need to explain how exactly the property goes back to "GOOD", but
that's the part we still need to figure out.
-Daniel

>   * Connectors also have one standardized atomic property:
>   *
>   * CRTC_ID:
> @@ -666,6 +683,13 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
>  		return -ENOMEM;
>  	dev->mode_config.tile_property = prop;
>  
> +	prop = drm_property_create_enum(dev, 0, "link-status",
> +					drm_link_status_enum_list,
> +					ARRAY_SIZE(drm_link_status_enum_list));
> +	if (!prop)
> +		return -ENOMEM;
> +	dev->mode_config.link_status_property = prop;
> +
>  	return 0;
>  }
>  
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 34f9741..ab564e6 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -695,6 +695,12 @@ struct drm_connector {
>  	uint8_t num_h_tile, num_v_tile;
>  	uint8_t tile_h_loc, tile_v_loc;
>  	uint16_t tile_h_size, tile_v_size;
> +
> +	/* Connector Link status
> +	 * 0: If the link is Good
> +	 * 1: If the link is Bad
> +	 */
> +	int link_status;
>  };
>  
>  #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> @@ -767,7 +773,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
>  int drm_mode_create_scaling_mode_property(struct drm_device *dev);
>  int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
>  int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
> -
>  int drm_mode_connector_set_path_property(struct drm_connector *connector,
>  					 const char *path);
>  int drm_mode_connector_set_tile_property(struct drm_connector *connector);
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index bf9991b..86faee4 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -431,6 +431,11 @@ struct drm_mode_config {
>  	 */
>  	struct drm_property *tile_property;
>  	/**
> +	 * @link_status_property: Default connector property for link status
> +	 * of a connector
> +	 */
> +	struct drm_property *link_status_property;
> +	/**
>  	 * @plane_type_property: Default plane property to differentiate
>  	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
>  	 */
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 728790b..309c478 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -123,6 +123,10 @@
>  #define DRM_MODE_DIRTY_ON       1
>  #define DRM_MODE_DIRTY_ANNOTATE 2
>  
> +/* Link Status options */
> +#define DRM_MODE_LINK_STATUS_GOOD	0
> +#define DRM_MODE_LINK_STATUS_BAD	1
> +
>  struct drm_mode_modeinfo {
>  	__u32 clock;
>  	__u16 hdisplay;
> -- 
> 1.9.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm: Set DRM connector link status property

[Manasi Navare]

In the usual working scenarios, this property is "Good".
If something fails during modeset, the DRM driver can
set the link status to "Bad", prune the mode list based on the
link rate/lane count fallback values and send  hotplug uevent
so that userspace that is aware of this property can take an
appropriate action by reprobing connectors and re triggering
a modeset to improve user experience and avoid black screens.
In case of userspace that is not aware of this link status
property, the user experience will be unchanged.

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.

v3:
* Updated kernel doc even more (Daniel Vetter)
v2:
* Update kernel doc, add lockdep_assert_held (Daniel Vetter)
Cc: dri-devel@lists.freedesktop.org
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/drm_connector.c | 37 +++++++++++++++++++++++++++++++++++++
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2b6ee0e..f3f09b8 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -968,6 +968,43 @@ int drm_mode_connector_update_edid_property(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
 
+/**
+ * drm_mode_connector_set_link_status_property - Set link status property of a connector
+ * @connector: drm connector
+ * @link_status: new value of link status property (0: Good, 1: Bad)
+ *
+ * In usual working scenario, this link status property will always be set to
+ * "GOOD". If something fails during or after a mode set, the kernel driver should
+ * prune the mode list based on new information, set this link status property to
+ * "BAD". The caller then needs to send a hotplug uevent for userspace to re-check
+ * the valid modes through GET_CONNECTOR_IOCTL and retry modeset.
+ *
+ * Note that a lot of existing userspace do not handle this property.
+ * Drivers can therefore not rely on userspace to fix up everything and
+ * should try to handle issues (like just re-training a link) without
+ * userspace's intervention. This should only be used when the current mode
+ * fails and userspace must select a different display mode.
+ * The DRM driver can chose to not modify property and keep link status
+ * as "GOOD" always to keep the user experience same as it currently is.
+ *
+ * The reason for adding this property is to handle link training failures, but
+ * it is not limited to DP or link training. For example, if we implement
+ * asynchronous setcrtc, this property can be used to report any failures in that.
+ */
+void drm_mode_connector_set_link_status_property(struct drm_connector *connector,
+						 uint64_t link_status)
+{
+	struct drm_device *dev = connector->dev;
+
+	/* Make sure the mutex is grabbed */
+	lockdep_assert_held(&dev->mode_config.mutex);
+	connector->link_status = link_status;
+	drm_object_property_set_value(&connector->base,
+				      dev->mode_config.link_status_property,
+				      link_status);
+}
+EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
+
 int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
 				    struct drm_property *property,
 				    uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ab564e6..f47b345 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct drm_connector *connector,
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
 int drm_mode_connector_update_edid_property(struct drm_connector *connector,
 					    const struct edid *edid);
+void drm_mode_connector_set_link_status_property(struct drm_connector *connector,
+						 uint64_t link_status);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
1.9.1

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

[PATCH v3 2/5] drm: Set DRM connector link status property

[Manasi Navare]

In the usual working scenarios, this property is "Good".
If something fails during modeset, the DRM driver can
set the link status to "Bad", prune the mode list based on the
link rate/lane count fallback values and send  hotplug uevent
so that userspace that is aware of this property can take an
appropriate action by reprobing connectors and re triggering
a modeset to improve user experience and avoid black screens.
In case of userspace that is not aware of this link status
property, the user experience will be unchanged.

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.

v3:
* Updated kernel doc even more (Daniel Vetter)
v2:
* Update kernel doc, add lockdep_assert_held (Daniel Vetter)
Cc: dri-devel@lists.freedesktop.org
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/drm_connector.c | 37 +++++++++++++++++++++++++++++++++++++
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index cfb5cf7..b5ca70f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1019,6 +1019,43 @@ int drm_mode_connector_update_edid_property(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
 
+/**
+ * drm_mode_connector_set_link_status_property - Set link status property of a connector
+ * @connector: drm connector
+ * @link_status: new value of link status property (0: Good, 1: Bad)
+ *
+ * In usual working scenario, this link status property will always be set to
+ * "GOOD". If something fails during or after a mode set, the kernel driver should
+ * set this link status property to "BAD" and prune the mode list based on new
+ * information. The caller then needs to send a hotplug uevent for userspace to
+ *  re-check the valid modes through GET_CONNECTOR_IOCTL and retry modeset.
+ *
+ * Note that a lot of existing userspace do not handle this property.
+ * Drivers can therefore not rely on userspace to fix up everything and
+ * should try to handle issues (like just re-training a link) without
+ * userspace's intervention. This should only be used when the current mode
+ * fails and userspace must select a different display mode.
+ * The DRM driver can chose to not modify property and keep link status
+ * as "GOOD" always to keep the user experience same as it currently is.
+ *
+ * The reason for adding this property is to handle link training failures, but
+ * it is not limited to DP or link training. For example, if we implement
+ * asynchronous setcrtc, this property can be used to report any failures in that.
+ */
+void drm_mode_connector_set_link_status_property(struct drm_connector *connector,
+						 uint64_t link_status)
+{
+	struct drm_device *dev = connector->dev;
+
+	/* Make sure the mutex is grabbed */
+	lockdep_assert_held(&dev->mode_config.mutex);
+	connector->link_status = link_status;
+	drm_object_property_set_value(&connector->base,
+				      dev->mode_config.link_status_property,
+				      link_status);
+}
+EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
+
 int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
 				    struct drm_property *property,
 				    uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ab564e6..f47b345 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct drm_connector *connector,
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
 int drm_mode_connector_update_edid_property(struct drm_connector *connector,
 					    const struct edid *edid);
+void drm_mode_connector_set_link_status_property(struct drm_connector *connector,
+						 uint64_t link_status);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
1.9.1

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

[PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

CRTC state connector_changed needs to be set to true
if connector link status property has changed. This will tell the
driver to do a complete modeset due to change in connector property.

Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tony Cheng <tony.cheng@amd.com>
Cc: dri-devel@lists.freedesktop.org
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/drm_atomic_helper.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 0b16587..2125fd1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
 					       connector_state);
 		if (ret)
 			return ret;
+
+		if (connector->state->crtc) {
+			crtc_state = drm_atomic_get_existing_crtc_state(state,
+									connector->state->crtc);
+			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
+				crtc_state->connectors_changed = true;
+		}
 	}
 
 	/*
-- 
1.9.1

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

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Maarten Lankhorst]

Op 18-11-16 om 08:13 schreef Manasi Navare:
> CRTC state connector_changed needs to be set to true
> if connector link status property has changed. This will tell the
> driver to do a complete modeset due to change in connector property.
>
> Acked-by: Harry Wentland <harry.wentland@amd.com>
> Acked-by: Tony Cheng <tony.cheng@amd.com>
> Cc: dri-devel@lists.freedesktop.org
> 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/drm_atomic_helper.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 0b16587..2125fd1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
>  					       connector_state);
>  		if (ret)
>  			return ret;
> +
> +		if (connector->state->crtc) {
> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> +									connector->state->crtc);
> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> +				crtc_state->connectors_changed = true;
> +		}
>  	}
>  
>  	/*

This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?

~Maarten

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

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Ville Syrjälä]

On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > CRTC state connector_changed needs to be set to true
> > if connector link status property has changed. This will tell the
> > driver to do a complete modeset due to change in connector property.
> >
> > Acked-by: Harry Wentland <harry.wentland@amd.com>
> > Acked-by: Tony Cheng <tony.cheng@amd.com>
> > Cc: dri-devel@lists.freedesktop.org
> > 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/drm_atomic_helper.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index 0b16587..2125fd1 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> >  					       connector_state);
> >  		if (ret)
> >  			return ret;
> > +
> > +		if (connector->state->crtc) {
> > +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > +									connector->state->crtc);
> > +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > +				crtc_state->connectors_changed = true;
> > +		}
> >  	}
> >  
> >  	/*
> 
> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?

Or just check for allow_modeset before setting connectors_changed=true here?

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Maarten Lankhorst]

Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
>> Op 18-11-16 om 08:13 schreef Manasi Navare:
>>> CRTC state connector_changed needs to be set to true
>>> if connector link status property has changed. This will tell the
>>> driver to do a complete modeset due to change in connector property.
>>>
>>> Acked-by: Harry Wentland <harry.wentland@amd.com>
>>> Acked-by: Tony Cheng <tony.cheng@amd.com>
>>> Cc: dri-devel@lists.freedesktop.org
>>> 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/drm_atomic_helper.c | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
>>> index 0b16587..2125fd1 100644
>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
>>>  					       connector_state);
>>>  		if (ret)
>>>  			return ret;
>>> +
>>> +		if (connector->state->crtc) {
>>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
>>> +									connector->state->crtc);
>>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
>>> +				crtc_state->connectors_changed = true;
>>> +		}
>>>  	}
>>>  
>>>  	/*
>> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
>> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
>> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> Or just check for allow_modeset before setting connectors_changed=true here?

I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.

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

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Ville Syrjälä]

On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> >>> CRTC state connector_changed needs to be set to true
> >>> if connector link status property has changed. This will tell the
> >>> driver to do a complete modeset due to change in connector property.
> >>>
> >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> >>> Cc: dri-devel@lists.freedesktop.org
> >>> 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/drm_atomic_helper.c | 7 +++++++
> >>>  1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> >>> index 0b16587..2125fd1 100644
> >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> >>>  					       connector_state);
> >>>  		if (ret)
> >>>  			return ret;
> >>> +
> >>> +		if (connector->state->crtc) {
> >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> >>> +									connector->state->crtc);
> >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> >>> +				crtc_state->connectors_changed = true;
> >>> +		}
> >>>  	}
> >>>  
> >>>  	/*
> >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > Or just check for allow_modeset before setting connectors_changed=true here?
> 
> I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.

Presumably userspace would want a picture on the screen using any means
if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
probably say as much?

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Daniel Vetter]

On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > >>> CRTC state connector_changed needs to be set to true
> > >>> if connector link status property has changed. This will tell the
> > >>> driver to do a complete modeset due to change in connector property.
> > >>>
> > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > >>> Cc: dri-devel@lists.freedesktop.org
> > >>> 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/drm_atomic_helper.c | 7 +++++++
> > >>>  1 file changed, 7 insertions(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > >>> index 0b16587..2125fd1 100644
> > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > >>>  					       connector_state);
> > >>>  		if (ret)
> > >>>  			return ret;
> > >>> +
> > >>> +		if (connector->state->crtc) {
> > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > >>> +									connector->state->crtc);
> > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > >>> +				crtc_state->connectors_changed = true;
> > >>> +		}
> > >>>  	}
> > >>>  
> > >>>  	/*
> > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > Or just check for allow_modeset before setting connectors_changed=true here?
> > 
> > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> 
> Presumably userspace would want a picture on the screen using any means
> if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> probably say as much?

Yeah, agreed. Also, if the link is bad then we pretty much have to do a
modeset to recover it, otherwise you'll be forever stuck with a bad
screen.

What we could try is to gate this of whether userspace touches the mode
property on the corresponding CRTC. I.e. if that's touched (even if it's
the same mode), and a link is bad in one of the connectors in the state
then we do a full modeset to recover.

Another option would be to make the link status writeable. Trying to
change it from bad->good would force the modeset. That would be 100% clear
to userspace, not special hacks needed with checking for allow_modeset,
no magic property that auto-changes its value. And 100% backwards compat
because existing userspace should never touch properties it doesn't
understand (except when restoring a mode, and then it should allow a full
modeset). And if someone does try a good->bad transition, we just silently
keep it at good.

Definitely need to document this properly in the property docs, no matter
what we decide.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Ville Syrjälä]

On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > >>> CRTC state connector_changed needs to be set to true
> > > >>> if connector link status property has changed. This will tell the
> > > >>> driver to do a complete modeset due to change in connector property.
> > > >>>
> > > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > >>> Cc: dri-devel@lists.freedesktop.org
> > > >>> 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/drm_atomic_helper.c | 7 +++++++
> > > >>>  1 file changed, 7 insertions(+)
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> index 0b16587..2125fd1 100644
> > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > > >>>  					       connector_state);
> > > >>>  		if (ret)
> > > >>>  			return ret;
> > > >>> +
> > > >>> +		if (connector->state->crtc) {
> > > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > >>> +									connector->state->crtc);
> > > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > >>> +				crtc_state->connectors_changed = true;
> > > >>> +		}
> > > >>>  	}
> > > >>>  
> > > >>>  	/*
> > > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > > Or just check for allow_modeset before setting connectors_changed=true here?
> > > 
> > > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > 
> > Presumably userspace would want a picture on the screen using any means
> > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > probably say as much?
> 
> Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> modeset to recover it, otherwise you'll be forever stuck with a bad
> screen.
> 
> What we could try is to gate this of whether userspace touches the mode
> property on the corresponding CRTC. I.e. if that's touched (even if it's
> the same mode), and a link is bad in one of the connectors in the state
> then we do a full modeset to recover.
> 
> Another option would be to make the link status writeable. Trying to
> change it from bad->good would force the modeset. That would be 100% clear
> to userspace, not special hacks needed with checking for allow_modeset,
> no magic property that auto-changes its value. And 100% backwards compat
> because existing userspace should never touch properties it doesn't
> understand (except when restoring a mode, and then it should allow a full
> modeset). And if someone does try a good->bad transition, we just silently
> keep it at good.
> 
> Definitely need to document this properly in the property docs, no matter
> what we decide.

Hmm. I think I kinda like this idea of userspace clear the state back
to good explicitly, if it happens with the same prop. So it's like
Maarten's retrain_link prop idea, but without having to add the second
prop to the mix.

It would also save me from pointing out (for the nth time) that the
link status should really be cleared to good during the commit state
swap and not at some random point during the commit ;)

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > >>> CRTC state connector_changed needs to be set to true
> > > > >>> if connector link status property has changed. This will tell the
> > > > >>> driver to do a complete modeset due to change in connector property.
> > > > >>>
> > > > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > > >>> Cc: dri-devel@lists.freedesktop.org
> > > > >>> 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/drm_atomic_helper.c | 7 +++++++
> > > > >>>  1 file changed, 7 insertions(+)
> > > > >>>
> > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > >>> index 0b16587..2125fd1 100644
> > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > >>>  					       connector_state);
> > > > >>>  		if (ret)
> > > > >>>  			return ret;
> > > > >>> +
> > > > >>> +		if (connector->state->crtc) {
> > > > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > >>> +									connector->state->crtc);
> > > > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > > >>> +				crtc_state->connectors_changed = true;
> > > > >>> +		}
> > > > >>>  	}
> > > > >>>  
> > > > >>>  	/*
> > > > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > > > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > > > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > > > Or just check for allow_modeset before setting connectors_changed=true here?
> > > > 
> > > > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > > 
> > > Presumably userspace would want a picture on the screen using any means
> > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > > probably say as much?
> > 
> > Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> > modeset to recover it, otherwise you'll be forever stuck with a bad
> > screen.
> > 
> > What we could try is to gate this of whether userspace touches the mode
> > property on the corresponding CRTC. I.e. if that's touched (even if it's
> > the same mode), and a link is bad in one of the connectors in the state
> > then we do a full modeset to recover.
> > 
> > Another option would be to make the link status writeable. Trying to
> > change it from bad->good would force the modeset. That would be 100% clear
> > to userspace, not special hacks needed with checking for allow_modeset,
> > no magic property that auto-changes its value. And 100% backwards compat
> > because existing userspace should never touch properties it doesn't
> > understand (except when restoring a mode, and then it should allow a full
> > modeset). And if someone does try a good->bad transition, we just silently
> > keep it at good.
> > 
> > Definitely need to document this properly in the property docs, no matter
> > what we decide.
> 
> Hmm. I think I kinda like this idea of userspace clear the state back
> to good explicitly, if it happens with the same prop. So it's like
> Maarten's retrain_link prop idea, but without having to add the second
> prop to the mix.
> 
> It would also save me from pointing out (for the nth time) that the
> link status should really be cleared to good during the commit state
> swap and not at some random point during the commit ;)
>

Okay, so change 1 is to make the userspace clear the state back to Good for the property..
Then Change 2 is to set connector_changed flag in crtc_state to true if this property changed
from BAD to GOOD. I am not quite how and where to change this to state connector_changed to true.
Without this the full modeset will not happen and the whole design of retrianing is lost.

Manasi
> -- 
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Daniel Vetter]

On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > >>> if connector link status property has changed. This will tell the
> > > > > >>> driver to do a complete modeset due to change in connector property.
> > > > > >>>
> > > > > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > > > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > > > >>> Cc: dri-devel@lists.freedesktop.org
> > > > > >>> 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/drm_atomic_helper.c | 7 +++++++
> > > > > >>>  1 file changed, 7 insertions(+)
> > > > > >>>
> > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > >>> index 0b16587..2125fd1 100644
> > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > >>>  					       connector_state);
> > > > > >>>  		if (ret)
> > > > > >>>  			return ret;
> > > > > >>> +
> > > > > >>> +		if (connector->state->crtc) {
> > > > > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > > >>> +									connector->state->crtc);
> > > > > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > > > >>> +				crtc_state->connectors_changed = true;
> > > > > >>> +		}
> > > > > >>>  	}
> > > > > >>>  
> > > > > >>>  	/*
> > > > > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > > > > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > > > > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > > > > Or just check for allow_modeset before setting connectors_changed=true here?
> > > > > 
> > > > > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > > > 
> > > > Presumably userspace would want a picture on the screen using any means
> > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > > > probably say as much?
> > > 
> > > Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > screen.
> > > 
> > > What we could try is to gate this of whether userspace touches the mode
> > > property on the corresponding CRTC. I.e. if that's touched (even if it's
> > > the same mode), and a link is bad in one of the connectors in the state
> > > then we do a full modeset to recover.
> > > 
> > > Another option would be to make the link status writeable. Trying to
> > > change it from bad->good would force the modeset. That would be 100% clear
> > > to userspace, not special hacks needed with checking for allow_modeset,
> > > no magic property that auto-changes its value. And 100% backwards compat
> > > because existing userspace should never touch properties it doesn't
> > > understand (except when restoring a mode, and then it should allow a full
> > > modeset). And if someone does try a good->bad transition, we just silently
> > > keep it at good.
> > > 
> > > Definitely need to document this properly in the property docs, no matter
> > > what we decide.
> > 
> > Hmm. I think I kinda like this idea of userspace clear the state back
> > to good explicitly, if it happens with the same prop. So it's like
> > Maarten's retrain_link prop idea, but without having to add the second
> > prop to the mix.
> > 
> > It would also save me from pointing out (for the nth time) that the
> > link status should really be cleared to good during the commit state
> > swap and not at some random point during the commit ;)
> >
> 
> Okay, so change 1 is to make the userspace clear the state back to Good for the property..
> Then Change 2 is to set connector_changed flag in crtc_state to true if this property changed
> from BAD to GOOD. I am not quite how and where to change this to state connector_changed to true.
> Without this the full modeset will not happen and the whole design of retrianing is lost.

To make this work we need a few more bits:

- link-status needs to become a full-blown atomic property. This means we
  need to move link_status into drm_connector_state, mark the property as
  type ATOMIC and wire up the get/set stuff.

- once that's done it's also pretty easy to set crtc->connectors_changed
  from the atomic helpers. You can just compare old and new link_status in
  drm_connector_state, similar to how we compare old/new CRTC in
  drm_connector_state->crtc already.

- Another fallout is that legacy clients will no longer see the
  link-status property. And they won't be able to set it through the
  SETCRTC ioctl, which would kinda defaut the point. I think the best
  solution would be to check for link_status == BAD in
  drm_atomic_helper_set_config, and reset it to good automatically for
  legacy clients.

This way there's no magic auto-switching properties from an atomic pov
(which is a pet peeve of Ville, and I agree with it), legacy clients still
work, we have a clear model of when link-retrain happens (no magic
behavioural changes depending upon ALLOW_MODESET, making me happy) and DP
compliance should also still work.

So ... everyone happy with the above?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Chris Wilson]

On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > >>> if connector link status property has changed. This will tell the
> > > > > > >>> driver to do a complete modeset due to change in connector property.
> > > > > > >>>
> > > > > > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > > > > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > > > > >>> Cc: dri-devel@lists.freedesktop.org
> > > > > > >>> 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/drm_atomic_helper.c | 7 +++++++
> > > > > > >>>  1 file changed, 7 insertions(+)
> > > > > > >>>
> > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > > >>>  					       connector_state);
> > > > > > >>>  		if (ret)
> > > > > > >>>  			return ret;
> > > > > > >>> +
> > > > > > >>> +		if (connector->state->crtc) {
> > > > > > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > > > >>> +									connector->state->crtc);
> > > > > > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > > > > >>> +				crtc_state->connectors_changed = true;
> > > > > > >>> +		}
> > > > > > >>>  	}
> > > > > > >>>  
> > > > > > >>>  	/*
> > > > > > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > > > > > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > > > > > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > > > > > Or just check for allow_modeset before setting connectors_changed=true here?
> > > > > > 
> > > > > > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > > > > 
> > > > > Presumably userspace would want a picture on the screen using any means
> > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > > > > probably say as much?
> > > > 
> > > > Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> > > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > > screen.
> > > > 
> > > > What we could try is to gate this of whether userspace touches the mode
> > > > property on the corresponding CRTC. I.e. if that's touched (even if it's
> > > > the same mode), and a link is bad in one of the connectors in the state
> > > > then we do a full modeset to recover.
> > > > 
> > > > Another option would be to make the link status writeable. Trying to
> > > > change it from bad->good would force the modeset. That would be 100% clear
> > > > to userspace, not special hacks needed with checking for allow_modeset,
> > > > no magic property that auto-changes its value. And 100% backwards compat
> > > > because existing userspace should never touch properties it doesn't
> > > > understand (except when restoring a mode, and then it should allow a full
> > > > modeset). And if someone does try a good->bad transition, we just silently
> > > > keep it at good.
> > > > 
> > > > Definitely need to document this properly in the property docs, no matter
> > > > what we decide.
> > > 
> > > Hmm. I think I kinda like this idea of userspace clear the state back
> > > to good explicitly, if it happens with the same prop. So it's like
> > > Maarten's retrain_link prop idea, but without having to add the second
> > > prop to the mix.
> > > 
> > > It would also save me from pointing out (for the nth time) that the
> > > link status should really be cleared to good during the commit state
> > > swap and not at some random point during the commit ;)
> > >
> > 
> > Okay, so change 1 is to make the userspace clear the state back to Good for the property..
> > Then Change 2 is to set connector_changed flag in crtc_state to true if this property changed
> > from BAD to GOOD. I am not quite how and where to change this to state connector_changed to true.
> > Without this the full modeset will not happen and the whole design of retrianing is lost.
> 
> To make this work we need a few more bits:
> 
> - link-status needs to become a full-blown atomic property. This means we
>   need to move link_status into drm_connector_state, mark the property as
>   type ATOMIC and wire up the get/set stuff.
> 
> - once that's done it's also pretty easy to set crtc->connectors_changed
>   from the atomic helpers. You can just compare old and new link_status in
>   drm_connector_state, similar to how we compare old/new CRTC in
>   drm_connector_state->crtc already.
> 
> - Another fallout is that legacy clients will no longer see the
>   link-status property. And they won't be able to set it through the
>   SETCRTC ioctl, which would kinda defaut the point. I think the best
>   solution would be to check for link_status == BAD in
>   drm_atomic_helper_set_config, and reset it to good automatically for
>   legacy clients.

Then how do they know that the kernel demands the modeset? Both a legacy
and atomic property?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Daniel Vetter]

On Mon, Nov 21, 2016 at 09:42:57AM +0000, Chris Wilson wrote:
> On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > > >>> if connector link status property has changed. This will tell the
> > > > > > > >>> driver to do a complete modeset due to change in connector property.
> > > > > > > >>>
> > > > > > > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > > > > > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > > > > > >>> Cc: dri-devel@lists.freedesktop.org
> > > > > > > >>> 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/drm_atomic_helper.c | 7 +++++++
> > > > > > > >>>  1 file changed, 7 insertions(+)
> > > > > > > >>>
> > > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > > > >>>  					       connector_state);
> > > > > > > >>>  		if (ret)
> > > > > > > >>>  			return ret;
> > > > > > > >>> +
> > > > > > > >>> +		if (connector->state->crtc) {
> > > > > > > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > > > > >>> +									connector->state->crtc);
> > > > > > > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > > > > > >>> +				crtc_state->connectors_changed = true;
> > > > > > > >>> +		}
> > > > > > > >>>  	}
> > > > > > > >>>  
> > > > > > > >>>  	/*
> > > > > > > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > > > > > > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > > > > > > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > > > > > > Or just check for allow_modeset before setting connectors_changed=true here?
> > > > > > > 
> > > > > > > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > > > > > 
> > > > > > Presumably userspace would want a picture on the screen using any means
> > > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > > > > > probably say as much?
> > > > > 
> > > > > Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> > > > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > > > screen.
> > > > > 
> > > > > What we could try is to gate this of whether userspace touches the mode
> > > > > property on the corresponding CRTC. I.e. if that's touched (even if it's
> > > > > the same mode), and a link is bad in one of the connectors in the state
> > > > > then we do a full modeset to recover.
> > > > > 
> > > > > Another option would be to make the link status writeable. Trying to
> > > > > change it from bad->good would force the modeset. That would be 100% clear
> > > > > to userspace, not special hacks needed with checking for allow_modeset,
> > > > > no magic property that auto-changes its value. And 100% backwards compat
> > > > > because existing userspace should never touch properties it doesn't
> > > > > understand (except when restoring a mode, and then it should allow a full
> > > > > modeset). And if someone does try a good->bad transition, we just silently
> > > > > keep it at good.
> > > > > 
> > > > > Definitely need to document this properly in the property docs, no matter
> > > > > what we decide.
> > > > 
> > > > Hmm. I think I kinda like this idea of userspace clear the state back
> > > > to good explicitly, if it happens with the same prop. So it's like
> > > > Maarten's retrain_link prop idea, but without having to add the second
> > > > prop to the mix.
> > > > 
> > > > It would also save me from pointing out (for the nth time) that the
> > > > link status should really be cleared to good during the commit state
> > > > swap and not at some random point during the commit ;)
> > > >
> > > 
> > > Okay, so change 1 is to make the userspace clear the state back to Good for the property..
> > > Then Change 2 is to set connector_changed flag in crtc_state to true if this property changed
> > > from BAD to GOOD. I am not quite how and where to change this to state connector_changed to true.
> > > Without this the full modeset will not happen and the whole design of retrianing is lost.
> > 
> > To make this work we need a few more bits:
> > 
> > - link-status needs to become a full-blown atomic property. This means we
> >   need to move link_status into drm_connector_state, mark the property as
> >   type ATOMIC and wire up the get/set stuff.
> > 
> > - once that's done it's also pretty easy to set crtc->connectors_changed
> >   from the atomic helpers. You can just compare old and new link_status in
> >   drm_connector_state, similar to how we compare old/new CRTC in
> >   drm_connector_state->crtc already.
> > 
> > - Another fallout is that legacy clients will no longer see the
> >   link-status property. And they won't be able to set it through the
> >   SETCRTC ioctl, which would kinda defaut the point. I think the best
> >   solution would be to check for link_status == BAD in
> >   drm_atomic_helper_set_config, and reset it to good automatically for
> >   legacy clients.
> 
> Then how do they know that the kernel demands the modeset? Both a legacy
> and atomic property?

I guess we could avoid the filtering of the property for legacy clients.
Definitely not 2 properties, that's silly. Or we teach userspace to go
look for atomic properties.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Daniel Vetter]

On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> On Mon, Nov 21, 2016 at 09:42:57AM +0000, Chris Wilson wrote:
> > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > > > >>> if connector link status property has changed. This will tell the
> > > > > > > > >>> driver to do a complete modeset due to change in connector property.
> > > > > > > > >>>
> > > > > > > > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > > > > > > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > > > > > > >>> Cc: dri-devel@lists.freedesktop.org
> > > > > > > > >>> 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/drm_atomic_helper.c | 7 +++++++
> > > > > > > > >>>  1 file changed, 7 insertions(+)
> > > > > > > > >>>
> > > > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > > > > >>>  					       connector_state);
> > > > > > > > >>>  		if (ret)
> > > > > > > > >>>  			return ret;
> > > > > > > > >>> +
> > > > > > > > >>> +		if (connector->state->crtc) {
> > > > > > > > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > > > > > >>> +									connector->state->crtc);
> > > > > > > > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > > > > > > >>> +				crtc_state->connectors_changed = true;
> > > > > > > > >>> +		}
> > > > > > > > >>>  	}
> > > > > > > > >>>  
> > > > > > > > >>>  	/*
> > > > > > > > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > > > > > > > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > > > > > > > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > > > > > > > Or just check for allow_modeset before setting connectors_changed=true here?
> > > > > > > > 
> > > > > > > > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > > > > > > 
> > > > > > > Presumably userspace would want a picture on the screen using any means
> > > > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > > > > > > probably say as much?
> > > > > > 
> > > > > > Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> > > > > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > > > > screen.
> > > > > > 
> > > > > > What we could try is to gate this of whether userspace touches the mode
> > > > > > property on the corresponding CRTC. I.e. if that's touched (even if it's
> > > > > > the same mode), and a link is bad in one of the connectors in the state
> > > > > > then we do a full modeset to recover.
> > > > > > 
> > > > > > Another option would be to make the link status writeable. Trying to
> > > > > > change it from bad->good would force the modeset. That would be 100% clear
> > > > > > to userspace, not special hacks needed with checking for allow_modeset,
> > > > > > no magic property that auto-changes its value. And 100% backwards compat
> > > > > > because existing userspace should never touch properties it doesn't
> > > > > > understand (except when restoring a mode, and then it should allow a full
> > > > > > modeset). And if someone does try a good->bad transition, we just silently
> > > > > > keep it at good.
> > > > > > 
> > > > > > Definitely need to document this properly in the property docs, no matter
> > > > > > what we decide.
> > > > > 
> > > > > Hmm. I think I kinda like this idea of userspace clear the state back
> > > > > to good explicitly, if it happens with the same prop. So it's like
> > > > > Maarten's retrain_link prop idea, but without having to add the second
> > > > > prop to the mix.
> > > > > 
> > > > > It would also save me from pointing out (for the nth time) that the
> > > > > link status should really be cleared to good during the commit state
> > > > > swap and not at some random point during the commit ;)
> > > > >
> > > > 
> > > > Okay, so change 1 is to make the userspace clear the state back to Good for the property..
> > > > Then Change 2 is to set connector_changed flag in crtc_state to true if this property changed
> > > > from BAD to GOOD. I am not quite how and where to change this to state connector_changed to true.
> > > > Without this the full modeset will not happen and the whole design of retrianing is lost.
> > > 
> > > To make this work we need a few more bits:
> > > 
> > > - link-status needs to become a full-blown atomic property. This means we
> > >   need to move link_status into drm_connector_state, mark the property as
> > >   type ATOMIC and wire up the get/set stuff.
> > > 
> > > - once that's done it's also pretty easy to set crtc->connectors_changed
> > >   from the atomic helpers. You can just compare old and new link_status in
> > >   drm_connector_state, similar to how we compare old/new CRTC in
> > >   drm_connector_state->crtc already.
> > > 
> > > - Another fallout is that legacy clients will no longer see the
> > >   link-status property. And they won't be able to set it through the
> > >   SETCRTC ioctl, which would kinda defaut the point. I think the best
> > >   solution would be to check for link_status == BAD in
> > >   drm_atomic_helper_set_config, and reset it to good automatically for
> > >   legacy clients.
> > 
> > Then how do they know that the kernel demands the modeset? Both a legacy
> > and atomic property?
> 
> I guess we could avoid the filtering of the property for legacy clients.
> Definitely not 2 properties, that's silly. Or we teach userspace to go
> look for atomic properties.

Well, now that I flushed the gunk out of my brain with some work-out it's
a lot easier: ATOMIC on properties is only to hide them from legacy
userspace, it doesn't control how it's implement. Which means we can
implement it as described above, and non-atomic userspace can still read
it. Setting would also work, but since we want to do that as part of
SETCRTC anyway, and since legacy SETCRTC doesn't specifiy whether a
modeset will happen or not, automagic in there seems reasonable.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 09:42:57AM +0000, Chris Wilson wrote:
> > > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > > > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > > > > >>> if connector link status property has changed. This will tell the
> > > > > > > > > >>> driver to do a complete modeset due to change in connector property.
> > > > > > > > > >>>
> > > > > > > > > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > > > > > > > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > > > > > > > >>> Cc: dri-devel@lists.freedesktop.org
> > > > > > > > > >>> 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/drm_atomic_helper.c | 7 +++++++
> > > > > > > > > >>>  1 file changed, 7 insertions(+)
> > > > > > > > > >>>
> > > > > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > > > > > >>>  					       connector_state);
> > > > > > > > > >>>  		if (ret)
> > > > > > > > > >>>  			return ret;
> > > > > > > > > >>> +
> > > > > > > > > >>> +		if (connector->state->crtc) {
> > > > > > > > > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > > > > > > >>> +									connector->state->crtc);
> > > > > > > > > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > > > > > > > >>> +				crtc_state->connectors_changed = true;
> > > > > > > > > >>> +		}
> > > > > > > > > >>>  	}
> > > > > > > > > >>>  
> > > > > > > > > >>>  	/*
> > > > > > > > > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > > > > > > > > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > > > > > > > > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > > > > > > > > Or just check for allow_modeset before setting connectors_changed=true here?
> > > > > > > > > 
> > > > > > > > > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > > > > > > > 
> > > > > > > > Presumably userspace would want a picture on the screen using any means
> > > > > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > > > > > > > probably say as much?
> > > > > > > 
> > > > > > > Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> > > > > > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > > > > > screen.
> > > > > > > 
> > > > > > > What we could try is to gate this of whether userspace touches the mode
> > > > > > > property on the corresponding CRTC. I.e. if that's touched (even if it's
> > > > > > > the same mode), and a link is bad in one of the connectors in the state
> > > > > > > then we do a full modeset to recover.
> > > > > > > 
> > > > > > > Another option would be to make the link status writeable. Trying to
> > > > > > > change it from bad->good would force the modeset. That would be 100% clear
> > > > > > > to userspace, not special hacks needed with checking for allow_modeset,
> > > > > > > no magic property that auto-changes its value. And 100% backwards compat
> > > > > > > because existing userspace should never touch properties it doesn't
> > > > > > > understand (except when restoring a mode, and then it should allow a full
> > > > > > > modeset). And if someone does try a good->bad transition, we just silently
> > > > > > > keep it at good.
> > > > > > > 
> > > > > > > Definitely need to document this properly in the property docs, no matter
> > > > > > > what we decide.
> > > > > > 
> > > > > > Hmm. I think I kinda like this idea of userspace clear the state back
> > > > > > to good explicitly, if it happens with the same prop. So it's like
> > > > > > Maarten's retrain_link prop idea, but without having to add the second
> > > > > > prop to the mix.
> > > > > > 
> > > > > > It would also save me from pointing out (for the nth time) that the
> > > > > > link status should really be cleared to good during the commit state
> > > > > > swap and not at some random point during the commit ;)
> > > > > >
> > > > > 
> > > > > Okay, so change 1 is to make the userspace clear the state back to Good for the property..
> > > > > Then Change 2 is to set connector_changed flag in crtc_state to true if this property changed
> > > > > from BAD to GOOD. I am not quite how and where to change this to state connector_changed to true.
> > > > > Without this the full modeset will not happen and the whole design of retrianing is lost.
> > > > 
> > > > To make this work we need a few more bits:
> > > > 
> > > > - link-status needs to become a full-blown atomic property. This means we
> > > >   need to move link_status into drm_connector_state, mark the property as
> > > >   type ATOMIC and wire up the get/set stuff.
> > > > 
> > > > - once that's done it's also pretty easy to set crtc->connectors_changed
> > > >   from the atomic helpers. You can just compare old and new link_status in
> > > >   drm_connector_state, similar to how we compare old/new CRTC in
> > > >   drm_connector_state->crtc already.
> > > > 
> > > > - Another fallout is that legacy clients will no longer see the
> > > >   link-status property. And they won't be able to set it through the
> > > >   SETCRTC ioctl, which would kinda defaut the point. I think the best
> > > >   solution would be to check for link_status == BAD in
> > > >   drm_atomic_helper_set_config, and reset it to good automatically for
> > > >   legacy clients.
> > > 
> > > Then how do they know that the kernel demands the modeset? Both a legacy
> > > and atomic property?
> > 
> > I guess we could avoid the filtering of the property for legacy clients.
> > Definitely not 2 properties, that's silly. Or we teach userspace to go
> > look for atomic properties.
> 
> Well, now that I flushed the gunk out of my brain with some work-out it's
> a lot easier: ATOMIC on properties is only to hide them from legacy
> userspace, it doesn't control how it's implement. Which means we can
> implement it as described above, and non-atomic userspace can still read
> it. Setting would also work, but since we want to do that as part of
> SETCRTC anyway, and since legacy SETCRTC doesn't specifiy whether a
> modeset will happen or not, automagic in there seems reasonable.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Thanks Daniel for providing the solution alternatives here.
So after we make it atomic, we would solve the problem of updating the connector_changed
in atomic_helper_check_modeset function. So in this, who resets the property to GOOD?
Would this happen in drm_atomic_helper_set_config in both atomic and non atomic cases?

And in case of non atomic userspace, will it still be able to read link-status as BAD in userspace
to decide whether it needs to call setcrtc?

Chris, will any implementation in your patch for link _status change if this is made atomic?

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

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Chris Wilson]

On Mon, Nov 21, 2016 at 11:00:52AM -0800, Manasi Navare wrote:
> On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 21, 2016 at 09:42:57AM +0000, Chris Wilson wrote:
> > > > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > > > - Another fallout is that legacy clients will no longer see the
> > > > >   link-status property. And they won't be able to set it through the
> > > > >   SETCRTC ioctl, which would kinda defaut the point. I think the best
> > > > >   solution would be to check for link_status == BAD in
> > > > >   drm_atomic_helper_set_config, and reset it to good automatically for
> > > > >   legacy clients.
> > > > 
> > > > Then how do they know that the kernel demands the modeset? Both a legacy
> > > > and atomic property?
> > > 
> > > I guess we could avoid the filtering of the property for legacy clients.
> > > Definitely not 2 properties, that's silly. Or we teach userspace to go
> > > look for atomic properties.
> > 
> > Well, now that I flushed the gunk out of my brain with some work-out it's
> > a lot easier: ATOMIC on properties is only to hide them from legacy
> > userspace, it doesn't control how it's implement. Which means we can
> > implement it as described above, and non-atomic userspace can still read
> > it. Setting would also work, but since we want to do that as part of
> > SETCRTC anyway, and since legacy SETCRTC doesn't specifiy whether a
> > modeset will happen or not, automagic in there seems reasonable.
> 
> Thanks Daniel for providing the solution alternatives here.
> So after we make it atomic, we would solve the problem of updating the connector_changed
> in atomic_helper_check_modeset function. So in this, who resets the property to GOOD?
> Would this happen in drm_atomic_helper_set_config in both atomic and non atomic cases?
> 
> And in case of non atomic userspace, will it still be able to read link-status as BAD in userspace
> to decide whether it needs to call setcrtc?
> 
> Chris, will any implementation in your patch for link _status change if this is made atomic?

So long at the property remains visible via the GETCONNECTOR ioctl, no.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

On Mon, Nov 21, 2016 at 08:46:19PM +0000, Chris Wilson wrote:
> On Mon, Nov 21, 2016 at 11:00:52AM -0800, Manasi Navare wrote:
> > On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > > > On Mon, Nov 21, 2016 at 09:42:57AM +0000, Chris Wilson wrote:
> > > > > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > > > > - Another fallout is that legacy clients will no longer see the
> > > > > >   link-status property. And they won't be able to set it through the
> > > > > >   SETCRTC ioctl, which would kinda defaut the point. I think the best
> > > > > >   solution would be to check for link_status == BAD in
> > > > > >   drm_atomic_helper_set_config, and reset it to good automatically for
> > > > > >   legacy clients.
> > > > > 
> > > > > Then how do they know that the kernel demands the modeset? Both a legacy
> > > > > and atomic property?
> > > > 
> > > > I guess we could avoid the filtering of the property for legacy clients.
> > > > Definitely not 2 properties, that's silly. Or we teach userspace to go
> > > > look for atomic properties.
> > > 
> > > Well, now that I flushed the gunk out of my brain with some work-out it's
> > > a lot easier: ATOMIC on properties is only to hide them from legacy
> > > userspace, it doesn't control how it's implement. Which means we can
> > > implement it as described above, and non-atomic userspace can still read
> > > it. Setting would also work, but since we want to do that as part of
> > > SETCRTC anyway, and since legacy SETCRTC doesn't specifiy whether a
> > > modeset will happen or not, automagic in there seems reasonable.
> > 
> > Thanks Daniel for providing the solution alternatives here.
> > So after we make it atomic, we would solve the problem of updating the connector_changed
> > in atomic_helper_check_modeset function. So in this, who resets the property to GOOD?
> > Would this happen in drm_atomic_helper_set_config in both atomic and non atomic cases?
> > 
> > And in case of non atomic userspace, will it still be able to read link-status as BAD in userspace
> > to decide whether it needs to call setcrtc?
> > 
> > Chris, will any implementation in your patch for link _status change if this is made atomic?
> 
> So long at the property remains visible via the GETCONNECTOR ioctl, no.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

If it is made an atomic property, will it be visible to userspace through
GETCONNECTOR?

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

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 09:42:57AM +0000, Chris Wilson wrote:
> > > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > > > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > > > > >>> if connector link status property has changed. This will tell the
> > > > > > > > > >>> driver to do a complete modeset due to change in connector property.
> > > > > > > > > >>>
> > > > > > > > > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > > > > > > > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > > > > > > > >>> Cc: dri-devel@lists.freedesktop.org
> > > > > > > > > >>> 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/drm_atomic_helper.c | 7 +++++++
> > > > > > > > > >>>  1 file changed, 7 insertions(+)
> > > > > > > > > >>>
> > > > > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > > > > > >>>  					       connector_state);
> > > > > > > > > >>>  		if (ret)
> > > > > > > > > >>>  			return ret;
> > > > > > > > > >>> +
> > > > > > > > > >>> +		if (connector->state->crtc) {
> > > > > > > > > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > > > > > > >>> +									connector->state->crtc);
> > > > > > > > > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > > > > > > > >>> +				crtc_state->connectors_changed = true;
> > > > > > > > > >>> +		}
> > > > > > > > > >>>  	}
> > > > > > > > > >>>  
> > > > > > > > > >>>  	/*
> > > > > > > > > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > > > > > > > > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > > > > > > > > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > > > > > > > > Or just check for allow_modeset before setting connectors_changed=true here?
> > > > > > > > > 
> > > > > > > > > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > > > > > > > 
> > > > > > > > Presumably userspace would want a picture on the screen using any means
> > > > > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > > > > > > > probably say as much?
> > > > > > > 
> > > > > > > Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> > > > > > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > > > > > screen.
> > > > > > > 
> > > > > > > What we could try is to gate this of whether userspace touches the mode
> > > > > > > property on the corresponding CRTC. I.e. if that's touched (even if it's
> > > > > > > the same mode), and a link is bad in one of the connectors in the state
> > > > > > > then we do a full modeset to recover.
> > > > > > > 
> > > > > > > Another option would be to make the link status writeable. Trying to
> > > > > > > change it from bad->good would force the modeset. That would be 100% clear
> > > > > > > to userspace, not special hacks needed with checking for allow_modeset,
> > > > > > > no magic property that auto-changes its value. And 100% backwards compat
> > > > > > > because existing userspace should never touch properties it doesn't
> > > > > > > understand (except when restoring a mode, and then it should allow a full
> > > > > > > modeset). And if someone does try a good->bad transition, we just silently
> > > > > > > keep it at good.
> > > > > > > 
> > > > > > > Definitely need to document this properly in the property docs, no matter
> > > > > > > what we decide.
> > > > > > 
> > > > > > Hmm. I think I kinda like this idea of userspace clear the state back
> > > > > > to good explicitly, if it happens with the same prop. So it's like
> > > > > > Maarten's retrain_link prop idea, but without having to add the second
> > > > > > prop to the mix.
> > > > > > 
> > > > > > It would also save me from pointing out (for the nth time) that the
> > > > > > link status should really be cleared to good during the commit state
> > > > > > swap and not at some random point during the commit ;)
> > > > > >
> > > > > 
> > > > > Okay, so change 1 is to make the userspace clear the state back to Good for the property..
> > > > > Then Change 2 is to set connector_changed flag in crtc_state to true if this property changed
> > > > > from BAD to GOOD. I am not quite how and where to change this to state connector_changed to true.
> > > > > Without this the full modeset will not happen and the whole design of retrianing is lost.
> > > > 
> > > > To make this work we need a few more bits:
> > > > 
> > > > - link-status needs to become a full-blown atomic property. This means we
> > > >   need to move link_status into drm_connector_state, mark the property as
> > > >   type ATOMIC and wire up the get/set stuff.
> > > > 
> > > > - once that's done it's also pretty easy to set crtc->connectors_changed
> > > >   from the atomic helpers. You can just compare old and new link_status in
> > > >   drm_connector_state, similar to how we compare old/new CRTC in
> > > >   drm_connector_state->crtc already.
> > > > 
> > > > - Another fallout is that legacy clients will no longer see the
> > > >   link-status property. And they won't be able to set it through the
> > > >   SETCRTC ioctl, which would kinda defaut the point. I think the best
> > > >   solution would be to check for link_status == BAD in
> > > >   drm_atomic_helper_set_config, and reset it to good automatically for
> > > >   legacy clients.
> > > 
> > > Then how do they know that the kernel demands the modeset? Both a legacy
> > > and atomic property?
> > 
> > I guess we could avoid the filtering of the property for legacy clients.
> > Definitely not 2 properties, that's silly. Or we teach userspace to go
> > look for atomic properties.
> 
> Well, now that I flushed the gunk out of my brain with some work-out it's
> a lot easier: ATOMIC on properties is only to hide them from legacy
> userspace, it doesn't control how it's implement. Which means we can
> implement it as described above, and non-atomic userspace can still read
> it. Setting would also work, but since we want to do that as part of
> SETCRTC anyway, and since legacy SETCRTC doesn't specifiy whether a
> modeset will happen or not, automagic in there seems reasonable.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Daniel,
I read through the atomic property functions and how those are wired, I just
have a few questions:

-  So to make this link-status property atomic, it would still be declared as
   a drm_property inside mode_config struct right?
-  Then in drm_connector_create_standard_properties(), when this gets created,
   it will be created with a flag DRM_MODE_PROP_ATOMIC?
-  It should still get attached in drm_connector_init right?
-  And we will still need the drm_mode_connector_set_link_status_property() function..?
-  I have wired it in drm_atomic_connector_set_property/get_property() functions? Is that
   all thats needed?

I will submit RFC patches for these above changes for you to look at.

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

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Daniel Vetter]

On Tue, Nov 22, 2016 at 05:15:59PM -0800, Manasi Navare wrote:
> On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 21, 2016 at 09:42:57AM +0000, Chris Wilson wrote:
> > > > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > > > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > > > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > > > > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > > > > > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > > > > > > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > > > > > > > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > > > > > > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > > > > > > > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > > > > > > > > >>> CRTC state connector_changed needs to be set to true
> > > > > > > > > > >>> if connector link status property has changed. This will tell the
> > > > > > > > > > >>> driver to do a complete modeset due to change in connector property.
> > > > > > > > > > >>>
> > > > > > > > > > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > > > > > > > > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > > > > > > > > >>> Cc: dri-devel@lists.freedesktop.org
> > > > > > > > > > >>> 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/drm_atomic_helper.c | 7 +++++++
> > > > > > > > > > >>>  1 file changed, 7 insertions(+)
> > > > > > > > > > >>>
> > > > > > > > > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > > >>> index 0b16587..2125fd1 100644
> > > > > > > > > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > > > > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > > > > > > > > > >>>  					       connector_state);
> > > > > > > > > > >>>  		if (ret)
> > > > > > > > > > >>>  			return ret;
> > > > > > > > > > >>> +
> > > > > > > > > > >>> +		if (connector->state->crtc) {
> > > > > > > > > > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > > > > > > > >>> +									connector->state->crtc);
> > > > > > > > > > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > > > > > > > > >>> +				crtc_state->connectors_changed = true;
> > > > > > > > > > >>> +		}
> > > > > > > > > > >>>  	}
> > > > > > > > > > >>>  
> > > > > > > > > > >>>  	/*
> > > > > > > > > > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > > > > > > > > > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > > > > > > > > > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > > > > > > > > > Or just check for allow_modeset before setting connectors_changed=true here?
> > > > > > > > > > 
> > > > > > > > > > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > > > > > > > > 
> > > > > > > > > Presumably userspace would want a picture on the screen using any means
> > > > > > > > > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > > > > > > > > probably say as much?
> > > > > > > > 
> > > > > > > > Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> > > > > > > > modeset to recover it, otherwise you'll be forever stuck with a bad
> > > > > > > > screen.
> > > > > > > > 
> > > > > > > > What we could try is to gate this of whether userspace touches the mode
> > > > > > > > property on the corresponding CRTC. I.e. if that's touched (even if it's
> > > > > > > > the same mode), and a link is bad in one of the connectors in the state
> > > > > > > > then we do a full modeset to recover.
> > > > > > > > 
> > > > > > > > Another option would be to make the link status writeable. Trying to
> > > > > > > > change it from bad->good would force the modeset. That would be 100% clear
> > > > > > > > to userspace, not special hacks needed with checking for allow_modeset,
> > > > > > > > no magic property that auto-changes its value. And 100% backwards compat
> > > > > > > > because existing userspace should never touch properties it doesn't
> > > > > > > > understand (except when restoring a mode, and then it should allow a full
> > > > > > > > modeset). And if someone does try a good->bad transition, we just silently
> > > > > > > > keep it at good.
> > > > > > > > 
> > > > > > > > Definitely need to document this properly in the property docs, no matter
> > > > > > > > what we decide.
> > > > > > > 
> > > > > > > Hmm. I think I kinda like this idea of userspace clear the state back
> > > > > > > to good explicitly, if it happens with the same prop. So it's like
> > > > > > > Maarten's retrain_link prop idea, but without having to add the second
> > > > > > > prop to the mix.
> > > > > > > 
> > > > > > > It would also save me from pointing out (for the nth time) that the
> > > > > > > link status should really be cleared to good during the commit state
> > > > > > > swap and not at some random point during the commit ;)
> > > > > > >
> > > > > > 
> > > > > > Okay, so change 1 is to make the userspace clear the state back to Good for the property..
> > > > > > Then Change 2 is to set connector_changed flag in crtc_state to true if this property changed
> > > > > > from BAD to GOOD. I am not quite how and where to change this to state connector_changed to true.
> > > > > > Without this the full modeset will not happen and the whole design of retrianing is lost.
> > > > > 
> > > > > To make this work we need a few more bits:
> > > > > 
> > > > > - link-status needs to become a full-blown atomic property. This means we
> > > > >   need to move link_status into drm_connector_state, mark the property as
> > > > >   type ATOMIC and wire up the get/set stuff.
> > > > > 
> > > > > - once that's done it's also pretty easy to set crtc->connectors_changed
> > > > >   from the atomic helpers. You can just compare old and new link_status in
> > > > >   drm_connector_state, similar to how we compare old/new CRTC in
> > > > >   drm_connector_state->crtc already.
> > > > > 
> > > > > - Another fallout is that legacy clients will no longer see the
> > > > >   link-status property. And they won't be able to set it through the
> > > > >   SETCRTC ioctl, which would kinda defaut the point. I think the best
> > > > >   solution would be to check for link_status == BAD in
> > > > >   drm_atomic_helper_set_config, and reset it to good automatically for
> > > > >   legacy clients.
> > > > 
> > > > Then how do they know that the kernel demands the modeset? Both a legacy
> > > > and atomic property?
> > > 
> > > I guess we could avoid the filtering of the property for legacy clients.
> > > Definitely not 2 properties, that's silly. Or we teach userspace to go
> > > look for atomic properties.
> > 
> > Well, now that I flushed the gunk out of my brain with some work-out it's
> > a lot easier: ATOMIC on properties is only to hide them from legacy
> > userspace, it doesn't control how it's implement. Which means we can
> > implement it as described above, and non-atomic userspace can still read
> > it. Setting would also work, but since we want to do that as part of
> > SETCRTC anyway, and since legacy SETCRTC doesn't specifiy whether a
> > modeset will happen or not, automagic in there seems reasonable.
> > -Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> Daniel,
> I read through the atomic property functions and how those are wired, I just
> have a few questions:
> 
> -  So to make this link-status property atomic, it would still be declared as
>    a drm_property inside mode_config struct right?

Yes. Atomic is about how the property is set/read, not how it's set up.

> -  Then in drm_connector_create_standard_properties(), when this gets created,
>    it will be created with a flag DRM_MODE_PROP_ATOMIC?

No, that was just me being confused. DRM_MODE_PROP_ATOMIC only hides a
property from old/legacy userspace, it doesn't really have an influence on
how it's internally embedded. Since we want legacy/non-atomic userspace to
be able to read the link_status property using GETCONNECTOR, we do not set
the PROP_ATOMIC flag.

> -  It should still get attached in drm_connector_init right?

Yes, that's unchanged.

> -  And we will still need the drm_mode_connector_set_link_status_property() function..?

Yes, I think that's still useful. The implementation will be a bit more
tricky though, since updating an atomic property needs different locks:
1) you need to grab drm_dev->mode_config.connection_mutex.
2) Usually properties are updated by first duplicating the existing
drm_connector_state, then changing it, and then committing it. But since
link-status going from good->bad is something that already happened, and
not something we need to commit, just updating
drm_connector->state->link_status should be fine. Protected with the lock
from 1) of course.

> -  I have wired it in drm_atomic_connector_set_property/get_property() functions? Is that
>    all thats needed?

Yup, that should be all that's needed.

> I will submit RFC patches for these above changes for you to look at.

Do they still work with the compliance tool and the sna patches? You
didn't have any questions about it, so I guess you did wire up the
explicit bad->good change in drm_atomic_helper_set_config?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 18, 2016 at 03:18:06PM +0100, Maarten Lankhorst wrote:
> > > Op 18-11-16 om 15:11 schreef Ville Syrjälä:
> > > > On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > > >> Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > >>> CRTC state connector_changed needs to be set to true
> > > >>> if connector link status property has changed. This will tell the
> > > >>> driver to do a complete modeset due to change in connector property.
> > > >>>
> > > >>> Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > >>> Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > >>> Cc: dri-devel@lists.freedesktop.org
> > > >>> 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/drm_atomic_helper.c | 7 +++++++
> > > >>>  1 file changed, 7 insertions(+)
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> index 0b16587..2125fd1 100644
> > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > > >>>  					       connector_state);
> > > >>>  		if (ret)
> > > >>>  			return ret;
> > > >>> +
> > > >>> +		if (connector->state->crtc) {
> > > >>> +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > >>> +									connector->state->crtc);
> > > >>> +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > >>> +				crtc_state->connectors_changed = true;
> > > >>> +		}
> > > >>>  	}
> > > >>>  
> > > >>>  	/*
> > > >> This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > > >> For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > > >> always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> > > > Or just check for allow_modeset before setting connectors_changed=true here?
> > > 
> > > I don't think modesets should be done automatically like that, even if ALLOW_MODESET is set a modeset may not be expected by userspace.
> > 
> > Presumably userspace would want a picture on the screen using any means
> > if it said ALLOW_MODESET. So if it can't tolerate the modeset it should
> > probably say as much?
> 
> Yeah, agreed. Also, if the link is bad then we pretty much have to do a
> modeset to recover it, otherwise you'll be forever stuck with a bad
> screen.
> 
> What we could try is to gate this of whether userspace touches the mode
> property on the corresponding CRTC. I.e. if that's touched (even if it's
> the same mode), and a link is bad in one of the connectors in the state
> then we do a full modeset to recover.
> 
> Another option would be to make the link status writeable. Trying to
> change it from bad->good would force the modeset. That would be 100% clear
> to userspace, not special hacks needed with checking for allow_modeset,
> no magic property that auto-changes its value. And 100% backwards compat
> because existing userspace should never touch properties it doesn't
> understand (except when restoring a mode, and then it should allow a full
> modeset). And if someone does try a good->bad transition, we just silently
> keep it at good.
> 
> Definitely need to document this properly in the property docs, no matter
> what we decide.
> -Daniel
> --

Daniel, but this isnt solving the problem of drm_atomic_helper_check_modeset() 
actually gating this modeset requested by userspace. This function checks for the
connector->state in each crtc and sees if connector_changed and only if it is then it will
set needs_modeset flag and do a full modeset.
How should I solve this problem?
I am not familiar with the state magic and so I am asking for helo here since I am completely
clueless as to how to propogate this link-status property change to this helper function and
somehow indicate in the connector state that it changed so driver will do a full modeset.
Even if I add a new connector->state variable like link_status_changed, where can this be set?

Manasi

 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

On Fri, Nov 18, 2016 at 04:11:47PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 18, 2016 at 02:50:52PM +0100, Maarten Lankhorst wrote:
> > Op 18-11-16 om 08:13 schreef Manasi Navare:
> > > CRTC state connector_changed needs to be set to true
> > > if connector link status property has changed. This will tell the
> > > driver to do a complete modeset due to change in connector property.
> > >
> > > Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > Cc: dri-devel@lists.freedesktop.org
> > > 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/drm_atomic_helper.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 0b16587..2125fd1 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
> > >  					       connector_state);
> > >  		if (ret)
> > >  			return ret;
> > > +
> > > +		if (connector->state->crtc) {
> > > +			crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > +									connector->state->crtc);
> > > +			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > > +				crtc_state->connectors_changed = true;
> > > +		}
> > >  	}
> > >  
> > >  	/*
> > 
> > This will cause ordinary atomic commits that happen to change connector flags to potentially fail with -EINVAL if ALLOW_MODESET is not set.
> > For this reason I'm not sure this flag should be set automatically by the kernel. Could we add add a retrain link property instead, that
> > always return 0 when queried, but writing a 1 causing connectors_changed to be set on bad link status?
> 
> Or just check for allow_modeset before setting connectors_changed=true here?
> 
> -- 
> Ville Syrjälä
> Intel OTC

Yes I think thats a better solution, I can check ALLOW_MODESET set and only then poke the link_status and change the connectors_changed flag.
I am already checking this only if connector->state->crtc, so I thought that should avoid other atomoic commits to get into this check. But I guess
I will have to check for ALLOW MODESET as well. That should fix it.

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

[PATCH 4/5] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.

v3:
* Remove fallback_link_rate_index variable, just obtain
that using the helper intel_dp_link_rate_index (Jani Nikula)
v2:
Squash the patch that returns the link rate index (Jani Nikula)

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 90283ed..4fb89e1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,46 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
 			       common_rates);
 }
 
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+				    int *common_rates, int link_rate)
+{
+	int common_len;
+	int index;
+
+	common_len = intel_dp_common_rates(intel_dp, common_rates);
+	for (index = 0; index < common_len; index++) {
+		if (link_rate == common_rates[common_len - index - 1])
+			return common_len - index - 1;
+	}
+
+	return -1;
+}
+
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+					    int link_rate, uint8_t lane_count)
+{
+	int common_rates[DP_MAX_SUPPORTED_RATES] = {};
+	int common_len;
+	int link_rate_index = -1;
+
+	common_len = intel_dp_common_rates(intel_dp, common_rates);
+	link_rate_index = intel_dp_link_rate_index(intel_dp,
+						   common_rates,
+						   link_rate);
+	if (link_rate_index > 0) {
+		intel_dp->fallback_link_rate = common_rates[link_rate_index - 1];
+		intel_dp->fallback_lane_count = intel_dp_max_lane_count(intel_dp);
+	} else if (lane_count > 1) {
+		intel_dp->fallback_link_rate = common_rates[common_len - 1];
+		intel_dp->fallback_lane_count = lane_count >> 1;
+	} else {
+		DRM_ERROR("Link Training Unsuccessful\n");
+		return -1;
+	}
+
+	return 0;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
 		    struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cd132c2..3f6b4c9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -887,6 +887,9 @@ struct intel_dp {
 	uint32_t DP;
 	int link_rate;
 	uint8_t lane_count;
+	int fallback_link_rate;
+	uint8_t fallback_lane_count;
+	bool link_train_failed;
 	uint8_t sink_count;
 	bool link_mst;
 	bool has_audio;
@@ -1383,6 +1386,8 @@ bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
 			      int link_rate, uint8_t lane_count,
 			      bool link_mst);
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+					    int link_rate, uint8_t lane_count);
 void intel_dp_start_link_train(struct intel_dp *intel_dp);
 void intel_dp_stop_link_train(struct intel_dp *intel_dp);
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
-- 
1.9.1

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

[PATCH 4/5] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.

v4:
* Remove the redundant variable link_train_failed
v3:
* Remove fallback_link_rate_index variable, just obtain
that using the helper intel_dp_link_rate_index (Jani Nikula)
v2:
Squash the patch that returns the link rate index (Jani Nikula)

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 90283ed..4fb89e1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,46 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
 			       common_rates);
 }
 
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+				    int *common_rates, int link_rate)
+{
+	int common_len;
+	int index;
+
+	common_len = intel_dp_common_rates(intel_dp, common_rates);
+	for (index = 0; index < common_len; index++) {
+		if (link_rate == common_rates[common_len - index - 1])
+			return common_len - index - 1;
+	}
+
+	return -1;
+}
+
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+					    int link_rate, uint8_t lane_count)
+{
+	int common_rates[DP_MAX_SUPPORTED_RATES] = {};
+	int common_len;
+	int link_rate_index = -1;
+
+	common_len = intel_dp_common_rates(intel_dp, common_rates);
+	link_rate_index = intel_dp_link_rate_index(intel_dp,
+						   common_rates,
+						   link_rate);
+	if (link_rate_index > 0) {
+		intel_dp->fallback_link_rate = common_rates[link_rate_index - 1];
+		intel_dp->fallback_lane_count = intel_dp_max_lane_count(intel_dp);
+	} else if (lane_count > 1) {
+		intel_dp->fallback_link_rate = common_rates[common_len - 1];
+		intel_dp->fallback_lane_count = lane_count >> 1;
+	} else {
+		DRM_ERROR("Link Training Unsuccessful\n");
+		return -1;
+	}
+
+	return 0;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
 		    struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cd132c2..e1c43a9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -887,6 +887,8 @@ struct intel_dp {
 	uint32_t DP;
 	int link_rate;
 	uint8_t lane_count;
+	int fallback_link_rate;
+	uint8_t fallback_lane_count;
 	uint8_t sink_count;
 	bool link_mst;
 	bool has_audio;
@@ -1383,6 +1385,8 @@ bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
 			      int link_rate, uint8_t lane_count,
 			      bool link_mst);
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+					    int link_rate, uint8_t lane_count);
 void intel_dp_start_link_train(struct intel_dp *intel_dp);
 void intel_dp_stop_link_train(struct intel_dp *intel_dp);
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
-- 
1.9.1

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

Re: [PATCH 4/5] drm/i915: Find fallback link rate/lane count

[Jani Nikula]

On Fri, 18 Nov 2016, Manasi Navare <manasi.d.navare@intel.com> wrote:
> If link training fails, then we need to fallback to lower
> link rate first and if link training fails at RBR, then
> fallback to lower lane count.
> This function finds the next lower link rate/lane count
> value after link training failure.
>
> v4:
> * Remove the redundant variable link_train_failed
> v3:
> * Remove fallback_link_rate_index variable, just obtain
> that using the helper intel_dp_link_rate_index (Jani Nikula)
> v2:
> Squash the patch that returns the link rate index (Jani Nikula)
>
> Acked-by: Tony Cheng <tony.cheng@amd.com>
> Acked-by: Harry Wentland <harry.wentland@amd.com>
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 40 ++++++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_drv.h |  4 ++++
>  2 files changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 90283ed..4fb89e1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -288,6 +288,46 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
>  			       common_rates);
>  }
>  
> +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> +				    int *common_rates, int link_rate)
> +{
> +	int common_len;
> +	int index;
> +
> +	common_len = intel_dp_common_rates(intel_dp, common_rates);
> +	for (index = 0; index < common_len; index++) {
> +		if (link_rate == common_rates[common_len - index - 1])
> +			return common_len - index - 1;
> +	}
> +
> +	return -1;
> +}
> +
> +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> +					    int link_rate, uint8_t lane_count)
> +{
> +	int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> +	int common_len;
> +	int link_rate_index = -1;
> +
> +	common_len = intel_dp_common_rates(intel_dp, common_rates);
> +	link_rate_index = intel_dp_link_rate_index(intel_dp,
> +						   common_rates,
> +						   link_rate);
> +	if (link_rate_index > 0) {
> +		intel_dp->fallback_link_rate = common_rates[link_rate_index - 1];
> +		intel_dp->fallback_lane_count = intel_dp_max_lane_count(intel_dp);

So you first try lower and lower link rates, until you're at the
lowest...

> +	} else if (lane_count > 1) {
> +		intel_dp->fallback_link_rate = common_rates[common_len - 1];
> +		intel_dp->fallback_lane_count = lane_count >> 1;

...and then go to highest rate, double lane count, and go back back to
reducing link rate. Rinse and repeat.

Problem is, lane_count will always be > 1, and you'll keep doubling lane
count without bounds if link training persistently fails, and I don't
think you'll reach the below else branch.

I regret that I haven't caught all of these issues all at once; it is in
part testament to the fact that the state machine here is not easy to
follow.

BR,
Jani.

> +	} else {
> +		DRM_ERROR("Link Training Unsuccessful\n");
> +		return -1;
> +	}
> +
> +	return 0;
> +}
> +
>  static enum drm_mode_status
>  intel_dp_mode_valid(struct drm_connector *connector,
>  		    struct drm_display_mode *mode)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index cd132c2..e1c43a9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -887,6 +887,8 @@ struct intel_dp {
>  	uint32_t DP;
>  	int link_rate;
>  	uint8_t lane_count;
> +	int fallback_link_rate;
> +	uint8_t fallback_lane_count;
>  	uint8_t sink_count;
>  	bool link_mst;
>  	bool has_audio;
> @@ -1383,6 +1385,8 @@ bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
>  void intel_dp_set_link_params(struct intel_dp *intel_dp,
>  			      int link_rate, uint8_t lane_count,
>  			      bool link_mst);
> +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> +					    int link_rate, uint8_t lane_count);
>  void intel_dp_start_link_train(struct intel_dp *intel_dp);
>  void intel_dp_stop_link_train(struct intel_dp *intel_dp);
>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

On Fri, Nov 18, 2016 at 03:22:49PM +0200, Jani Nikula wrote:
> On Fri, 18 Nov 2016, Manasi Navare <manasi.d.navare@intel.com> wrote:
> > If link training fails, then we need to fallback to lower
> > link rate first and if link training fails at RBR, then
> > fallback to lower lane count.
> > This function finds the next lower link rate/lane count
> > value after link training failure.
> >
> > v4:
> > * Remove the redundant variable link_train_failed
> > v3:
> > * Remove fallback_link_rate_index variable, just obtain
> > that using the helper intel_dp_link_rate_index (Jani Nikula)
> > v2:
> > Squash the patch that returns the link rate index (Jani Nikula)
> >
> > Acked-by: Tony Cheng <tony.cheng@amd.com>
> > Acked-by: Harry Wentland <harry.wentland@amd.com>
> > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 40 ++++++++++++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/i915/intel_drv.h |  4 ++++
> >  2 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 90283ed..4fb89e1 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -288,6 +288,46 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
> >  			       common_rates);
> >  }
> >  
> > +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> > +				    int *common_rates, int link_rate)
> > +{
> > +	int common_len;
> > +	int index;
> > +
> > +	common_len = intel_dp_common_rates(intel_dp, common_rates);
> > +	for (index = 0; index < common_len; index++) {
> > +		if (link_rate == common_rates[common_len - index - 1])
> > +			return common_len - index - 1;
> > +	}
> > +
> > +	return -1;
> > +}
> > +
> > +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > +					    int link_rate, uint8_t lane_count)
> > +{
> > +	int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> > +	int common_len;
> > +	int link_rate_index = -1;
> > +
> > +	common_len = intel_dp_common_rates(intel_dp, common_rates);
> > +	link_rate_index = intel_dp_link_rate_index(intel_dp,
> > +						   common_rates,
> > +						   link_rate);
> > +	if (link_rate_index > 0) {
> > +		intel_dp->fallback_link_rate = common_rates[link_rate_index - 1];
> > +		intel_dp->fallback_lane_count = intel_dp_max_lane_count(intel_dp);
> 
> So you first try lower and lower link rates, until you're at the
> lowest...
>

Yes so first it tries to lower the link rate until it goes to the lowes i.e RBR.
All this link rate reduction happens with lane count set to maximum.
 
> > +	} else if (lane_count > 1) {
> > +		intel_dp->fallback_link_rate = common_rates[common_len - 1];
> > +		intel_dp->fallback_lane_count = lane_count >> 1;
> 
> ...and then go to highest rate, double lane count, and go back back to
> reducing link rate. Rinse and repeat.
>

So after link rate reaches RBR, it checks if lane count is > 1 and if it is then
it jumps the link rate back to highest supported and reduces the link rate from 
4 to 2 to 1.
 
> Problem is, lane_count will always be > 1, and you'll keep doubling lane
> count without bounds if link training persistently fails, and I don't
> think you'll reach the below else branch.
>

So since I am reducing the lane count in each iteration, lane_count >> 1, at some point
it will go to 0 and that point it will exit with DRM_ERROR that link train failed
because at thatpoint we have exhausted trying all the link raterate and lane count
combinations. 
I am never doubling the link rate for it to reach out of bounds, infact I am reducing
the link rate to half each time (right shifting lane count) so at some point lane count will
fall to less than 0 when it will fall into the last else part.

Regards
Manasi

 
> I regret that I haven't caught all of these issues all at once; it is in
> part testament to the fact that the state machine here is not easy to
> follow.
> 
> BR,
> Jani.
>
 
> > +	} else {
> > +		DRM_ERROR("Link Training Unsuccessful\n");
> > +		return -1;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> >  static enum drm_mode_status
> >  intel_dp_mode_valid(struct drm_connector *connector,
> >  		    struct drm_display_mode *mode)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index cd132c2..e1c43a9 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -887,6 +887,8 @@ struct intel_dp {
> >  	uint32_t DP;
> >  	int link_rate;
> >  	uint8_t lane_count;
> > +	int fallback_link_rate;
> > +	uint8_t fallback_lane_count;
> >  	uint8_t sink_count;
> >  	bool link_mst;
> >  	bool has_audio;
> > @@ -1383,6 +1385,8 @@ bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> >  void intel_dp_set_link_params(struct intel_dp *intel_dp,
> >  			      int link_rate, uint8_t lane_count,
> >  			      bool link_mst);
> > +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > +					    int link_rate, uint8_t lane_count);
> >  void intel_dp_start_link_train(struct intel_dp *intel_dp);
> >  void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

On Fri, Nov 18, 2016 at 07:39:50AM -0800, Manasi Navare wrote:
> On Fri, Nov 18, 2016 at 03:22:49PM +0200, Jani Nikula wrote:
> > On Fri, 18 Nov 2016, Manasi Navare <manasi.d.navare@intel.com> wrote:
> > > If link training fails, then we need to fallback to lower
> > > link rate first and if link training fails at RBR, then
> > > fallback to lower lane count.
> > > This function finds the next lower link rate/lane count
> > > value after link training failure.
> > >
> > > v4:
> > > * Remove the redundant variable link_train_failed
> > > v3:
> > > * Remove fallback_link_rate_index variable, just obtain
> > > that using the helper intel_dp_link_rate_index (Jani Nikula)
> > > v2:
> > > Squash the patch that returns the link rate index (Jani Nikula)
> > >
> > > Acked-by: Tony Cheng <tony.cheng@amd.com>
> > > Acked-by: Harry Wentland <harry.wentland@amd.com>
> > > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c  | 40 ++++++++++++++++++++++++++++++++++++++++
> > >  drivers/gpu/drm/i915/intel_drv.h |  4 ++++
> > >  2 files changed, 44 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > index 90283ed..4fb89e1 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -288,6 +288,46 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
> > >  			       common_rates);
> > >  }
> > >  
> > > +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> > > +				    int *common_rates, int link_rate)
> > > +{
> > > +	int common_len;
> > > +	int index;
> > > +
> > > +	common_len = intel_dp_common_rates(intel_dp, common_rates);
> > > +	for (index = 0; index < common_len; index++) {
> > > +		if (link_rate == common_rates[common_len - index - 1])
> > > +			return common_len - index - 1;
> > > +	}
> > > +
> > > +	return -1;
> > > +}
> > > +
> > > +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > > +					    int link_rate, uint8_t lane_count)
> > > +{
> > > +	int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> > > +	int common_len;
> > > +	int link_rate_index = -1;
> > > +
> > > +	common_len = intel_dp_common_rates(intel_dp, common_rates);
> > > +	link_rate_index = intel_dp_link_rate_index(intel_dp,
> > > +						   common_rates,
> > > +						   link_rate);
> > > +	if (link_rate_index > 0) {
> > > +		intel_dp->fallback_link_rate = common_rates[link_rate_index - 1];
> > > +		intel_dp->fallback_lane_count = intel_dp_max_lane_count(intel_dp);
> > 
> > So you first try lower and lower link rates, until you're at the
> > lowest...
> >
> 
> Yes so first it tries to lower the link rate until it goes to the lowes i.e RBR.
> All this link rate reduction happens with lane count set to maximum.
>  
> > > +	} else if (lane_count > 1) {
> > > +		intel_dp->fallback_link_rate = common_rates[common_len - 1];
> > > +		intel_dp->fallback_lane_count = lane_count >> 1;
> > 
> > ...and then go to highest rate, double lane count, and go back back to
> > reducing link rate. Rinse and repeat.
> >
> 
> So after link rate reaches RBR, it checks if lane count is > 1 and if it is then
> it jumps the link rate back to highest supported and reduces the link rate from 
> 4 to 2 to 1.
>  
> > Problem is, lane_count will always be > 1, and you'll keep doubling lane
> > count without bounds if link training persistently fails, and I don't
> > think you'll reach the below else branch.
> >
> 
> So since I am reducing the lane count in each iteration, lane_count >> 1, at some point
> it will go to 0 and that point it will exit with DRM_ERROR that link train failed
> because at thatpoint we have exhausted trying all the link raterate and lane count
> combinations. 
> I am never doubling the link rate for it to reach out of bounds, infact I am reducing
> the link rate to half each time (right shifting lane count) so at some point lane count will
> fall to less than 0 when it will fall into the last else part.
> 
> Regards
> Manasi
> 
>

The only problem i found is that I am setting lane count to max lane count which is wrong
in each iteration it should be set to lane count being passed in and it should start from that value and fallback.
So for Ex: If the first modeset is trying to train link at 2.7 and 4 lanes and link training fails,
Iteration 1 : 1.62 and 4 if this fails
Iteration 2: max link rate 5.4 and 2 (reduced lane count is halved)
Iteration 3: 2.7 and 2
Iteration 4: 1.62 and 2
Iteration 5: 5.4 and 1
iteration 6: 2.7 and 1
Iteration 7: 1.62 and 1
If this fails then it will return an error that Link training is failed.

Manasi
  
> > I regret that I haven't caught all of these issues all at once; it is in
> > part testament to the fact that the state machine here is not easy to
> > follow.
> > 
> > BR,
> > Jani.
> >
>  
> > > +	} else {
> > > +		DRM_ERROR("Link Training Unsuccessful\n");
> > > +		return -1;
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > >  static enum drm_mode_status
> > >  intel_dp_mode_valid(struct drm_connector *connector,
> > >  		    struct drm_display_mode *mode)
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > index cd132c2..e1c43a9 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -887,6 +887,8 @@ struct intel_dp {
> > >  	uint32_t DP;
> > >  	int link_rate;
> > >  	uint8_t lane_count;
> > > +	int fallback_link_rate;
> > > +	uint8_t fallback_lane_count;
> > >  	uint8_t sink_count;
> > >  	bool link_mst;
> > >  	bool has_audio;
> > > @@ -1383,6 +1385,8 @@ bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > >  void intel_dp_set_link_params(struct intel_dp *intel_dp,
> > >  			      int link_rate, uint8_t lane_count,
> > >  			      bool link_mst);
> > > +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > > +					    int link_rate, uint8_t lane_count);
> > >  void intel_dp_start_link_train(struct intel_dp *intel_dp);
> > >  void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> > >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> > 
> > -- 
> > Jani Nikula, Intel Open Source Technology Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v6 4/56 4/56 4/56 4/56 4/56 4/5] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.

v5:
* Start the fallback at the lane count value passed not
the max lane count (Jani Nikula)
v4:
* Remove the redundant variable link_train_failed
v3:
* Remove fallback_link_rate_index variable, just obtain
that using the helper intel_dp_link_rate_index (Jani Nikula)
v2:
Squash the patch that returns the link rate index (Jani Nikula)

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 90283ed..3a72014 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,46 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
 			       common_rates);
 }
 
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+				    int *common_rates, int link_rate)
+{
+	int common_len;
+	int index;
+
+	common_len = intel_dp_common_rates(intel_dp, common_rates);
+	for (index = 0; index < common_len; index++) {
+		if (link_rate == common_rates[common_len - index - 1])
+			return common_len - index - 1;
+	}
+
+	return -1;
+}
+
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+					    int link_rate, uint8_t lane_count)
+{
+	int common_rates[DP_MAX_SUPPORTED_RATES] = {};
+	int common_len;
+	int link_rate_index = -1;
+
+	common_len = intel_dp_common_rates(intel_dp, common_rates);
+	link_rate_index = intel_dp_link_rate_index(intel_dp,
+						   common_rates,
+						   link_rate);
+	if (link_rate_index > 0) {
+		intel_dp->fallback_link_rate = common_rates[link_rate_index - 1];
+		intel_dp->fallback_lane_count = lane_count;
+	} else if (lane_count > 1) {
+		intel_dp->fallback_link_rate = common_rates[common_len - 1];
+		intel_dp->fallback_lane_count = lane_count >> 1;
+	} else {
+		DRM_ERROR("Link Training Unsuccessful\n");
+		return -1;
+	}
+
+	return 0;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
 		    struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cd132c2..e1c43a9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -887,6 +887,8 @@ struct intel_dp {
 	uint32_t DP;
 	int link_rate;
 	uint8_t lane_count;
+	int fallback_link_rate;
+	uint8_t fallback_lane_count;
 	uint8_t sink_count;
 	bool link_mst;
 	bool has_audio;
@@ -1383,6 +1385,8 @@ bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
 			      int link_rate, uint8_t lane_count,
 			      bool link_mst);
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+					    int link_rate, uint8_t lane_count);
 void intel_dp_start_link_train(struct intel_dp *intel_dp);
 void intel_dp_stop_link_train(struct intel_dp *intel_dp);
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
-- 
1.9.1

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

[PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

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.

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              |  4 +-
 3 files changed, 90 insertions(+), 5 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 3f6b4c9..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 {
@@ -889,7 +892,6 @@ struct intel_dp {
 	uint8_t lane_count;
 	int fallback_link_rate;
 	uint8_t fallback_lane_count;
-	bool link_train_failed;
 	uint8_t sink_count;
 	bool link_mst;
 	bool has_audio;
-- 
1.9.1

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

[PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

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

Re: [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Jani Nikula]

On Fri, 18 Nov 2016, Manasi Navare <manasi.d.navare@intel.com> wrote:
> 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;

Nitpick, totally unnecessary temporary variable.

> +
> +	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);
> +	}

The first time we end up here, we'll still have "good" link status, and
the fallback values won't be taken into account in
intel_dp_mode_valid(). If there are modes that no longer fit into the
fallback values, compute config will fail off the bat the next time
around. So I think you should set link status to bad first.

BR,
Jani.

> +	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 {

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

On Fri, Nov 18, 2016 at 03:31:48PM +0200, Jani Nikula wrote:
> On Fri, 18 Nov 2016, Manasi Navare <manasi.d.navare@intel.com> wrote:
> > 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;
> 
> Nitpick, totally unnecessary temporary variable.
>

Ok, then directly use true while calling the drm_prune_invalid function?

 
> > +
> > +	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);
> > +	}
> 
> The first time we end up here, we'll still have "good" link status, and
> the fallback values won't be taken into account in
> intel_dp_mode_valid(). If there are modes that no longer fit into the
> fallback values, compute config will fail off the bat the next time
> around. So I think you should set link status to bad first.
> 
> BR,
> Jani.
>

Yes, I totally agree, this property need sto be set first and then call mode valid.

Manasi 
> > +	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 {
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v8 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

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.

v8:
* Set link_status to BAD first and then call mode_valid (Jani Nikula)
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 3a72014..747a2ba 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;
+	DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
+		      connector->name);
+
+	/* Grab the locks before changing connector property*/
+	mutex_lock(&connector->dev->mode_config.mutex);
+	/* 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);
+	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);
+	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

✗ Fi.CI.BAT: failure for Link Training failure handling during modeset (rev3)

[Patchwork]

== Series Details ==

Series: Link Training failure handling during modeset (rev3)
URL   : https://patchwork.freedesktop.org/series/15537/
State : failure

== Summary ==

drivers/gpu/drm/i915/intel_drv.h:892:9: error: invalid suffix "bcbb9f2b4bf4246a3a88fbdec7de32f2f6070d6" on integer constant
 <<<<<<< 1bcbb9f2b4bf4246a3a88fbdec7de32f2f6070d6
         ^
In file included from drivers/gpu/drm/i915/i915_sysfs.c:32:0:
drivers/gpu/drm/i915/intel_drv.h:892:1: error: expected specifier-qualifier-list before ‘<<’ token
 <<<<<<< 1bcbb9f2b4bf4246a3a88fbdec7de32f2f6070d6
 ^
drivers/gpu/drm/i915/intel_drv.h:892:9: error: invalid suffix "bcbb9f2b4bf4246a3a88fbdec7de32f2f6070d6" on integer constant
 <<<<<<< 1bcbb9f2b4bf4246a3a88fbdec7de32f2f6070d6
         ^
In file included from drivers/gpu/drm/i915/i915_suspend.c:29:0:
drivers/gpu/drm/i915/intel_drv.h:892:1: error: expected specifier-qualifier-list before ‘<<’ token
 <<<<<<< 1bcbb9f2b4bf4246a3a88fbdec7de32f2f6070d6
 ^
drivers/gpu/drm/i915/intel_drv.h:892:9: error: invalid suffix "bcbb9f2b4bf4246a3a88fbdec7de32f2f6070d6" on integer constant
 <<<<<<< 1bcbb9f2b4bf4246a3a88fbdec7de32f2f6070d6
         ^
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/i915_sysfs.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_sysfs.o] Error 1
  LD      net/xfrm/built-in.o
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/i915_suspend.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_suspend.o] Error 1
  LD [M]  sound/pci/hda/snd-hda-codec-generic.o
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/intel_csr.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_csr.o] Error 1
  LD      sound/pci/built-in.o
  LD      drivers/pci/built-in.o
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/intel_device_info.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_device_info.o] Error 1
  LD      drivers/scsi/scsi_mod.o
  LD      sound/built-in.o
  LD      drivers/usb/storage/usb-storage.o
  LD      drivers/usb/storage/built-in.o
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/intel_pm.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_pm.o] Error 1
scripts/Makefile.build:475: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:475: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:475: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
make[1]: *** Waiting for unfinished jobs....
  LD      drivers/acpi/acpica/acpi.o
  LD      drivers/tty/serial/8250/8250.o
  LD      drivers/thermal/thermal_sys.o
  LD [M]  drivers/usb/serial/usbserial.o
  LD      drivers/thermal/built-in.o
  LD      drivers/spi/built-in.o
  LD      drivers/acpi/acpica/built-in.o
  LD      drivers/usb/gadget/libcomposite.o
  LD      drivers/video/fbdev/core/fb.o
  LD      drivers/video/fbdev/core/built-in.o
  LD      drivers/acpi/built-in.o
  LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
  LD      drivers/scsi/sd_mod.o
  LD      drivers/usb/gadget/udc/udc-core.o
  LD      drivers/usb/gadget/udc/built-in.o
  LD      drivers/usb/gadget/built-in.o
  LD      drivers/scsi/built-in.o
  LD      net/ipv6/ipv6.o
  LD      net/ipv6/built-in.o
  LD      drivers/video/fbdev/built-in.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD      drivers/iommu/built-in.o
  AR      lib/lib.a
  EXPORTS lib/lib-ksyms.o
  LD      lib/built-in.o
  LD      drivers/tty/serial/8250/8250_base.o
  LD      drivers/tty/serial/8250/built-in.o
  CC      arch/x86/kernel/cpu/capflags.o
  LD      drivers/tty/serial/built-in.o
  LD      drivers/video/console/built-in.o
  LD      arch/x86/kernel/cpu/built-in.o
  LD      drivers/video/built-in.o
  LD      arch/x86/kernel/built-in.o
  LD      fs/btrfs/btrfs.o
  LD      drivers/usb/core/usbcore.o
  LD      fs/btrfs/built-in.o
  LD      arch/x86/built-in.o
  LD      drivers/usb/core/built-in.o
  LD      drivers/usb/host/xhci-hcd.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD      drivers/md/md-mod.o
  LD      drivers/md/built-in.o
  LD      drivers/tty/vt/built-in.o
  LD      drivers/tty/built-in.o
  LD      net/ipv4/built-in.o
  LD      fs/ext4/ext4.o
  LD      drivers/usb/host/built-in.o
  LD      net/core/built-in.o
  LD      drivers/usb/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD      fs/ext4/built-in.o
  LD      net/built-in.o
  LD      fs/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD      drivers/net/ethernet/built-in.o
  LD      drivers/net/built-in.o
Makefile:985: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

✗ Fi.CI.BAT: failure for Link Training failure handling during modeset (rev4)

[Patchwork]

== Series Details ==

Series: Link Training failure handling during modeset (rev4)
URL   : https://patchwork.freedesktop.org/series/15537/
State : failure

== Summary ==

   (_timer)->data = (_data);    \
                     ^
./include/linux/workqueue.h:247:2: note: in expansion of macro ‘__INIT_DELAYED_WORK’
  __INIT_DELAYED_WORK(_work, _func, 0)
  ^
drivers/gpu/drm/i915/intel_dp.c:5745:2: note: in expansion of macro ‘INIT_DELAYED_WORK’
  INIT_DELAYED_WORK(&intel_dp->panel_vdd_work,
  ^
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_mst_suspend’:
drivers/gpu/drm/i915/intel_dp.c:5899:45: error: ‘struct intel_dp’ has no member named ‘can_mst’
   if (!intel_dig_port || !intel_dig_port->dp.can_mst)
                                             ^
drivers/gpu/drm/i915/intel_dp.c:5902:25: error: ‘struct intel_dp’ has no member named ‘is_mst’
   if (intel_dig_port->dp.is_mst)
                         ^
drivers/gpu/drm/i915/intel_dp.c:5903:55: error: ‘struct intel_dp’ has no member named ‘mst_mgr’
    drm_dp_mst_topology_mgr_suspend(&intel_dig_port->dp.mst_mgr);
                                                       ^
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_mst_resume’:
drivers/gpu/drm/i915/intel_dp.c:5916:45: error: ‘struct intel_dp’ has no member named ‘can_mst’
   if (!intel_dig_port || !intel_dig_port->dp.can_mst)
                                             ^
drivers/gpu/drm/i915/intel_dp.c:5919:59: error: ‘struct intel_dp’ has no member named ‘mst_mgr’
   ret = drm_dp_mst_topology_mgr_resume(&intel_dig_port->dp.mst_mgr);
                                                           ^
drivers/gpu/drm/i915/intel_dp.c: In function ‘__intel_dp_read_desc’:
drivers/gpu/drm/i915/intel_dp.c:1501:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_rate_select’:
drivers/gpu/drm/i915/intel_dp.c:1551:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/gvt/scheduler.o' failed
make[4]: *** [drivers/gpu/drm/i915/gvt/scheduler.o] Error 1
drivers/gpu/drm/i915/intel_dp.c: In function ‘vlv_power_sequencer_pipe’:
drivers/gpu/drm/i915/intel_dp.c:568:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_get_link_status’:
drivers/gpu/drm/i915/intel_dp.c:3013:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_read_dpcd’:
drivers/gpu/drm/i915/intel_dp.c:3545:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_connector_register’:
drivers/gpu/drm/i915/intel_dp.c:4695:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_get_edid’:
drivers/gpu/drm/i915/intel_dp.c:4361:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/gvt/gtt.o' failed
make[4]: *** [drivers/gpu/drm/i915/gvt/gtt.o] Error 1
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/intel_dp.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_dp.o] Error 1
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/i915_trace_points.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_trace_points.o] Error 1
scripts/Makefile.build:290: recipe for target 'drivers/gpu/drm/i915/gvt/handlers.o' failed
make[4]: *** [drivers/gpu/drm/i915/gvt/handlers.o] Error 1
  CC      arch/x86/kernel/cpu/capflags.o
  LD      arch/x86/kernel/cpu/built-in.o
scripts/Makefile.build:475: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:475: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:475: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
make[1]: *** Waiting for unfinished jobs....
  LD      arch/x86/kernel/built-in.o
  LD      drivers/pci/built-in.o
  LD      arch/x86/built-in.o
  LD      fs/btrfs/btrfs.o
  AR      lib/lib.a
  EXPORTS lib/lib-ksyms.o
  LD      lib/built-in.o
  LD      fs/btrfs/built-in.o
  LD      drivers/md/md-mod.o
  LD      drivers/md/built-in.o
  LD      drivers/usb/host/xhci-hcd.o
  LD      drivers/tty/vt/built-in.o
  LD      drivers/tty/built-in.o
  LD      net/ipv4/built-in.o
  LD      drivers/usb/host/built-in.o
  LD      drivers/usb/built-in.o
  LD      fs/ext4/ext4.o
  LD      fs/ext4/built-in.o
  LD      fs/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD      net/core/built-in.o
  LD      net/built-in.o
  LD      drivers/net/ethernet/built-in.o
  LD      drivers/net/built-in.o
Makefile:985: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[PATCH 0/5] Clean series for Link training failure handling

[Manasi Navare]

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

[PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

CRTC state connector_changed needs to be set to true
if connector link status property has changed. This will tell the
driver to do a complete modeset due to change in connector property.

Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tony Cheng <tony.cheng@amd.com>
Cc: dri-devel@lists.freedesktop.org
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/drm_atomic_helper.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 0b16587..2125fd1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
 					       connector_state);
 		if (ret)
 			return ret;
+
+		if (connector->state->crtc) {
+			crtc_state = drm_atomic_get_existing_crtc_state(state,
+									connector->state->crtc);
+			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
+				crtc_state->connectors_changed = true;
+		}
 	}
 
 	/*
-- 
1.9.1

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

[PATCH 0/5] Handle link training failure during modeset

[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

[PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

CRTC state connector_changed needs to be set to true
if connector link status property has changed. This will tell the
driver to do a complete modeset due to change in connector property.

Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Tony Cheng <tony.cheng@amd.com>
Cc: dri-devel@lists.freedesktop.org
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/drm_atomic_helper.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 5007796..aeecf2f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
 					       connector_state);
 		if (ret)
 			return ret;
+
+		if (connector->state->crtc) {
+			crtc_state = drm_atomic_get_existing_crtc_state(state,
+									connector->state->crtc);
+			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
+				crtc_state->connectors_changed = true;
+		}
 	}
 
 	/*
-- 
1.9.1

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

[PATCH 0/5] Handle Link Training Failure during modeset

[Manasi Navare]

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

[PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

CRTC state connector_changed needs to be set to true
if connector link status property has changed. This will tell the
driver to do a complete modeset due to change in connector property.

Cc: dri-devel@lists.freedesktop.org
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/drm_atomic_helper.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 5007796..aeecf2f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state,
 					       connector_state);
 		if (ret)
 			return ret;
+
+		if (connector->state->crtc) {
+			crtc_state = drm_atomic_get_existing_crtc_state(state,
+									connector->state->crtc);
+			if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
+				crtc_state->connectors_changed = true;
+		}
 	}
 
 	/*
-- 
1.9.1

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