[PATCH 1/5] drm/i915: Splitting intel_dp_detect

[PATCH 1/5] drm/i915: Splitting intel_dp_detect

[Shubhangi Shrivastava]

intel_dp_detect() is called for not just detection but
during modes enumeration as well. Repeating the whole
sequence during each of these calls is wasteful and
time consuming.
This patch moves probing for panel, DPCD read etc done in
intel_dp_detect() to a new function intel_dp_long_pulse().
Note that the behavior of intel_dp_detect() is changed to
report connected or disconnected depending on whether the
EDID is available or not.
This change will be required by further patches in the series
to avoid performing duplicated DPCD operations on hotplug.

v2: Moved a hunk to next patch of the series.
    Moved intel_dp_unset_edid to out. (Ander)

v3: Rephrased commit message and intel_dp_unset_dp() is called
    within intel_dp_set_dp() to free the previous EDID. (Ander)

v4: Added overriding of status to disconnected for MST. (Ander)

Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
---
 drivers/gpu/drm/i915/intel_dp.c | 63 ++++++++++++++++++++++++++++-------------
 1 file changed, 43 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3bdd8ba..b4cff63 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -129,6 +129,7 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync);
 static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
 static void vlv_steal_power_sequencer(struct drm_device *dev,
 				      enum pipe pipe);
+static void intel_dp_unset_edid(struct intel_dp *intel_dp);
 
 static unsigned int intel_dp_unused_lane_mask(int lane_count)
 {
@@ -4513,6 +4514,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
 	struct intel_connector *intel_connector = intel_dp->attached_connector;
 	struct edid *edid;
 
+	intel_dp_unset_edid(intel_dp);
 	edid = intel_dp_get_edid(intel_dp);
 	intel_connector->detect_edid = edid;
 
@@ -4533,9 +4535,10 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
 	intel_dp->has_audio = false;
 }
 
-static enum drm_connector_status
-intel_dp_detect(struct drm_connector *connector, bool force)
+static void
+intel_dp_long_pulse(struct intel_connector *intel_connector)
 {
+	struct drm_connector *connector = &intel_connector->base;
 	struct intel_dp *intel_dp = intel_attached_dp(connector);
 	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
 	struct intel_encoder *intel_encoder = &intel_dig_port->base;
@@ -4545,17 +4548,6 @@ intel_dp_detect(struct drm_connector *connector, bool force)
 	bool ret;
 	u8 sink_irq_vector;
 
-	DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
-		      connector->base.id, connector->name);
-	intel_dp_unset_edid(intel_dp);
-
-	if (intel_dp->is_mst) {
-		/* MST devices are disconnected from a monitor POV */
-		if (intel_encoder->type != INTEL_OUTPUT_EDP)
-			intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
-		return connector_status_disconnected;
-	}
-
 	power_domain = intel_display_port_aux_power_domain(intel_encoder);
 	intel_display_power_get(to_i915(dev), power_domain);
 
@@ -4576,14 +4568,18 @@ intel_dp_detect(struct drm_connector *connector, bool force)
 		goto out;
 	}
 
+	if (intel_encoder->type != INTEL_OUTPUT_EDP)
+		intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
+
 	intel_dp_probe_oui(intel_dp);
 
 	ret = intel_dp_probe_mst(intel_dp);
 	if (ret) {
-		/* if we are in MST mode then this connector
-		   won't appear connected or have anything with EDID on it */
-		if (intel_encoder->type != INTEL_OUTPUT_EDP)
-			intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
+		/*
+		 * If we are in MST mode then this connector
+		 * won't appear connected or have anything
+		 * with EDID on it
+		 */
 		status = connector_status_disconnected;
 		goto out;
 	}
@@ -4598,8 +4594,6 @@ intel_dp_detect(struct drm_connector *connector, bool force)
 
 	intel_dp_set_edid(intel_dp);
 
-	if (intel_encoder->type != INTEL_OUTPUT_EDP)
-		intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
 	status = connector_status_connected;
 
 	/* Try to read the source of the interrupt */
@@ -4617,8 +4611,37 @@ intel_dp_detect(struct drm_connector *connector, bool force)
 	}
 
 out:
+	if (status != connector_status_connected)
+		intel_dp_unset_edid(intel_dp);
 	intel_display_power_put(to_i915(dev), power_domain);
-	return status;
+	return;
+}
+
+static enum drm_connector_status
+intel_dp_detect(struct drm_connector *connector, bool force)
+{
+	struct intel_dp *intel_dp = intel_attached_dp(connector);
+	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+	struct intel_encoder *intel_encoder = &intel_dig_port->base;
+	struct intel_connector *intel_connector = to_intel_connector(connector);
+
+	DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
+		     connector->base.id, connector->name);
+
+	if (intel_dp->is_mst) {
+		/* MST devices are disconnected from a monitor POV */
+		intel_dp_unset_edid(intel_dp);
+		if (intel_encoder->type != INTEL_OUTPUT_EDP)
+			intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
+		return connector_status_disconnected;
+	}
+
+	intel_dp_long_pulse(intel_dp->attached_connector);
+
+	if (intel_connector->detect_edid)
+		return connector_status_connected;
+	else
+		return connector_status_disconnected;
 }
 
 static void
-- 
2.6.1

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

[PATCH 2/5] drm/i915: Cleaning up intel_dp_hpd_pulse

[Shubhangi Shrivastava]

Current DP detection has DPCD operations split across
intel_dp_hpd_pulse and intel_dp_detect which contains
duplicates as well. Also intel_dp_detect is called
during modes enumeration as well which will result
in multiple dpcd operations. So this patch tries
to solve both these by bringing all DPCD operations
in one single function and make intel_dp_detect
use existing values instead of repeating same steps.

v2: Pulled in a hunk from last patch of the series to
    this patch. (Ander)

v3: Added MST hotplug handling. (Ander)

v4: Added a flag to check if detect is performed to
    prevent multiple detects on hotplug. (Ander)

Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
---
 drivers/gpu/drm/i915/intel_dp.c  | 72 +++++++++++++++++++++++++---------------
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 47 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b4cff63..0e16f74 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4582,6 +4582,16 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
 		 */
 		status = connector_status_disconnected;
 		goto out;
+	} else if (connector->status == connector_status_connected) {
+		/*
+		 * If display was connected already and is still connected
+		 * check links status, there has been known issues of
+		 * link loss triggerring long pulse!!!!
+		 */
+		drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+		intel_dp_check_link_status(intel_dp);
+		drm_modeset_unlock(&dev->mode_config.connection_mutex);
+		goto out;
 	}
 
 	/*
@@ -4595,6 +4605,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
 	intel_dp_set_edid(intel_dp);
 
 	status = connector_status_connected;
+	intel_dp->detect_done = true;
 
 	/* Try to read the source of the interrupt */
 	if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
