[Intel-gfx] [PATCH 3/3] drm/i915: Displayport compliance test 4.2.2.8 support

[Daniel Vetter]

On Tue, Jun 09, 2015 at 05:22:20PM -0700, Todd Previte wrote:
> Adds support for the test 4.2.2.8 EDID read on IRQ_HPD event after
> Branch Device Detection in the Displayport Link CTS Core 1.2 rev1.1.
> This test checks to see that the source device reads the EDID from
> the attached sink device upon detection of a downstream port. A short
> pulse is generated by the sink device to indicate a status change in
> the downstream ports to which the source device must respond by
> reading the EDID from the attached sink.
> 
> Since this is a test that occurs during a short pulse instead of a
> long pulse, the normal EDID read that occurs during the call to
> intel_dp_detect() does happen. Currently this read must be placed here
> in order to pass the compliance tests. However, the EDID data from
> this read is discarded at this time. In the future, this EDID read
> may be used for other purposes and can be stored as necessary at that
> time should be need arise.
> 
> Signed-off-by: Todd Previte <tprevite at gmail.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 697857a..99d2e81 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4220,6 +4220,14 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>  		if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
>  			DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
>  	}
> +	/* Displayport Link CTS 1.2a rev1.1
> +	 *      4.2.2.8 : Check for downstream port status change
> +	 */
> +	if (link_status[2] & DP_DOWNSTREAM_PORT_STATUS_CHANGED) {
> +		struct edid *edid_read = NULL;
> +		edid_read = drm_get_edid(&intel_dp->attached_connector->base,
> +					 &intel_dp->aux.ddc);

This smells like papering over a bug in our dp implementation again.
Assuming we correctly handle the hpd for this case of a downstream port
change then userspace should receive the uevent, which should result in an
edid read.

If that doesn't happen then we have again a bug somewhere in our dp code
that needs to be address properly. Just reading the edid and then throwing
it away isn't it.
-Daniel

> +	}
>  
>  	if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
>  		DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
> -- 
> 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
http://blog.ffwll.ch