Re: [PATCH] drm/dp: Use large transactions for I2C over AUX

[Simon Farnsworth <simon.farnsworth@onelan.co.uk>]

[-- Attachment #1.1: Type: text/plain, Size: 2604 bytes --]

On Monday 26 January 2015 17:33:35 Ville Syrjälä 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 bugs in
> > their I2C over AUX implementation. They work fine with Windows, but fail
> > with Linux.
> > 
> > It turns out that they cannot keep an I2C transaction open unless the
> > previous read was 16 bytes; shorter reads can only be followed by a zero
> > byte transfer ending the I2C transaction.
> > 
> > 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 read size
> > to match.
> > 
> > Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
> > ---
> > 
> > v2 changes, after feedback from Thierry and Ville:
> > 
> >  * Handle short replies. I've decided (arbitrarily) that a short reply
> >    results in us dropping back to the newly chosen size for the rest of this
> >    I2C transaction. Thus, given an attempt to read the first 16 bytes of
> >    EDID, and a sink that only does 4 bytes of buffering, we will see the
> >    following AUX transfers for the EDID read (after address is set):
> > 
> >    <set address, block etc>
> >    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
> >    <end I2C transaction>
> 
> I think that's agaisnt the spec. IIRC you have to keep repeating the
> same transaction (meaning address/len are unchanged) until all the data
> 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 never
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 check 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.
> >
--snip code--
-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel