From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan =?ISO-8859-1?Q?Br=FCns?= Subject: Re: [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> References: <151492106622.21495.250228197580562391@mail.alporthouse.com> <87vagj2z2w.fsf@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2002317277==" Return-path: In-Reply-To: <87vagj2z2w.fsf@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Jani Nikula Cc: David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Rodrigo Vivi List-Id: intel-gfx@lists.freedesktop.org --===============2002317277== Content-Type: multipart/signed; boundary="nextPart1783230.TJn4caODh1"; micalg=pgp-sha1; protocol="application/pgp-signature" --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 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-- --===============2002317277== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============2002317277==--