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

["Stefan Brüns" <stefan.bruens@rwth-aachen.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2728 bytes --]

On Wednesday, January 3, 2018 8:14:47 AM CET Jani Nikula wrote:
> 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)?

I have seen two different behaviours, one on the ~2009 GM965, the other on the 
~2013 Haswell. The Haswell provides a 250..500ns hold time, the other does 
not.

There is a flag in the GMBUS0 register, GMBUS_HOLD_EXT, "300ns hold time, rsvd 
on Pineview". The driver does not set this flag. Possibly it is always set/
implied on the Haswell (which is post-Pineview), and should be set for 
anything older than Pineview.

There is another odd fact with the GM965, according to the register setting it 
should run at 100 kBit/s, but it only runs at 30 kBit/s. The Haswell runs at 
100 kBit/s, as specified. As there are also idle periods ever 8 bytes, the 
EDID read takes 270ms before it fails.

The bitbanging code, running at 45 kBit/s (2 * 20us per clock cycle plus 
overhead) on the other hand just needs 58 ms, but keeps one core busy 
(udelay).


Unfortunately I currently have no older system than the Haswell available, so 
I can not check if the GMBUS_HOLD_EXT flag has any effect.

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034     mobile: +49 151 50412019

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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