<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 4, 2015 at 7:47 AM Daniel Vetter <<a href="mailto:daniel@ffwll.ch">daniel@ffwll.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 04, 2015 at 06:56:14PM +0530, Sonika Jindal wrote:<br>
> The Bspec is very clear that Live status must be checked about before<br>
> trying to read EDID over DDC channel. This patch makes sure that HDMI<br>
> EDID is read only when live status us up.<br></blockquote><div><br></div><div>s/us/is</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> The live status doesn't seem to perform very consistent across various<br>
> platforms when tested with different monitors. The reason behind that is<br>
> some monitors are late to provide right voltage to set live_status up.<br>
> So, after getting the interrupt, for a small duration, live status reg<br>
> fluctuates, and then settles down showing the correct staus.<br>
><br>
> This is explained here in, in a rough way:<br>
> HPD line  ________________<br>
>                        |\ T1 = Monitor Hotplug causing IRQ<br>
>                        | \______________________________________<br>
>                        | |<br>
>                          | |<br>
>                        | |   T2 = Live status is stable<br>
>                        | |  _____________________________________<br>
>                        | | /|<br>
> Live status _____________|_|/ |<br>
>                        | |  |<br>
>                        | |  |<br>
>                        | |  |<br>
>                       T0 T1  T2<br>
><br>
> (Between T1 and T2 Live status fluctuates or can be even low, depending on<br>
>  the monitor)<br>
><br>
> After several experiments, we have concluded that a max delay<br>
> of 30ms is enough to allow the live status to settle down with<br>
> most of the monitors. This total delay of 30ms has been split into<br>
> a resolution of 3 retries of 10ms each, for the better cases.<br>
><br>
> This delay is kept at 30ms, keeping in consideration that, HDCP compliance<br>
> expect the HPD handler to respond a plug out in 100ms, by disabling the port.<br>
><br>
> v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions<br>
> to check digital port status. Adding a separate function to get bxt live<br>
> status (Daniel)<br>
> v3: Using intel_encoder->hpd_pin to check the live status (Siva)<br>
> Moving the live status read to intel_hdmi_probe and passing parameter<br>
> to read/not to read the edid. (me)<br>
> v4:<br>
> * Added live status check for all platforms using<br>
> intel_digital_port_connected.<br>
> * Rebased on top of Jani's DP cleanup series<br>
> * Some monitors take time in setting the live status. So retry for few<br>
> times if this is a connect HPD<br>
><br>
> Signed-off-by: Sonika Jindal <<a href="mailto:sonika.jindal@intel.com" target="_blank">sonika.jindal@intel.com</a>><br>
<br>
Really pretty commit message! Had some minor comments on two other patches<br>
in this series while reading through them, but looks good otherwise.<br>
Please sign up someone for final review of the details and I'll pull in<br>
the patches once that's done.<br>
-Daniel<br>
<br>
> ---<br>
>  drivers/gpu/drm/i915/intel_hdmi.c |   35 ++++++++++++++++++++++++++++-------<br>
>  1 file changed, 28 insertions(+), 7 deletions(-)<br>
><br>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c<br>
> index 1eda71a..d82887b 100644<br>
> --- a/drivers/gpu/drm/i915/intel_hdmi.c<br>
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c<br>
> @@ -1329,22 +1329,23 @@ intel_hdmi_unset_edid(struct drm_connector *connector)<br>
>  }<br>
><br>
>  static bool<br>
> -intel_hdmi_set_edid(struct drm_connector *connector)<br>
> +intel_hdmi_set_edid(struct drm_connector *connector, bool force)<br>
>  {<br>
>       struct drm_i915_private *dev_priv = to_i915(connector->dev);<br>
>       struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);<br>
>       struct intel_encoder *intel_encoder =<br>
>               &hdmi_to_dig_port(intel_hdmi)->base;<br>
>       enum intel_display_power_domain power_domain;<br>
> -     struct edid *edid;<br>
> +     struct edid *edid = NULL;<br>
>       bool connected = false;<br>
><br>
>       power_domain = intel_display_port_power_domain(intel_encoder);<br>
>       intel_display_power_get(dev_priv, power_domain);<br>
><br>
> -     edid = drm_get_edid(connector,<br>
> -                         intel_gmbus_get_adapter(dev_priv,<br>
> -                                                 intel_hdmi->ddc_bus));<br>
> +     if (force)<br></blockquote><div><br></div><div>The force name is confusing here since you only don't get edid in any other way when it is false...</div><div><br></div><div>But also there is the risk of this function to get called only with this false and never gets edid..</div><div>So I believe we should add a debug message here at least for this case so if we start getting cases where panel is taking more than 30ms to get live we will know why we did't actually read the edid....</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> +             edid = drm_get_edid(connector,<br>
> +                                 intel_gmbus_get_adapter(dev_priv,<br>
> +                                 intel_hdmi->ddc_bus));<br>
><br>
>       intel_display_power_put(dev_priv, power_domain);<br>
><br>
> @@ -1374,6 +1375,26 @@ void intel_hdmi_probe(struct intel_encoder *intel_encoder)<br>
>                       enc_to_intel_hdmi(&intel_encoder->base);<br>
>       struct intel_connector *intel_connector =<br>
>                               intel_hdmi->attached_connector;<br>
> +     struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev);<br>
> +     bool live_status = false;<br>
> +     unsigned int retry = 3;<br>
> +<br>
> +     live_status = intel_digital_port_connected(dev_priv,<br>
> +                                                hdmi_to_dig_port(intel_hdmi));<br>
> +     if (!intel_connector->detect_edid && live_status == false) {<br>
> +             /*<br>
> +              * Hotplug had occurred and old status was disconnected,<br>
> +              * so it might be possible that live status is not set,<br>
> +              * so retry for few times<br>
> +              */<br>
> +             do {<br>
> +                     mdelay(10);<br>
> +                     live_status = intel_digital_port_connected(dev_priv,<br>
> +                                             hdmi_to_dig_port(intel_hdmi));<br>
> +                     if (live_status)<br>
> +                             break;<br>
> +             } while (retry--);<br></blockquote><div><br></div><div>small and optional bikesheding here: I'd do:</div><div>while(!live_status && --retry) {</div><div> mdelay(10);</div><div>live_status = ...</div><div>}</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> +     }<br>
><br>
>       /*<br>
>        * We are here, means there is a hotplug or a force<br>
> @@ -1381,7 +1402,7 @@ void intel_hdmi_probe(struct intel_encoder *intel_encoder)<br>
>        * DDC bus to check the current status of HDMI.<br>
>        */<br>
>       intel_hdmi_unset_edid(&intel_connector->base);<br>
> -     if (intel_hdmi_set_edid(&intel_connector->base))<br>
> +     if (intel_hdmi_set_edid(&intel_connector->base, live_status))<br>
>               DRM_DEBUG_DRIVER("DDC probe: got EDID\n");<br>
>       else<br>
>               DRM_DEBUG_DRIVER("DDC probe: no EDID\n");<br>
> @@ -1432,7 +1453,7 @@ intel_hdmi_force(struct drm_connector *connector)<br>
>       if (connector->status != connector_status_connected)<br>
>               return;<br>
><br>
> -     intel_hdmi_set_edid(connector);<br>
> +     intel_hdmi_set_edid(connector, true);<br>
>       hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;<br>
>  }<br>
><br>
> --<br>
> 1.7.10.4<br>
><br>
> _______________________________________________<br>
> Intel-gfx mailing list<br>
> <a href="mailto:Intel-gfx@lists.freedesktop.org" target="_blank">Intel-gfx@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/intel-gfx" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/intel-gfx</a><br>
<br>
--<br>
Daniel Vetter<br>
Software Engineer, Intel Corporation<br>
<a href="http://blog.ffwll.ch" rel="noreferrer" target="_blank">http://blog.ffwll.ch</a><br>
_______________________________________________<br>
Intel-gfx mailing list<br>
<a href="mailto:Intel-gfx@lists.freedesktop.org" target="_blank">Intel-gfx@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/intel-gfx" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/intel-gfx</a><br>
</blockquote></div></div>