From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Farnsworth Subject: Re: [PATCH] drm/dp: Use large transactions for I2C over AUX Date: Mon, 26 Jan 2015 15:47:13 +0000 Message-ID: <1540451.drLVq8Y4Zh@f19simon> References: <1422285768-1655-1-git-send-email-simon.farnsworth@onelan.co.uk> <20150126153335.GA19354@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0670608986==" Return-path: Received: from claranet-outbound-smtp00.uk.clara.net (claranet-outbound-smtp00.uk.clara.net [195.8.89.33]) by gabe.freedesktop.org (Postfix) with ESMTP id BA79289B46 for ; Mon, 26 Jan 2015 07:47:21 -0800 (PST) In-Reply-To: <20150126153335.GA19354@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 --===============0670608986== Content-Type: multipart/signed; boundary="nextPart2460248.lI9xxPSaJL"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart2460248.lI9xxPSaJL Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Monday 26 January 2015 17:33:35 Ville Syrj=E4l=E4 wrote: > On Mon, Jan 26, 2015 at 03:22:48PM +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. > >=20 > > Signed-off-by: Simon Farnsworth > > --- > >=20 > > v2 changes, after feedback from Thierry and Ville: > >=20 > > * Handle short replies. I've decided (arbitrarily) that a short re= ply > > results in us dropping back to the newly chosen size for the res= t of this > > I2C transaction. Thus, given an attempt to read the first 16 byt= es of > > EDID, and a sink that only does 4 bytes of buffering, we will se= e the > > following AUX transfers for the EDID read (after address is set)= : > >=20 > > > > Read 16 bytes from I2C over AUX. > > Reply with 4 bytes > > Read 4 bytes > > Reply with 4 bytes > > Read 4 bytes > > Reply with 4 bytes > > Read 4 bytes > > Reply with 4 bytes > > >=20 > I think that's agaisnt the spec. IIRC you have to keep repeating the > same transaction (meaning address/len are unchanged) until all the da= ta > was transferred. > Do you have a spec reference against the DisplayPort 1.1a (last public version) spec? My chosen behaviour matches Table 2-50 in the 1.1a spec.= I can't see anything in section 2.4.5 (I2C over AUX) that prohibits me = from changing the length or address mid-transaction, and there is text that = says that when the address changes without the source clearing the MOT bit, = the sink should do an I2C Repeated Start to change address. The length is n= ever supplied to the I2C bus - it's purely an artifact of DisplayPort. > > Note that I've not looked at MST support - I have neither the DP 1.= 2 spec > > nor any MST branch devices, so I can't test anything I write or che= ck it > > against a spec. It looks from the code, however, as if MST has the = branch > > device do the split from a big request into small transactions. > > =2D-snip code-- =2D-=20 Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com --nextPart2460248.lI9xxPSaJL 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 iQEcBAABAgAGBQJUxmGEAAoJEOsKZy3xM+c7REAH/RcNISyeDANsTjjeRRwVV0up 7h2rXWYiQUbpFCEN6fTo9tWxfOLiSZg8qxCybsje+Z7h2kWPgHWX4bz3MDwqxMho asdIRLDxbTfrwr1+WNJY+0DJxvHChovVXg8FDiYHjcaoGZgZzP6f9NcTM1RlzNbH Csxpag3c9A8T41qa0Gn8AcEer33N/OvuYB/MezNSEZ8Y/ZmF1iUrQO2EQanoJTwN Tt1tG6aki4HwxIBWP9JxP05s04oRwWeZVKPDi7EFEPdleB7JDmUKWRAvcNvO/H7S LsKYBvgV1OQOvQG1yAH/9tyZ8oe3zlR4lOUMiMknVHW368+i3atXS7MoYZCEW/U= =C5Ol -----END PGP SIGNATURE----- --nextPart2460248.lI9xxPSaJL-- --===============0670608986== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0670608986==--