From: Stefan =?ISO-8859-1?Q?Br=FCns?= <stefan.bruens@rwth-aachen.de>
To: Jani Nikula <jani.nikula@linux.intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>,
        Rodrigo Vivi <rodrigo.vivi@intel.com>,
        David Airlie <airlied@linux.ie>,
        <intel-gfx@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
        <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read
Date: Wed, 3 Jan 2018 10:23:15 +0100
Message-ID: <2107557.Ofm5HlIVOH@pebbles>
In-Reply-To: <87vagj2z2w.fsf@intel.com>
References: <a39f080b-81a5-4c93-b3f7-7cb0a58daca3@rwthex-w2-a.rwth-ad.de> <151492106622.21495.250228197580562391@mail.alporthouse.com> <87vagj2z2w.fsf@intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1783230.TJn4caODh1";
        micalg=pgp-sha1; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org

--nextPart1783230.TJn4caODh1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

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)
> >=20
> >> On Sun, Dec 31, 2017 at 10:34:54PM +0000, Stefan Br=FCns wrote:
> >> > +     edid =3D 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 =3D drm_get_edid(connector, i2c);
> >> > +             intel_gmbus_force_bit(i2c, false);
> >> > +     }
> >>=20
> >> 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?>=20
> > 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.
> >=20
> > I would say that given the explanation above, the question is why not
> > apply it universally? (Bonus points for including the explanation as
> > comments.)
>=20
> 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=20
~2013 Haswell. The Haswell provides a 250..500ns hold time, the other does=
=20
not.

There is a flag in the GMBUS0 register, GMBUS_HOLD_EXT, "300ns hold time, r=
svd=20
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=20
anything older than Pineview.

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

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


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

Kind regards,

Stefan

=2D-=20
Stefan Br=FCns  /  Bergstra=DFe 21  /  52062 Aachen
home: +49 241 53809034     mobile: +49 151 50412019
--nextPart1783230.TJn4caODh1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQSwWRWIpJbl0W4DemNvf0o9jP6qUwUCWkyhAwAKCRBvf0o9jP6q
U8DgAJ0bcoZi+Fvfdw7mN+GidFpCMbx8ywCeKHt2mwclzbntXBWbxdyCuVFatIo=
=QP7E
-----END PGP SIGNATURE-----

--nextPart1783230.TJn4caODh1--