drm_do_probe_ddc_edid ENXIO check too aggressive?

[Daniel Vetter]

On Mon, Dec 16, 2013 at 10:47 PM, Daniel Drake <drake at endlessm.com> wrote:
> I'm using exynos_drm on Exynos4412 to output to a Sony HDMI TV.
>
> When I disconnect and then re-plug the TV, Exynos detects this event
> and tries to read the EDID from the DDC over I2C.
>
> The DDC does not provide an ACK at this point, so the i2c-s3c2410
> driver reports ENXIO, which seems to agree with the documentation:
>
> ENXIO
>     Returned by I2C adapters to indicate that the address phase
>     of a transfer didn't get an ACK.  While it might just mean
>     an I2C device was temporarily not responding, usually it
>     means there's nothing listening at that address.
>
> As of commit 9292f37e1f5c79400254dca46f83313488093825, DRM treats
> ENXIO as "no device, bail":
>
> Author: Eugeni Dodonov <eugeni.dodonov at intel.com>
> Date:   Thu Jan 5 09:34:28 2012 -0200
>
>     drm: give up on edid retries when i2c bus is not responding
>
> But in the case of my Sony TV it seems that we hit the "temporarily
> not responding" case, because if I insert a delay, the message gets
> acked and the EDID gets read successfully. Similarly, if I revert the
> patch so that we attempt the query a few times times, it succeeds on
> second retry.
>
> Any suggested solutions to this issue?

This usually happens if the hpd isn't properly recessed and we start
the i2c transaction while the physical connection hasn't been
established properly yet. If you're _really_ slow and careful you can
probably even break your current delay (presuming this theory is
correct).

At least on intel I've not yet heard of this, at least since we've
fixed up our code for this bug. We now only have the reverse problem,
where when you unplug the connector really slowly we'll miss the
unplug since the i2c slave still responded when the hpd interrupt
fired.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch