Re: [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

[Jani Nikula <jani.nikula@linux.intel.com>]

On Tue, 02 Jan 2018, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Rodrigo Vivi (2018-01-02 19:12:18)
>> On Sun, Dec 31, 2017 at 10:34:54PM +0000, Stefan Brüns wrote:
>> > +     edid = drm_get_edid(connector, i2c);
>> > +
>> > +     if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
>> > +             DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO bit-banging\n");
>> > +             intel_gmbus_force_bit(i2c, true);
>> > +             edid = drm_get_edid(connector, i2c);
>> > +             intel_gmbus_force_bit(i2c, false);
>> > +     }
>> 
>> Approach seems fine for this case.
>> I just wonder what would be the risks of forcing this bit and edid read when nothing is present on the other end?
>
> Should be no more risky than using GMBUS as the bit-banging is the
> underlying HW protocol; it should just be adding an extra delay to
> the disconnected probe. Offset against the chance that it fixes
> detection of borderline devices.
>
> I would say that given the explanation above, the question is why not
> apply it universally? (Bonus points for including the explanation as
> comments.)

I'm wondering, is gmbus too fast for the adapters, does gmbus generally
have different timing for the ack/nak as described in the commit message
than bit banging, or are the adapters just plain buggy? Do we have any
control over gmbus timings (don't have the time to peruse the bpsec just
now)?

BR,
Jani.

> -Chris
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx