On Thu, 2019-02-28 at 18:06 +0200, Imre Deak wrote: > 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. Just sent the new kernel patches and the IGT test for the type-c bug, still working in the HDMI test. > > --Imre
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