@@ -4611,8 +4622,21 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
 	}
 
 out:
-	if (status != connector_status_connected)
+	if (status != connector_status_connected) {
 		intel_dp_unset_edid(intel_dp);
+		/*
+		 * If we were in MST mode, and device is not there,
+		 * get out of MST mode
+		 */
+		if (intel_dp->is_mst) {
+			DRM_DEBUG_KMS("MST device may have disappeared %d vs %d\n",
+				intel_dp->is_mst, intel_dp->mst_mgr.mst_state);
+			intel_dp->is_mst = false;
+			drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
+							intel_dp->is_mst);
+		}
+	}
+
 	intel_display_power_put(to_i915(dev), power_domain);
 	return;
 }
@@ -4636,7 +4660,11 @@ intel_dp_detect(struct drm_connector *connector, bool force)
 		return connector_status_disconnected;
 	}
 
-	intel_dp_long_pulse(intel_dp->attached_connector);
+	/* If full detect is not performed yet, do a full detect */
+	if (!intel_dp->detect_done)
+		intel_dp_long_pulse(intel_dp->attached_connector);
+
+	intel_dp->detect_done = false;
 
 	if (intel_connector->detect_edid)
 		return connector_status_connected;
@@ -4968,25 +4996,25 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
 		/* indicate that we need to restart link training */
 		intel_dp->train_set_valid = false;
 
-		if (!intel_digital_port_connected(dev_priv, intel_dig_port))
-			goto mst_fail;
-
-		if (!intel_dp_get_dpcd(intel_dp)) {
-			goto mst_fail;
-		}
-
-		intel_dp_probe_oui(intel_dp);
+		intel_dp_long_pulse(intel_dp->attached_connector);
+		if (intel_dp->is_mst)
+			ret = IRQ_HANDLED;
+		goto put_power;
 
-		if (!intel_dp_probe_mst(intel_dp)) {
-			drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
-			intel_dp_check_link_status(intel_dp);
-			drm_modeset_unlock(&dev->mode_config.connection_mutex);
-			goto mst_fail;
-		}
 	} else {
 		if (intel_dp->is_mst) {
-			if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
-				goto mst_fail;
+			if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
+				/*
+				 * If we were in MST mode, and device is not
+				 * there, get out of MST mode
+				 */
+				DRM_DEBUG_KMS("MST device may have disappeared %d vs %d\n",
+					intel_dp->is_mst, intel_dp->mst_mgr.mst_state);
+				intel_dp->is_mst = false;
+				drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
+								intel_dp->is_mst);
+				goto put_power;
+			}
 		}
 
 		if (!intel_dp->is_mst) {
@@ -4998,14 +5026,6 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
 
 	ret = IRQ_HANDLED;
 
-	goto put_power;
-mst_fail:
-	/* if we were in MST mode, and device is not there get out of MST mode */
-	if (intel_dp->is_mst) {
-		DRM_DEBUG_KMS("MST device may have disappeared %d vs %d\n", intel_dp->is_mst, intel_dp->mst_mgr.mst_state);
-		intel_dp->is_mst = false;
-		drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr, intel_dp->is_mst);
-	}
 put_power:
 	intel_display_power_put(dev_priv, power_domain);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c87b450..3ce9391 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -797,6 +797,7 @@ struct intel_dp {
 	int link_rate;
 	uint8_t lane_count;
 	bool has_audio;
+	bool detect_done;
 	enum hdmi_force_audio force_audio;
 	bool limited_color_range;
 	bool color_range_auto;
-- 
2.6.1

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

[PATCH 3/5] drm/i915: Reorganizing intel_dp_check_link_status

[Shubhangi Shrivastava]

When created originally intel_dp_check_link_status()
was supposed to handle only link training for short
pulse but has grown into handler for short pulse itself.
This patch cleans up this function by splitting it into
two halves. First intel_dp_short_pulse() is called,
which will be entry point and handle all logic for
short pulse handling while intel_dp_check_link_status()
will retain its original purpose of only doing link
status related work.

intel_dp_short_pulse: All existing code other than
link status read and link training upon error status.

intel_dp_check_link_status:
The link status should be read on short pulse
irrespective of panel being enabled or not so
intel_dp_get_link_status() performs dpcd read first
then based on crtc active / enabled it will
perform the link training.

This is because short pulse is a generic interrupt
which should always be handled, because it may mean:
	1. Hotplug/unplug of MST panel
	2. Hotplug/unplug of dongle
	3. Link status change for other DP panels

v2: Added WARN_ON to intel_dp_check_link_status()
    Removed a call to intel_dp_get_link_status() (Ander)

v3: Changed commit message to explain need of link status
    being read before performing encoder checks (Daniel)

v4: Changed commit message to explain need of reading
    link status on short pulse (Ander)

Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
---
 drivers/gpu/drm/i915/intel_dp.c | 65 +++++++++++++++++++++++------------------
 1 file changed, 36 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0e16f74..46030a2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4215,6 +4215,36 @@ go_again:
 	return -EINVAL;
 }
 
+static void
+intel_dp_check_link_status(struct intel_dp *intel_dp)
+{
+	struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
+	struct drm_device *dev = intel_dp_to_dev(intel_dp);
+	u8 link_status[DP_LINK_STATUS_SIZE];
+
+	WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+
+	if (!intel_dp_get_link_status(intel_dp, link_status)) {
+		DRM_ERROR("Failed to get link status\n");
+		return;
+	}
+
+	if (!intel_encoder->base.crtc)
+		return;
+
+	if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+		return;
+
+	/* if link training is requested we should perform it always */
+	if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
+		(!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
+		DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
+				intel_encoder->base.name);
+		intel_dp_start_link_train(intel_dp);
+		intel_dp_stop_link_train(intel_dp);
+	}
+}
+
 /*
  * According to DP spec
  * 5.1.2:
@@ -4224,14 +4254,10 @@ go_again:
  *  4. Check link status on receipt of hot-plug interrupt
  */
 static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
 	struct drm_device *dev = intel_dp_to_dev(intel_dp);
-	struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
 	u8 sink_irq_vector;
-	u8 link_status[DP_LINK_STATUS_SIZE];
-
-	WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
 
 	/*
 	 * Clearing compliance test variables to allow capturing
@@ -4241,17 +4267,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 	intel_dp->compliance_test_type = 0;
 	intel_dp->compliance_test_data = 0;
 
-	if (!intel_encoder->base.crtc)
-		return;
-
-	if (!to_intel_crtc(intel_encoder->base.crtc)->active)
-		return;
-
-	/* Try to read receiver status if the link appears to be up */
-	if (!intel_dp_get_link_status(intel_dp, link_status)) {
-		return;
-	}
-
 	/* Now read the DPCD to see if it's actually running */
 	if (!intel_dp_get_dpcd(intel_dp)) {
 		return;
@@ -4271,14 +4286,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 			DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
 	}
 
-	/* if link training is requested we should perform it always */
-	if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
-		(!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
-		DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
-			      intel_encoder->base.name);
-		intel_dp_start_link_train(intel_dp);
-		intel_dp_stop_link_train(intel_dp);
-	}
+	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+	intel_dp_check_link_status(intel_dp);
+	drm_modeset_unlock(&dev->mode_config.connection_mutex);
 }
 
 /* XXX this is probably wrong for multiple downstream ports */
@@ -5017,11 +5027,8 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
 			}
 		}
 
-		if (!intel_dp->is_mst) {
-			drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
-			intel_dp_check_link_status(intel_dp);
-			drm_modeset_unlock(&dev->mode_config.connection_mutex);
-		}
+		if (!intel_dp->is_mst)
+			intel_dp_short_pulse(intel_dp);
 	}
 
 	ret = IRQ_HANDLED;
-- 
2.6.1

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

[PATCH 4/5] drm/i915: Read sink_count dpcd always

[Shubhangi Shrivastava]

Sink count can change between short pulse hpd hence this patch
adds a member variable to intel_dp so we can track any changes
between short pulse interrupts.

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

Here is a table of possible values and scenarios

sink_count      downstream_port
                present
0               0               no display is attached
0               1               dongle is connected without display
1               0               display connected directly
1               1               display connected through dongle

v2: Storing value of intel_dp->sink_count that is ready
    for consumption. (Ander)
    Squashing two commits into one. (Ander)

v3: Added comment to explain the need of early return when
    sink count is 0. (Ander)

Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
---
 drivers/gpu/drm/i915/intel_dp.c  | 30 +++++++++++++++++++++++-------
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 46030a2..9b2b96f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3788,6 +3788,27 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
 	if (intel_dp->dpcd[DP_DPCD_REV] == 0)
 		return false; /* DPCD not present */
 
+	if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
+				    &intel_dp->sink_count, 1) < 0)
+		return false;
+
+	/*
+	 * Sink count can change between short pulse hpd hence
+	 * a member variable in intel_dp will track any changes
+	 * between short pulse interrupts.
+	 */
+	intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count);
+
+	/*
+	 * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
+	 * a dongle is present but no display. Unless we require to know
+	 * if a dongle is present or not, we don't need to update
+	 * downstream port information. So, an early return here saves
+	 * time from performing other operations which are not required.
+	 */
+	if (!intel_dp->sink_count)
+		return false;
+
 	/* Check if the panel supports PSR */
 	memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
 	if (is_edp(intel_dp)) {
@@ -4308,14 +4329,9 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
 	/* If we're HPD-aware, SINK_COUNT changes dynamically */
 	if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
 	    intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
-		uint8_t reg;
-
-		if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
-					    &reg, 1) < 0)
-			return connector_status_unknown;
 
-		return DP_GET_SINK_COUNT(reg) ? connector_status_connected
-					      : connector_status_disconnected;
+		return intel_dp->sink_count ?
+		connector_status_connected : connector_status_disconnected;
 	}
 
 	/* If no HPD, poke DDC gently */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3ce9391..36c41e8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -796,6 +796,7 @@ struct intel_dp {
 	uint32_t DP;
 	int link_rate;
 	uint8_t lane_count;
+	uint8_t sink_count;
 	bool has_audio;
 	bool detect_done;
 	enum hdmi_force_audio force_audio;
-- 
2.6.1

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

[PATCH 5/5] drm/i915: force full detect on sink count change

[Shubhangi Shrivastava]

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

v2: changed variable type from u8 to bool (Jani)
    return immediately if perform_full_detect is set(Siva)

v3: changed method of determining full detection from using
    pointer to return code (Siva)

v4: changed comments to indicate meaning of return value of
    intel_dp_short_pulse and explain the use of return value
    from intel_dp_get_dpcd in intel_dp_short_pulse (Ander)

Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
---
 drivers/gpu/drm/i915/intel_dp.c | 33 +++++++++++++++++++++++++++------
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9b2b96f..538bc02 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4273,12 +4273,19 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
  *  2. Configure link according to Receiver Capabilities
  *  3. Use Link Training from 2.5.3.3 and 3.5.1.3
  *  4. Check link status on receipt of hot-plug interrupt
+ *
+ * intel_dp_short_pulse -  handles short pulse interrupts
+ * when full detection is not required.
+ * Returns %true if short pulse is handled and full detection
+ * is NOT required and %false otherwise.
  */
-static void
+static bool
 intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
 	struct drm_device *dev = intel_dp_to_dev(intel_dp);
 	u8 sink_irq_vector;
+	u8 old_sink_count = intel_dp->sink_count;
+	bool ret;
 
 	/*
 	 * Clearing compliance test variables to allow capturing
@@ -4288,9 +4295,17 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
 	intel_dp->compliance_test_type = 0;
 	intel_dp->compliance_test_data = 0;
 
-	/* Now read the DPCD to see if it's actually running */
-	if (!intel_dp_get_dpcd(intel_dp)) {
-		return;
+	/*
+	 * Now read the DPCD to see if it's actually running
+	 * If the current value of sink count doesn't match with
+	 * the value that was stored earlier or dpcd read failed
+	 * we need to do full detection
+	 */
+	ret = intel_dp_get_dpcd(intel_dp);
+
+	if ((old_sink_count != intel_dp->sink_count) || !ret) {
+		/* No need to proceed if we are going to do full detect */
+		return false;
 	}
 
 	/* Try to read the source of the interrupt */
@@ -4310,6 +4325,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
 	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
 	intel_dp_check_link_status(intel_dp);
 	drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+	return true;
 }
 
 /* XXX this is probably wrong for multiple downstream ports */
@@ -5043,8 +5060,12 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
 			}
 		}
 
-		if (!intel_dp->is_mst)
-			intel_dp_short_pulse(intel_dp);
+		if (!intel_dp->is_mst) {
+			if (!intel_dp_short_pulse(intel_dp)) {
+				intel_dp_long_pulse(intel_dp->attached_connector);
+				goto put_power;
+			}
+		}
 	}
 
 	ret = IRQ_HANDLED;
