On Thu, 16 Oct 2014, ville.syrjala@xxxxxxxxxxxxxxx wrote:
> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
>
> Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
> to handle hpd we would need to turn on vdd to perform aux transfers.
> This would lead to an endless cycle of
> "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..."
>
> So ignore long hpd pulses on eDP ports. eDP panels should be physically
> tied to the machine anyway so they should not actually disappear and
> thus don't need long hpd handling. Short hpds are still needed for link
> re-train and whatnot so we can't just turn off the hpd interrupt
> entirely for eDP ports. Perhaps we could turn it off whenever the panel
> is disabled, but just ignoring the long hpd seems sufficient.
Did you test this with my short vs. long hpd fix applied?
In any case, makes sense,
Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx>
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f07f02c..4455009 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4611,6 +4611,18 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
> if (intel_dig_port->base.type != INTEL_OUTPUT_EDP)
> intel_dig_port->base.type = INTEL_OUTPUT_DISPLAYPORT;
>
> + if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
> + /*
> + * vdd off can generate a long pulse on eDP which
> + * would require vdd on to handle it, and thus we
> + * would end up in an endless cycle of
> + * "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..."
> + */
> + DRM_DEBUG_KMS("ignoring long hpd on eDP port %c\n",
> + port_name(intel_dig_port->port));
> + return false;
> + }
> +
> DRM_DEBUG_KMS("got hpd irq on port %c - %s\n",
> port_name(intel_dig_port->port),
> long_hpd ? "long" : "short");
> --
> 2.0.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
