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@xxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
