<div dir="ltr"><span style="font-size:12.8000001907349px">> Userspace always sets force. Are you sure this actually improves anything?</span><div>Yes we do. We have had this code for commercial projects, and that's really important to have proper interrupt handling as well as to avoid race condition between multiple HDMI detects from interrupt handler and userspace detect calls. This is a must for HDMI compliance also.</div><div><br></div><div>Actually the plan is to use this force for GEN < 6 HW only, where the hotplug doesn't work reliably (I remember our last conversation on some old HW which doesn't support HPD properly). For vlv+, we can (will) use only the cached EDID.</div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> Also the goal should be to keep things cache for a few calls from</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> userspace (since often it pokes a few times in a row unfortuantely), for</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> which we need a proper timeout to clear the edid again.</span></div><div><br></div><div>Can you please let us know why ? Why do we need to clear this EDID caching ? We should clear it only in the next hot-unplug, and maintain this cached EDID for all userspace detect operations. I believe as long as we have the state machine maintained, we need not to clear it. </div><div><br><span style="font-size:12.8000001907349px">>-Daniel</span><br></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Regards</span></div><div><span style="font-size:12.8000001907349px">Shashank</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 30, 2015 at 4:36 PM, Daniel Vetter <span dir="ltr"><<a href="mailto:daniel@ffwll.ch" target="_blank">daniel@ffwll.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Jun 30, 2015 at 11:13:58AM +0530, Sonika Jindal wrote:<br> > From: Shashank Sharma <<a href="mailto:contactshashanksharma@gmail.com">contactshashanksharma@gmail.com</a>><br> ><br> > This patch makes sure that the HDMI detect function<br> > reads EDID only when its forced to do it. All the other<br> > times, it uses the connector->detect_edid which was cached<br> > during hotplug handling in the hdmi_probe() function. As the<br> > probe function gets called before detect in the interrupt handler<br> > and handles the EDID cacheing part, its absolutely safe to assume<br> > that presence of EDID reflects monitor connected and viceversa.<br> ><br> > This will save us from many race conditions between hotplug/unplug<br> > detect call handler threads and userspace calls for the same.<br> > The previous patch in this patch series explains this in detail.<br> ><br> > Signed-off-by: Shashank Sharma <<a href="mailto:contactshashanksharma@gmail.com">contactshashanksharma@gmail.com</a>><br> > ---<br> > drivers/gpu/drm/i915/intel_hdmi.c | 26 ++++++++++++++++++++------<br> > 1 file changed, 20 insertions(+), 6 deletions(-)<br> ><br> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c<br> > index 064ddd8..1fb6919 100644<br> > --- a/drivers/gpu/drm/i915/intel_hdmi.c<br> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c<br> > @@ -1362,19 +1362,33 @@ static enum drm_connector_status<br> > intel_hdmi_detect(struct drm_connector *connector, bool force)<br> > {<br> > enum drm_connector_status status;<br> > + struct intel_connector *intel_connector =<br> > + to_intel_connector(connector);<br> ><br> > DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",<br> > connector-><a href="http://base.id" rel="noreferrer" target="_blank">base.id</a>, connector->name);<br> > + /*<br> > + * There are many userspace calls which probe EDID from<br> > + * detect path. In case on multiple hotplug/unplug, these<br> > + * can cause race conditions while probing EDID. Also its<br> > + * waste of CPU cycles to read the EDID again and again<br> > + * unless there is a real hotplug.<br> > + * So until we are forced, check connector status<br> > + * based on availability of cached EDID. This will avoid many of<br> > + * these race conditions and timing problems.<br> > + */<br> > + if (force)<br> <br> </div></div>Userspace always sets force. Are you sure this actually improves anything?<br> Also the goal should be to keep things cache for a few calls from<br> userspace (since often it pokes a few times in a row unfortuantely), for<br> which we need a proper timeout to clear the edid again.<br> -Daniel<br> <span class=""><br> > + intel_hdmi_probe(intel_connector->encoder);<br> ><br> > - intel_hdmi_unset_edid(connector);<br> > -<br> > - if (intel_hdmi_set_edid(connector)) {<br> > + if (intel_connector->detect_edid) {<br> > struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);<br> > -<br> > - hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;<br> > status = connector_status_connected;<br> > - } else<br> > + hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;<br> > + DRM_DEBUG_DRIVER("hdmi status = connected\n");<br> > + } else {<br> > status = connector_status_disconnected;<br> > + DRM_DEBUG_DRIVER("hdmi status = disconnected\n");<br> > + }<br> ><br> > return status;<br> > }<br> > --<br> > 1.7.10.4<br> ><br> </span>> _______________________________________________<br> > Intel-gfx mailing list<br> > <a href="mailto:Intel-gfx@lists.freedesktop.org">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> <span class="HOEnZb"><font color="#888888"><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> </font></span></blockquote></div><br></div>