All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Thierry Reding <treding@nvidia.com>, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3] drm/dp: Use large transactions for I2C over AUX
Date: Wed, 28 Jan 2015 11:31:46 +0100	[thread overview]
Message-ID: <20150128103146.GX4764@phenom.ffwll.local> (raw)
In-Reply-To: <874mrbs24e.fsf@intel.com>

On Wed, Jan 28, 2015 at 11:09:21AM +0200, Jani Nikula wrote:
> On Tue, 27 Jan 2015, Simon Farnsworth <simon.farnsworth@onelan.co.uk> 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. 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.
> >
> > Also provide a module parameter for testing smaller transfer sizes, in case
> > there are sinks out there that cannot work with Windows.
> >
> > Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
> > ---
> >
> > v3 changes, after feedback from Ville and more testing of Windows:
> >
> >  * Change the short reply algorithm to match Ville's description of the
> >    DisplayPort 1.2 spec wording.
> >
> >  * Add a module parameter to set the default transfer size for
> >    experiments. Requested over IRC by Ville.
> 
> IMO module parameters are ABI we shouldn't add just because we might
> need them. Also see my reply in the other thread
> http://mid.gmane.org/877fw7s2lh.fsf@intel.com

Imo just marking it as _unsafe is good enough to make it clear that it's
for debugging only.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2015-01-28 10:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-27 15:43 [PATCH v3] drm/dp: Use large transactions for I2C over AUX Simon Farnsworth
2015-01-28  9:09 ` Jani Nikula
2015-01-28 10:31   ` Daniel Vetter [this message]
2015-01-29 13:30 ` Ville Syrjälä
2015-01-29 14:24   ` Simon Farnsworth
2015-01-29 14:36     ` Ville Syrjälä
2015-01-29 15:14       ` Simon Farnsworth
2015-01-30  6:11 ` Jani Nikula
2015-01-30 18:45 ` Ville Syrjälä
2015-02-02 11:16   ` 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=20150128103146.GX4764@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --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.