On Thu, Feb 28, 2019 at 02:32:38AM +0200, Souza, Jose wrote: > [...] > > > + * and then retrying the probe. > > > + */ > > > + if (state == INTEL_HOTPLUG_NOCHANGE && > > > + connector->base.status != connector_status_connected && > > > + irq_received && intel_port_is_tc(dev_priv, encoder->port) > > > && > > > + !dig_port->tc_legacy_port && !dig_port->dp.is_mst) > > > > Based on the investigation by Jani et al, we have the similar problem > > with > > HDMI, only during disconnect. So I think we could generalize by > > retrying > > any time there is no change (except for MST where the driver always > > keeps > > the connector in a disconnected state), regardless of the type of the > > sink, since a no-change is suspect in any case: why would the sink > > signal > > (with a long pulse) if there is no change? > > The only case that I can think of is the cases were sink do a short > pulse but we don't handle it in the short pulse handler and schedule a > long pulse handler but it should not cause any drawback retry everytime > there is no change in the state and irq_received is set. > > What comment could we add about the HDMI here? Something like this > would be fine? > > "HDMI sinks are reported as connected by hardware right after unpluging > it, so here also giving some time for hardware to process the unplug so > driver can read it and do the unplug sequence and notify userspace > about the absence of the HDMI sink"
It could be more specific, something like: On many platforms the HDMI live state signal is known to be unreliable, so we can't use it to detect if a sink is connected or not. Instead we detect if it's connected based on whether we can read the EDID or not. That in turn has a problem during disconnect, since the HPD interrupt may be raised before the DDC lines get disconnected (due to how the required length of DDC vs. HPD connector pins are specified) and so we'll still be able to get a valid EDID. To solve this schedule another detection cycle if this time around we didn't detect any change in the sink's connection status. > > > > > For HDMI we'd also need to handle this in intel_hdmi.c. > > It happens in older gens that don't have DDI? Otherwise just the update > above should take care of DP and HDMI DDI ports. I've been told it happens both on old and new HW. > > Then Ville suggested to add a Chamelium test for this to IGT, could > > you > > Jose look into that as well? Both the connect and disconnect races > > could > > be tested, both on HDMI and DP, by generating the HPD early/late wrt. > > to > > AUX/DDC starting/stopping to return valid data. I don't know if > > Chamelium can do this, you'd have to find that out first. > > I will try put my hands in a Chamelium board otherwise I will play with > trybot to add this tests. Okay, thanks. --Imre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
