From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Farnsworth Subject: Re: [PATCH v3] drm/dp: Use large transactions for I2C over AUX Date: Mon, 02 Feb 2015 11:16:22 +0000 Message-ID: <8916844.35s4qX6xYm@f19simon> References: <1422373429-10137-1-git-send-email-simon.farnsworth@onelan.co.uk> <20150130184528.GD19354@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0578679326==" Return-path: Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by gabe.freedesktop.org (Postfix) with ESMTP id 5249D6E3E9 for ; Mon, 2 Feb 2015 03:16:33 -0800 (PST) In-Reply-To: <20150130184528.GD19354@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= Cc: Thierry Reding , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0578679326== Content-Type: multipart/signed; boundary="nextPart7592359.4XBAAPsgAx"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart7592359.4XBAAPsgAx Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Friday 30 January 2015 20:45:28 Ville Syrj=E4l=E4 wrote: > On Tue, Jan 27, 2015 at 03:43:49PM +0000, Simon Farnsworth wrote: > > DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bu= gs in > > their I2C over AUX implementation. They work fine with Windows, but= fail > > with Linux. > >=20 > > It turns out that they cannot keep an I2C transaction open unless t= he > > previous read was 16 bytes; shorter reads can only be followed by a= zero > > byte transfer ending the I2C transaction. > >=20 > > Copy Windows's behaviour, and read 16 bytes at a time. If we get a = short > > reply, assume that there's a hardware bottleneck, and shrink our re= ad size > > to match. For this purpose, use the algorithm in the DisplayPort 1.= 2 spec, > > in the hopes that it'll be closest to what Windows does, as no sink= I've > > found actually gives short replies. > >=20 > > Also provide a module parameter for testing smaller transfer sizes,= in case > > there are sinks out there that cannot work with Windows. > >=20 > > Signed-off-by: Simon Farnsworth > > --- > >=20 > > v3 changes, after feedback from Ville and more testing of Windows: > >=20 > > * Change the short reply algorithm to match Ville's description of= the > > DisplayPort 1.2 spec wording. > >=20 > > * Add a module parameter to set the default transfer size for > > experiments. Requested over IRC by Ville. > >=20 > > No-one's been able to find a device that does short replies, but ex= periments > > show that bigger reads are faster on most devices. Ville got: > >=20 > > DP->DVI (OUI 001cf8): 40ms -> 35ms > > DP->VGA (OUI 0022b9): 45ms -> 38ms > > Zotac DP->2xHDMI: 25ms -> 4ms >=20 > Another datapoint: > Asus PB278 monitor: 22ms -> 3ms >=20 > I've been pondering about these massive improvements for the Zotac an= d > Asus. After reading the DP spec a bit more I've noticed just how wast= eful > AUX is. If my understanding of the spec and arithmetic aren't totally= off, > the effective bandwidth for EDID reads is ~400kbps when using 16 byte= AUX > messages, but it drops to only ~60kbps when doing 1 byte AUX messages= . > Those seem to match reasonably well with my measurements. I never rea= lized > just how slow it can be since the 1Mbps number feels like plenty, and= no > one ever seems to mention the effective bandwidth. > Doing the maths myself, to see if you're in the right ballpark: Each AUX message has 24 bits worth of SYNC/STOP overhead, and between 1= 0 and 16 bits of precharge overhead. You've got 32 bits of data in the request. In the reply, you have 8 ove= rhead bits, and however many bits of data you requested. Each request therefore takes 66 to 72 bits to make. A reply has 42 to 4= 8 bits of overhead, plus the bits you requested. This makes 108 to 120 bi= ts of overhead for each I2C transfer. At one byte per request, we're using 116 to 128 bit times for every EDI= D byte. This is 14.5 to 16 bit times per payload bit transferred, for a payload bit rate on a 1 MHz channel between 62.5 kbit/s and 69.0 kbit/s= . At 16 bytes per request, we're using 236 to 248 bit times for every 16 = bytes of EDID. This is 1.84 to 1.94 bit times per payload bit transferred, fo= r a payload bit rate between 516.1 kbit/s and 542.3 kbit/s. =2D-=20 Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com --nextPart7592359.4XBAAPsgAx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUz1yJAAoJEOsKZy3xM+c7edwIAIMyJYS/vSEqLBKimUQ5OJdD ITU7lWu9eCkg2e0JLi+A9HR21BeD8jt1Rz3BkvPvDg8LpweMXgmlBYYqxZ+avPzn fEN0ydmEry8/+NE/5bESWKQIT/f4bamA/WrtK7uUmnuJ4vgT093w7v8LHO8Zn/dE BEIWxA6TDuANHgiYPQhlFINt3UU9xJpPkLmtnpATT0s5Z2o0cWK87nL0GVQzFt4M Y7qdU+TR8VqJiqSSrDHIHHYfpwFcx9Ig+gTh4iRc1bOxS8Qtv4gm3EUbqiX2bgID ihjXEZRU6ESJCSvuB1LYfb//DW8xYR+E3HxktmjGj0ChevVE9k5OKLUnC5qhfjY= =Zvmw -----END PGP SIGNATURE----- --nextPart7592359.4XBAAPsgAx-- --===============0578679326== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0578679326==--