-- 
2.6.1

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

✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
URL   : https://patchwork.freedesktop.org/series/5044/
State : success

== Summary ==

Series 5044v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5044/revisions/1/mbox/

Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-c:
                dmesg-warn -> PASS       (bsw-nuc-2)

bdw-nuci7        total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultra        total:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2        total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc          total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox      total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2          total:27   pass:24   dwarn:0   dfail:0   fail:0   skip:2  
skl-i7k-2        total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5        total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps      total:79   pass:68   dwarn:0   dfail:0   fail:0   skip:10 

Results at /archive/results/CI_IGT_test/Patchwork_1753/

03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly: 2016y-03m-31d-10h-50m-15s UTC integration manifest
c448c6c059ae7bcdb7345feafd5324dd6dd164a7 drm/i915: force full detect on sink count change
c1a69603958ccde4084f379f6c1a02314b8f5245 drm/i915: Read sink_count dpcd always
5f91fb8d635f35130714bf60601948996ee976e3 drm/i915: Reorganizing intel_dp_check_link_status
950d50e19edac435bed7a08f6147af55cd2c8835 drm/i915: Cleaning up intel_dp_hpd_pulse
41fd654a2ac9ffc2d59ccf23511113b28f6271b1 drm/i915: Splitting intel_dp_detect

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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Ander Conselvan De Oliveira]

On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
> URL   : https://patchwork.freedesktop.org/series/5044/
> State : success

I pushed those to dinq.

I fixed a couple of "Alignment should match open parenthesis" errors from
checkpatch. I should have pointed those out during review, but I missed them.

For future reference, in a expression like below,

	DRM_DEBUG_KMS("debug message %d",
		      number),

the second line should be aligned with the opening '('.

Ander


> 
> == Summary ==
> 
> Series 5044v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/5044/revisions/1/mbox/
> 
> Test kms_pipe_crc_basic:
>         Subgroup suspend-read-crc-pipe-c:
>                 dmesg-warn -> PASS       (bsw-nuc-2)
> 
> bdw-nuci7        total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultra        total:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
> bsw-nuc-2        total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
> byt-nuc          total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
> hsw-brixbox      total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
> hsw-gt2          total:27   pass:24   dwarn:0   dfail:0   fail:0   skip:2  
> skl-i7k-2        total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
> skl-nuci5        total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
> snb-dellxps      total:79   pass:68   dwarn:0   dfail:0   fail:0   skip:10 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1753/
> 
> 03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly: 2016y-03m-31d-10h
> -50m-15s UTC integration manifest
> c448c6c059ae7bcdb7345feafd5324dd6dd164a7 drm/i915: force full detect on sink
> count change
> c1a69603958ccde4084f379f6c1a02314b8f5245 drm/i915: Read sink_count dpcd always
> 5f91fb8d635f35130714bf60601948996ee976e3 drm/i915: Reorganizing
> intel_dp_check_link_status
> 950d50e19edac435bed7a08f6147af55cd2c8835 drm/i915: Cleaning up
> intel_dp_hpd_pulse
> 41fd654a2ac9ffc2d59ccf23511113b28f6271b1 drm/i915: Splitting intel_dp_detect
> 
> _______________________________________________
> 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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Tvrtko Ursulin]

On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
> On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
>> == Series Details ==
>>
>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>> URL   : https://patchwork.freedesktop.org/series/5044/
>> State : success
> 
> I pushed those to dinq.

This series seems to break eDP detection on BDW RVP.

Old kernel:

[    1.554183] [drm:intel_dp_init_connector] Adding eDP connector on port A
[    1.554245] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 2000 t10 500 t11_t12 6000
[    1.554254] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000
[    1.554263] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 200, power down delay 50, power cycle delay 600
[    1.554271] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, off delay 200
[    1.554279] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
[    1.554530] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
[    1.554562] [drm:edp_panel_vdd_on] PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd000f
[    1.556670] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[    1.557617] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, sink no
[    1.557627] [drm:intel_dp_print_rates] source rates: 162000, 270000, 540000
[    1.557633] [drm:intel_dp_print_rates] sink rates: 162000, 270000
[    1.557638] [drm:intel_dp_print_rates] common rates: 162000, 270000
[    1.557651] [drm:intel_dp_init_panel_power_sequencer_registers] panel power sequencer register settings: PP_ON 0x7d00001, PP_OFF 0x1f40001, PP_DIV 0x4af06
[    1.567299] [drm:drm_edid_to_eld] ELD: no CEA Extension found
[    1.567308] [drm:intel_dp_drrs_init] VBT doesn't support DRRS
[    1.567319] [drm:intel_panel_setup_backlight] Connector eDP-1 backlight initialized, enabled, brightness 937/937


Todays nightly:

[    4.306321] [drm:intel_dp_init_connector] Adding eDP connector on port A
[    4.306370] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 2000 t10 500 t11_t12 6000
[    4.306371] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000
[    4.306373] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 200, power down delay 50, power cycle delay 600
[    4.306374] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, off delay 200
[    4.306375] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
[    4.306402] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
[    4.306413] [drm:edp_panel_vdd_on] PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd000f
[    4.319361] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[    4.331840] [drm] failed to retrieve link info, disabling eDP
[    4.331862] [drm:edp_panel_vdd_off_sync] Turning eDP port A VDD off

Series reverted:

[    4.770004] [drm:intel_dp_init_connector] Adding eDP connector on port A
[    4.777651] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 2000 t10 500 t11_t12 6000
[    4.788222] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000
[    4.798890] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 200, power down delay 50, power cycle delay 600
[    4.811424] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, off delay 200
[    4.820705] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
[    4.828631] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
[    4.835061] [drm:edp_panel_vdd_on] PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd000f
[    4.843757] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
[    4.853032] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, sink no
[    4.861624] [drm:intel_dp_print_rates] source rates: 162000, 270000, 540000
[    4.869551] [drm:intel_dp_print_rates] sink rates: 162000, 270000
[    4.876558] [drm:intel_dp_print_rates] common rates: 162000, 270000
[    4.883812] [drm:intel_dp_init_panel_power_sequencer_registers] panel power sequencer register settings: PP_ON 0x7d00001, PP_OFF 0x1f40001, PP_DIV 0x4af06
[    4.900522] asix 1-2:1.0 eth0: register 'asix' at usb-0000:00:14.0-2, ASIX AX88772 USB 2.0 Ethernet, b6:c3:97:fe:06:71
[    4.905379] [drm:drm_edid_to_eld] ELD: no CEA Extension found
[    4.905380] [drm:intel_dp_drrs_init] VBT doesn't support DRRS
[    4.905385] [drm:intel_panel_setup_backlight] Connector eDP-1 backlight initialized, enabled, brightness 937/937

