From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Cc: Thierry Reding <treding@nvidia.com>, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/dp: Use large transactions for I2C over AUX
Date: Mon, 26 Jan 2015 18:11:01 +0200 [thread overview]
Message-ID: <20150126161101.GC19354@intel.com> (raw)
In-Reply-To: <1540451.drLVq8Y4Zh@f19simon>
On Mon, Jan 26, 2015 at 03:47:13PM +0000, Simon Farnsworth wrote:
> 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.
In my copy if DP v1.1 the example in 2-50 just keeps repeating w/ 16 bytes.
So doesn't match what you do. And that's unchanged in v1.2.
DP v1.2 has some extra clarifications for this stuff:
"2.7.7 I2C-overAUX Transaction Clarifications and Implementation Rules
2.7.7.1.6.4 Upon the Reply of I2C_ACK|AUX_ACK Followed by the Total Number of Data
Bytes Fewer than LEN+1, to a Request Transaction with MOT Bit Set Either to 0 or 1
The Source device must:
o Repeat the identical I2C-read-over-AUX transaction with the updated
LEN value equal to the original LEN value minus the total number of data
bytes received so far,
o Repeat the identical I2C-read-over-AUX transaction with the same LEN
value as the original value, or,
o Issue an address-only I2C-over-AUX with MOT bit set to 0 to prompt I2C STOP
to terminate the current I2C-read-over-AUX transaction.
It should be noted that when the Source device repeats the same I2C-read-over-AUX
transaction with the same LEN value as the original value, the Sink device is
likely to read more data bytes than the Source device needs."
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-01-26 16:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-26 15:22 [PATCH] drm/dp: Use large transactions for I2C over AUX Simon Farnsworth
2015-01-26 15:33 ` Ville Syrjälä
2015-01-26 15:47 ` Simon Farnsworth
2015-01-26 16:11 ` Ville Syrjälä [this message]
2015-01-26 16:39 ` Simon Farnsworth
2015-01-27 13:36 ` Ville Syrjälä
2015-01-28 8:59 ` Jani Nikula
2015-01-28 9:10 ` Daniel Vetter
2015-01-28 9:33 ` Jani Nikula
2015-01-28 10:30 ` Daniel Vetter
2015-01-28 10:45 ` Simon Farnsworth
2015-01-26 16:00 ` Ville Syrjälä
-- strict thread matches above, loose matches on Subject: below --
2015-02-10 18:38 Simon Farnsworth
2015-02-10 18:42 ` Simon Farnsworth
2015-02-11 5:36 ` Dave Airlie
2015-02-11 7:25 ` Daniel Vetter
2015-02-11 8:13 ` Jani Nikula
2015-02-11 12:05 ` Ville Syrjälä
2015-03-11 19:28 ` Ville Syrjälä
2015-03-11 21:06 ` Daniel Vetter
2015-01-23 18:40 Simon Farnsworth
2015-01-23 19:46 ` Ville Syrjälä
2015-01-23 21:21 ` Thierry Reding
2015-01-24 11:27 ` Daniel Vetter
2015-01-26 9:50 ` Simon Farnsworth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150126161101.GC19354@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=simon.farnsworth@onelan.co.uk \
--cc=treding@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.