[Intel-gfx] [PATCH 2/2] drm/i915/icl: Probe again type-c connectors that failed

[Souza, Jose]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20190313/68ad05fd/attachment.sig>