Regards,

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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Shubhangi Shrivastava]

On Friday 01 April 2016 01:11 PM, Ander Conselvan De Oliveira wrote:
> On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
>> == Series Details ==
>>
>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>> URL   : https://patchwork.freedesktop.org/series/5044/
>> State : success
> I pushed those to dinq.
>
> I fixed a couple of "Alignment should match open parenthesis" errors from
> checkpatch. I should have pointed those out during review, but I missed them.

Ohh.. Apology for the inconvenience caused..
Thanks for fixing these errors..

Shubhangi
>
> For future reference, in a expression like below,
>
> 	DRM_DEBUG_KMS("debug message %d",
> 		      number),
>
> the second line should be aligned with the opening '('.
>
> Ander
>

Sure.. Will ensure that in future patches..

Shubhangi
>> == Summary ==
>>
>> Series 5044v1 Series without cover letter
>> http://patchwork.freedesktop.org/api/1.0/series/5044/revisions/1/mbox/
>>
>> Test kms_pipe_crc_basic:
>>          Subgroup suspend-read-crc-pipe-c:
>>                  dmesg-warn -> PASS       (bsw-nuc-2)
>>
>> bdw-nuci7        total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12
>> bdw-ultra        total:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21
>> bsw-nuc-2        total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37
>> byt-nuc          total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35
>> hsw-brixbox      total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22
>> hsw-gt2          total:27   pass:24   dwarn:0   dfail:0   fail:0   skip:2
>> skl-i7k-2        total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23
>> skl-nuci5        total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11
>> snb-dellxps      total:79   pass:68   dwarn:0   dfail:0   fail:0   skip:10
>>
>> Results at /archive/results/CI_IGT_test/Patchwork_1753/
>>
>> 03c0f854e93263563f559d2bc8e47fb51adae697 drm-intel-nightly: 2016y-03m-31d-10h
>> -50m-15s UTC integration manifest
>> c448c6c059ae7bcdb7345feafd5324dd6dd164a7 drm/i915: force full detect on sink
>> count change
>> c1a69603958ccde4084f379f6c1a02314b8f5245 drm/i915: Read sink_count dpcd always
>> 5f91fb8d635f35130714bf60601948996ee976e3 drm/i915: Reorganizing
>> intel_dp_check_link_status
>> 950d50e19edac435bed7a08f6147af55cd2c8835 drm/i915: Cleaning up
>> intel_dp_hpd_pulse
>> 41fd654a2ac9ffc2d59ccf23511113b28f6271b1 drm/i915: Splitting intel_dp_detect
>>
>> _______________________________________________
>> 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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Jani Nikula]

On Mon, 04 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
> On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
>> On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
>>> == Series Details ==
>>>
>>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>>> URL   : https://patchwork.freedesktop.org/series/5044/
>>> State : success
>> 
>> I pushed those to dinq.
>
> This series seems to break eDP detection on BDW RVP.

I presume this is due to the sink count check. Can you add debug logging
to print intel_dp->sink_count after it's been read in
intel_dp_get_dpcd() please?

Then the question is, is this just because you have an RVP with who
knows what panel, or do we have to take into account potentially broken
panels too? Then I assume the fix would be to to ignore sink count for
eDP.

BR,
Jani.


>
> Old kernel:
>
> [    1.554183] [drm:intel_dp_init_connector] Adding eDP connector on port A
> [    1.554245] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 2000 t10 500 t11_t12 6000
> [    1.554254] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000
> [    1.554263] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 200, power down delay 50, power cycle delay 600
> [    1.554271] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, off delay 200
> [    1.554279] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
> [    1.554530] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
> [    1.554562] [drm:edp_panel_vdd_on] PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd000f
> [    1.556670] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
> [    1.557617] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, sink no
> [    1.557627] [drm:intel_dp_print_rates] source rates: 162000, 270000, 540000
> [    1.557633] [drm:intel_dp_print_rates] sink rates: 162000, 270000
> [    1.557638] [drm:intel_dp_print_rates] common rates: 162000, 270000
> [    1.557651] [drm:intel_dp_init_panel_power_sequencer_registers] panel power sequencer register settings: PP_ON 0x7d00001, PP_OFF 0x1f40001, PP_DIV 0x4af06
> [    1.567299] [drm:drm_edid_to_eld] ELD: no CEA Extension found
> [    1.567308] [drm:intel_dp_drrs_init] VBT doesn't support DRRS
> [    1.567319] [drm:intel_panel_setup_backlight] Connector eDP-1 backlight initialized, enabled, brightness 937/937
>
>
> Todays nightly:
>
> [    4.306321] [drm:intel_dp_init_connector] Adding eDP connector on port A
> [    4.306370] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 2000 t10 500 t11_t12 6000
> [    4.306371] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000
> [    4.306373] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 200, power down delay 50, power cycle delay 600
> [    4.306374] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, off delay 200
> [    4.306375] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
> [    4.306402] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
> [    4.306413] [drm:edp_panel_vdd_on] PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd000f
> [    4.319361] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
> [    4.331840] [drm] failed to retrieve link info, disabling eDP
> [    4.331862] [drm:edp_panel_vdd_off_sync] Turning eDP port A VDD off
>
> Series reverted:
>
> [    4.770004] [drm:intel_dp_init_connector] Adding eDP connector on port A
> [    4.777651] [drm:intel_dp_init_panel_power_sequencer] cur t1_t3 2000 t8 0 t9 2000 t10 500 t11_t12 6000
> [    4.788222] [drm:intel_dp_init_panel_power_sequencer] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000
> [    4.798890] [drm:intel_dp_init_panel_power_sequencer] panel power up delay 200, power down delay 50, power cycle delay 600
> [    4.811424] [drm:intel_dp_init_panel_power_sequencer] backlight on delay 1, off delay 200
> [    4.820705] [drm:intel_dp_aux_init] registering DPDDC-A bus for card0-eDP-1
> [    4.828631] [drm:edp_panel_vdd_on] Turning eDP port A VDD on
> [    4.835061] [drm:edp_panel_vdd_on] PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd000f
> [    4.843757] [drm:intel_dp_get_dpcd] DPCD: 11 0a 02 00 00 00 00 00 00 00 00 00 00 00 00
> [    4.853032] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source yes, sink no
> [    4.861624] [drm:intel_dp_print_rates] source rates: 162000, 270000, 540000
> [    4.869551] [drm:intel_dp_print_rates] sink rates: 162000, 270000
> [    4.876558] [drm:intel_dp_print_rates] common rates: 162000, 270000
> [    4.883812] [drm:intel_dp_init_panel_power_sequencer_registers] panel power sequencer register settings: PP_ON 0x7d00001, PP_OFF 0x1f40001, PP_DIV 0x4af06
> [    4.900522] asix 1-2:1.0 eth0: register 'asix' at usb-0000:00:14.0-2, ASIX AX88772 USB 2.0 Ethernet, b6:c3:97:fe:06:71
> [    4.905379] [drm:drm_edid_to_eld] ELD: no CEA Extension found
> [    4.905380] [drm:intel_dp_drrs_init] VBT doesn't support DRRS
> [    4.905385] [drm:intel_panel_setup_backlight] Connector eDP-1 backlight initialized, enabled, brightness 937/937
>
> Regards,
>
> Tvrtko
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Tvrtko Ursulin]

On 04/04/16 12:08, Jani Nikula wrote:
> On Mon, 04 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>> On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
>>> On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
>>>> == Series Details ==
>>>>
>>>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>>>> URL   : https://patchwork.freedesktop.org/series/5044/
>>>> State : success
>>>
>>> I pushed those to dinq.
>>
>> This series seems to break eDP detection on BDW RVP.
>
> I presume this is due to the sink count check. Can you add debug logging
> to print intel_dp->sink_count after it's been read in
> intel_dp_get_dpcd() please?

intel_dp->sink_count is zero here. (raw value, before the 
DP_GET_SINK_COUNT.)

Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage 
with not overly confident wording for the workaround there.

> Then the question is, is this just because you have an RVP with who
> knows what panel, or do we have to take into account potentially broken
> panels too? Then I assume the fix would be to to ignore sink count for
> eDP.

No idea. :)

Regards,

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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Tvrtko Ursulin]

On 04/04/16 12:41, Tvrtko Ursulin wrote:
>
> On 04/04/16 12:08, Jani Nikula wrote:
>> On Mon, 04 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> wrote:
>>> On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
>>>> On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
>>>>> == Series Details ==
>>>>>
>>>>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>>>>> URL   : https://patchwork.freedesktop.org/series/5044/
>>>>> State : success
>>>>
>>>> I pushed those to dinq.
>>>
>>> This series seems to break eDP detection on BDW RVP.
>>
>> I presume this is due to the sink count check. Can you add debug logging
>> to print intel_dp->sink_count after it's been read in
>> intel_dp_get_dpcd() please?
>
> intel_dp->sink_count is zero here. (raw value, before the
> DP_GET_SINK_COUNT.)
>
> Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage
> with not overly confident wording for the workaround there.
>
>> Then the question is, is this just because you have an RVP with who
>> knows what panel, or do we have to take into account potentially broken
>> panels too? Then I assume the fix would be to to ignore sink count for
>> eDP.
>
> No idea. :)

I could really use a solution for this. My only development platform is 
incapacitated unless I revert this series which, apart from the extra 
work when preparing and sending out patches this is taking, including 
lost time waiting on CI which I suspect dislikes patches from top of 
unknown bases, I think it won't be so easy to continue doing so when the 
conflicts start arriving. :(

Regards,

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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Jani Nikula]

On Wed, 06 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
> On 04/04/16 12:41, Tvrtko Ursulin wrote:
>>
>> On 04/04/16 12:08, Jani Nikula wrote:
>>> On Mon, 04 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>> wrote:
>>>> On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
>>>>> On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
>>>>>> == Series Details ==
>>>>>>
>>>>>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>>>>>> URL   : https://patchwork.freedesktop.org/series/5044/
>>>>>> State : success
>>>>>
>>>>> I pushed those to dinq.
>>>>
>>>> This series seems to break eDP detection on BDW RVP.
>>>
>>> I presume this is due to the sink count check. Can you add debug logging
>>> to print intel_dp->sink_count after it's been read in
>>> intel_dp_get_dpcd() please?
>>
>> intel_dp->sink_count is zero here. (raw value, before the
>> DP_GET_SINK_COUNT.)
>>
>> Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage
>> with not overly confident wording for the workaround there.
>>
>>> Then the question is, is this just because you have an RVP with who
>>> knows what panel, or do we have to take into account potentially broken
>>> panels too? Then I assume the fix would be to to ignore sink count for
>>> eDP.
>>
>> No idea. :)
>
> I could really use a solution for this. My only development platform is 
> incapacitated unless I revert this series which, apart from the extra 
> work when preparing and sending out patches this is taking, including 
> lost time waiting on CI which I suspect dislikes patches from top of 
> unknown bases, I think it won't be so easy to continue doing so when the 
> conflicts start arriving. :(

Ander, Shubhangi?

Would something like this be sensible? Tvrtko, can you give it a go?

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d29fda8..0890e71db188 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
 	 */
 	intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count);
 
+	if (is_edp(intel_dp))
+		intel_dp->sink_count = max(intel_dp->sink_count, 1);
+
 	/*
 	 * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
 	 * a dongle is present but no display. Unless we require to know

BR,
Jani.



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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Ander Conselvan De Oliveira]

On Thu, 2016-04-07 at 10:58 +0300, Jani Nikula wrote:
> On Wed, 06 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
> > On 04/04/16 12:41, Tvrtko Ursulin wrote:
> > > 
> > > On 04/04/16 12:08, Jani Nikula wrote:
> > > > On Mon, 04 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > > > wrote:
> > > > > On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
> > > > > > On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
> > > > > > > == Series Details ==
> > > > > > > 
> > > > > > > Series: series starting with [1/5] drm/i915: Splitting
> > > > > > > intel_dp_detect
> > > > > > > URL   : https://patchwork.freedesktop.org/series/5044/
> > > > > > > State : success
> > > > > > 
> > > > > > I pushed those to dinq.
> > > > > 
> > > > > This series seems to break eDP detection on BDW RVP.
> > > > 
> > > > I presume this is due to the sink count check. Can you add debug logging
> > > > to print intel_dp->sink_count after it's been read in
> > > > intel_dp_get_dpcd() please?
> > > 
> > > intel_dp->sink_count is zero here. (raw value, before the
> > > DP_GET_SINK_COUNT.)
> > > 
> > > Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage
> > > with not overly confident wording for the workaround there.
> > > 
> > > > Then the question is, is this just because you have an RVP with who
> > > > knows what panel, or do we have to take into account potentially broken
> > > > panels too? Then I assume the fix would be to to ignore sink count for
> > > > eDP.
> > > 
> > > No idea. :)
> > 
> > I could really use a solution for this. My only development platform is 
> > incapacitated unless I revert this series which, apart from the extra 
> > work when preparing and sending out patches this is taking, including 
> > lost time waiting on CI which I suspect dislikes patches from top of 
> > unknown bases, I think it won't be so easy to continue doing so when the 
> > conflicts start arriving. :(
> 
> Ander, Shubhangi?
> 
> Would something like this be sensible? Tvrtko, can you give it a go?
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index da0c3d29fda8..0890e71db188 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>  	 */
>  	intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count);
>  
> +	if (is_edp(intel_dp))
> +		intel_dp->sink_count = max(intel_dp->sink_count, 1);

