[Intel-gfx] [PATCH] drm/i915: Update intel_dp_hpd_pulse() to check link status for non-MST operation

[Daniel Vetter]

On Thu, Mar 05, 2015 at 11:22:19AM -0700, Todd Previte wrote:
> Update the hot plug function to handle the SST case. Instead of placing
> the SST case within the long/short pulse block, it is now handled after
> determining that MST mode is not in use. This way, the topology management
> layer can handle any MST-related operations while SST operations are still
> correctly handled afterwards.
> 
> This patch also corrects the problem of SST mode only being handled in the
> case of a short (0.5ms - 1.0ms) HPD pulse. For compliance testing purposes
> both short and long pulses are used by the different tests, thus both cases
> need to be addressed for SST.
> 
> This patch replaces [PATCH 10/10] drm/i915: Fix intel_dp_hot_plug() in the
> previous compliance testing patch sequence. Review feedback on that patch
> indicated that updating intel_dp_hot_plug() was not the correct place for
> the test handler.
> 
> For the SST case, the main stream is disabled for long HPD pulses as this
> generally indicates either a connect/disconnect event or link failure. For
> a number of case in compliance testing, the source is required to disable
> the main link upon detection of a long HPD.
> 
> V2:
> - N/A
> V3:
> - Place the SST mode link status check into the mst_fail case
> - Remove obsolete comment regarding SST mode operation
> - Removed an erroneous line of code that snuck in during rebasing
> V4:
> - Added a disable of the main stream (DP transport) for the long pulse case
>   for SST to support compliance testing
> 
> Signed-off-by: Todd PRevite <tprevite at gmail.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 25 +++++++++++++++----------
>  1 file changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 080cc23..2460d14 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4618,16 +4618,6 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>  			if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
>  				goto mst_fail;
>  		}
> -
> -		if (!intel_dp->is_mst) {
> -			/*
> -			 * we'll check the link status via the normal hot plug path later -
> -			 * but for short hpds we should check it now
> -			 */
> -			drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> -			intel_dp_check_link_status(intel_dp);
> -			drm_modeset_unlock(&dev->mode_config.connection_mutex);
> -		}
>  	}
>  
>  	ret = IRQ_HANDLED;
> @@ -4639,6 +4629,21 @@ mst_fail:
>  		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);
> +	} else {
> +		/* SST mode - handle short/long pulses here */
> +		drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> +		/* Clear compliance testing flags/data here to prevent
> +		 * false detection in userspace */
> +		intel_dp->compliance_test_data = 0;
> +		intel_dp->compliance_testing_active = 0;
> +		/* For a long pulse in SST mode, disable the main link */
> +		if (long_hpd) {
> +			I915_WRITE(DP_TP_CTL(intel_dig_port->port),
> +					      ~DP_TP_CTL_ENABLE);
> +		}

Disabling the  main link should be done in userspace. All long pulse
requests should be forwarded to userspace as a hotplug event. Userspace
can then react to that hotplug appropriately. This way we can again
exercise the normal operation of all our dp code.

If otoh this is again a case where compliance requirements are so strict
that they don't allow any lee-way (I can't come up with a scenario really)
then I think this should be in a completely separate commit with the full
explanation in the commit message.
-Daniel

> +		intel_dp_check_link_status(intel_dp);
> +		drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +		ret = IRQ_HANDLED;
>  	}
>  put_power:
>  	intel_display_power_put(dev_priv, power_domain);
> -- 
> 1.9.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch