linux-kernel - Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 3 Jan 2018 10:23:15 +0100
From:   Stefan Brüns <stefan.bruens@...h-aachen.de>
To:     Jani Nikula <jani.nikula@...ux.intel.com>
CC:     Chris Wilson <chris@...is-wilson.co.uk>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        David Airlie <airlied@...ux.ie>,
        <intel-gfx@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>,
        <dri-devel@...ts.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

On Wednesday, January 3, 2018 8:14:47 AM CET Jani Nikula wrote:
> On Tue, 02 Jan 2018, Chris Wilson <chris@...is-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
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)