I couldn't find anything in the spec that would make SINK_COUNT behave
differently for eDP, but eDP with 0 sinks simply doesn't make sense, so this
seems sensible to me.

Ander
>  	/*
>  	 * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
>  	 * a dongle is present but no display. Unless we require to know
> 
> BR,
> Jani.
> 
> 
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Thulasimani, Sivakumar]

On 4/7/2016 1:54 PM, Ander Conselvan De Oliveira wrote:
> On Thu, 2016-04-07 at 10:58 +0300, Jani Nikula wrote:
>> On Wed, 06 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>>> On 04/04/16 12:41, Tvrtko Ursulin wrote:
>>>> On 04/04/16 12:08, Jani Nikula wrote:
>>>>> On Mon, 04 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>>> wrote:
>>>>>> On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
>>>>>>> On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
>>>>>>>> == Series Details ==
>>>>>>>>
>>>>>>>> Series: series starting with [1/5] drm/i915: Splitting
>>>>>>>> intel_dp_detect
>>>>>>>> URL   : https://patchwork.freedesktop.org/series/5044/
>>>>>>>> State : success
>>>>>>> I pushed those to dinq.
>>>>>> This series seems to break eDP detection on BDW RVP.
>>>>> I presume this is due to the sink count check. Can you add debug logging
>>>>> to print intel_dp->sink_count after it's been read in
>>>>> intel_dp_get_dpcd() please?
>>>> intel_dp->sink_count is zero here. (raw value, before the
>>>> DP_GET_SINK_COUNT.)
>>>>
>>>> Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage
>>>> with not overly confident wording for the workaround there.
>>>>
>>>>> Then the question is, is this just because you have an RVP with who
>>>>> knows what panel, or do we have to take into account potentially broken
>>>>> panels too? Then I assume the fix would be to to ignore sink count for
>>>>> eDP.
>>>> No idea. :)
>>> I could really use a solution for this. My only development platform is
>>> incapacitated unless I revert this series which, apart from the extra
>>> work when preparing and sending out patches this is taking, including
>>> lost time waiting on CI which I suspect dislikes patches from top of
>>> unknown bases, I think it won't be so easy to continue doing so when the
>>> conflicts start arriving. :(
>> Ander, Shubhangi?
>>
>> Would something like this be sensible? Tvrtko, can you give it a go?
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index da0c3d29fda8..0890e71db188 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>>   	 */
>>   	intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count);
>>   
>> +	if (is_edp(intel_dp))
>> +		intel_dp->sink_count = max(intel_dp->sink_count, 1);
> I couldn't find anything in the spec that would make SINK_COUNT behave
> differently for eDP, but eDP with 0 sinks simply doesn't make sense, so this
> seems sensible to me.
>
> Ander
its possible that manufacturers might not have filled sink count dpcd 
registers.
i would prefer ignoring sink_count for edp rather than hardcoding 1 in 
case of edp.

Also just to be safe, we should add a similar check in short pulse 
handling too
where we check sink count.

Shubhangi, can you share a patch to handle this asap ?

regards,
Sivakumar
>>   	/*
>>   	 * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
>>   	 * a dongle is present but no display. Unless we require to know
>>
>> BR,
>> Jani.
>>
>>
>>

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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Tvrtko Ursulin]

On 07/04/16 08:58, Jani Nikula wrote:
> On Wed, 06 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>> On 04/04/16 12:41, Tvrtko Ursulin wrote:
>>>
>>> On 04/04/16 12:08, Jani Nikula wrote:
>>>> On Mon, 04 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>> wrote:
>>>>> On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
>>>>>> On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
>>>>>>> == Series Details ==
>>>>>>>
>>>>>>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
>>>>>>> URL   : https://patchwork.freedesktop.org/series/5044/
>>>>>>> State : success
>>>>>>
>>>>>> I pushed those to dinq.
>>>>>
>>>>> This series seems to break eDP detection on BDW RVP.
>>>>
>>>> I presume this is due to the sink count check. Can you add debug logging
>>>> to print intel_dp->sink_count after it's been read in
>>>> intel_dp_get_dpcd() please?
>>>
>>> intel_dp->sink_count is zero here. (raw value, before the
>>> DP_GET_SINK_COUNT.)
>>>
>>> Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage
>>> with not overly confident wording for the workaround there.
>>>
>>>> Then the question is, is this just because you have an RVP with who
>>>> knows what panel, or do we have to take into account potentially broken
>>>> panels too? Then I assume the fix would be to to ignore sink count for
>>>> eDP.
>>>
>>> No idea. :)
>>
>> I could really use a solution for this. My only development platform is
>> incapacitated unless I revert this series which, apart from the extra
>> work when preparing and sending out patches this is taking, including
>> lost time waiting on CI which I suspect dislikes patches from top of
>> unknown bases, I think it won't be so easy to continue doing so when the
>> conflicts start arriving. :(
>
> Ander, Shubhangi?
>
> Would something like this be sensible? Tvrtko, can you give it a go?
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index da0c3d29fda8..0890e71db188 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   	 */
>   	intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count);
>
> +	if (is_edp(intel_dp))
> +		intel_dp->sink_count = max(intel_dp->sink_count, 1);
> +
>   	/*
>   	 * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
>   	 * a dongle is present but no display. Unless we require to know

FWIW this patch fixes it on my BDW RVP.

I just had to change it to max_t since max has an issue with taking an 
address of const 1 by the look of it.

Regards,

Tvrtko

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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Shubhangi Shrivastava]

On Thursday 07 April 2016 03:26 PM, Thulasimani, Sivakumar wrote:
>
>
> On 4/7/2016 1:54 PM, Ander Conselvan De Oliveira wrote:
>> On Thu, 2016-04-07 at 10:58 +0300, Jani Nikula wrote:
>>> On Wed, 06 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> 
>>> wrote:
>>>> On 04/04/16 12:41, Tvrtko Ursulin wrote:
>>>>> On 04/04/16 12:08, Jani Nikula wrote:
>>>>>> On Mon, 04 Apr 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>>>> wrote:
>>>>>>> On 01/04/16 08:41, Ander Conselvan De Oliveira wrote:
>>>>>>>> On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote:
>>>>>>>>> == Series Details ==
>>>>>>>>>
>>>>>>>>> Series: series starting with [1/5] drm/i915: Splitting
>>>>>>>>> intel_dp_detect
>>>>>>>>> URL   : https://patchwork.freedesktop.org/series/5044/
>>>>>>>>> State : success
>>>>>>>> I pushed those to dinq.
>>>>>>> This series seems to break eDP detection on BDW RVP.
>>>>>> I presume this is due to the sink count check. Can you add debug 
>>>>>> logging
>>>>>> to print intel_dp->sink_count after it's been read in
>>>>>> intel_dp_get_dpcd() please?
>>>>> intel_dp->sink_count is zero here. (raw value, before the
>>>>> DP_GET_SINK_COUNT.)
>>>>>
>>>>> Also, intel_dp_dpcd_read_wake suggests a possibility for reading 
>>>>> garbage
>>>>> with not overly confident wording for the workaround there.
>>>>>
>>>>>> Then the question is, is this just because you have an RVP with who
>>>>>> knows what panel, or do we have to take into account potentially 
>>>>>> broken
>>>>>> panels too? Then I assume the fix would be to to ignore sink 
>>>>>> count for
>>>>>> eDP.
>>>>> No idea. :)
>>>> I could really use a solution for this. My only development 
>>>> platform is
>>>> incapacitated unless I revert this series which, apart from the extra
>>>> work when preparing and sending out patches this is taking, including
>>>> lost time waiting on CI which I suspect dislikes patches from top of
>>>> unknown bases, I think it won't be so easy to continue doing so 
>>>> when the
>>>> conflicts start arriving. :(
>>> Ander, Shubhangi?
>>>
>>> Would something like this be sensible? Tvrtko, can you give it a go?
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>>> b/drivers/gpu/drm/i915/intel_dp.c
>>> index da0c3d29fda8..0890e71db188 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>>>        */
>>>       intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count);
>>>   +    if (is_edp(intel_dp))
>>> +        intel_dp->sink_count = max(intel_dp->sink_count, 1);
>> I couldn't find anything in the spec that would make SINK_COUNT behave
>> differently for eDP, but eDP with 0 sinks simply doesn't make sense, 
>> so this
>> seems sensible to me.
>>
>> Ander
> its possible that manufacturers might not have filled sink count dpcd 
> registers.
> i would prefer ignoring sink_count for edp rather than hardcoding 1 in 
> case of edp.
>
> Also just to be safe, we should add a similar check in short pulse 
> handling too
> where we check sink count.
>
> Shubhangi, can you share a patch to handle this asap ?
>
> regards,
> Sivakumar

Shared the patch.. https://patchwork.freedesktop.org/patch/79924/

Shubhangi.

>>> /*
>>>        * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
>>>        * a dongle is present but no display. Unless we require to know
>>>
>>> BR,
>>> Jani.
>>>
>>>
>>>
>

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

Re: ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Joonas Lahtinen]

On to, 2016-04-07 at 11:00 +0100, Tvrtko Ursulin wrote:
> On 07/04/16 08:58, Jani Nikula wrote:
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index da0c3d29fda8..0890e71db188 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> >   	 */
> >   	intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count);
> > 
> > +	if (is_edp(intel_dp))
> > +		intel_dp->sink_count = max(intel_dp->sink_count, 1);

It should be max(intel_dp->sink_count, (u8)1)

Which is essentially the same as max_t(u8, ...)

> > +
> >   	/*
> >   	 * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
> >   	 * a dongle is present but no display. Unless we require to know
> FWIW this patch fixes it on my BDW RVP.
> 
> I just had to change it to max_t since max has an issue with taking an 
> address of const 1 by the look of it.

The problem is differing types, taking address of a constant is not a
problem, differing types when comparing pointers is.

The whole address taking line in max macro is there to make the pointer
type comparison at compile time.

Regards, joonas

> 
> Regards,
> 
> Tvrtko
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

[Patchwork]

== Summary ==

Series 2978v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/2978/revisions/1/mbox/

Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-a:
                incomplete -> PASS       (hsw-gt2)
        Subgroup suspend-read-crc-pipe-c:
                dmesg-warn -> PASS       (bsw-nuc-2)

bdw-nuci7        total:156  pass:147  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultra        total:159  pass:147  dwarn:0   dfail:0   fail:0   skip:12 
bsw-nuc-2        total:159  pass:129  dwarn:0   dfail:0   fail:0   skip:30 
byt-nuc          total:159  pass:136  dwarn:0   dfail:0   fail:0   skip:23 
hsw-brixbox      total:159  pass:146  dwarn:0   dfail:0   fail:0   skip:13 
hsw-gt2          total:159  pass:149  dwarn:0   dfail:0   fail:0   skip:10 
ilk-hp8440p      total:159  pass:111  dwarn:0   dfail:0   fail:0   skip:48 
ivb-t430s        total:159  pass:145  dwarn:0   dfail:0   fail:0   skip:14 
skl-i5k-2        total:159  pass:144  dwarn:1   dfail:0   fail:0   skip:14 
snb-dellxps      total:159  pass:137  dwarn:0   dfail:0   fail:0   skip:22 
snb-x220t        total:159  pass:137  dwarn:0   dfail:0   fail:1   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1335/

6b1049b84dcd979f631d15b2ada325d8e5b2c4e1 drm-intel-nightly: 2016y-01m-29d-22h-50m-57s UTC integration manifest
115af193cac6d62145809df8292fadbd3c370fb2 drm/i915: force full detect on sink count change
c8dced60ddfc26d53e37a7607767046880cc5178 drm/i915: Save sink_count for tracking changes to it and read sink_count dpcd always
9e65fb79da24330663dcbc888afeb61300507e71 drm/i915: Reorganizing intel_dp_check_link_status
c2e3381bf553cade9bbe15bc9f21d1677e8940e8 drm/i915: Cleaning up intel_dp_hpd_pulse
88fa9d50f75d5d5d939f49ce6441fd39c181acc2 drm/i915: Splitting intel_dp_detect

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