All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Daniel Kurtz <djkurtz@chromium.org>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Benson Leung <bleung@chromium.org>
Subject: Re: [PATCH] drm/i915: Fix single msg gmbus_xfers writes
Date: Mon, 20 Feb 2012 14:30:40 +0100	[thread overview]
Message-ID: <20120220133040.GC4104@phenom.ffwll.local> (raw)
In-Reply-To: <CAGS+omD8e9dBen_kQkoY+vc4yP6HCAeoNRYhzK+OPw+99HDoFg@mail.gmail.com>

On Mon, Feb 20, 2012 at 07:22:00PM +0800, Daniel Kurtz wrote:
> On Feb 15, 2012 6:48 PM, "Daniel Vetter" <daniel@ffwll.ch> wrote:
> >
> > On Thu, Feb 09, 2012 at 12:03:17PM -0800, Benson Leung wrote:
> > > gmbus_xfer with a single message (particularly a single message write) would
> > > set Bus Cycle Select to 100b, the Gen Stop cycle, instead of 101b,
> > > No Index, Stop cycle. This would not start single message i2c transactions.
> > >
> > > Also, gmbus_xfer done: will disable the interface without checking if
> > > it is idle. In the case of writes, there will be no wait on status or delay
> > > to ensure the write starts and completes before the interface is turned off.
> > >
> > > Fixed the former issue by using the same cycle selection as used in the
> > > I2C_M_RD for the write case.
> > > GMBUS_CYCLE_WAIT | (i + 1 == num ? GMBUS_CYCLE_STOP : 0)
> > > Fixed the latter by waiting on GMBUS_ACTIVE to deassert before disable.
> > >
> > > Signed-off-by: Benson Leung <bleung@chromium.org>
> 
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> 
> >
> > Can you clarify the commit message a bit and say that the first hunk is
> > just for optics and the issue is only with the write path (because the
> > read path is correct already). Silly me is just to easily confused ;-)
> >
> > Btw, I've reworked the gmbus -> gpio bit-banging fallback code a bit and
> > if that passes review and all I'll reenable gmbus by default again. See
> >
> > http://cgit.freedesktop.org/~danvet/drm/log/?h=gmbus
> 
> If the write case is fixed by Benson's patch, is there any known use
> case that still requires i2c bit banging on these pins?  It would be a
> nice cleanup to remove it completely.

Let's first see how much things blow up when re-enabling gmbus again ;-)

> Also, I can think of at least two further potential performance
> improvements that I was wondering if anybody has yet pursued:
>   (1) Enabling the i915's gmbus interrupt.  This would eliminate the
> need for the (relatively slow) wait_for polling loop.
>   (2) Taking advantage of the i915's "INDEX" cycles to combine writing
> a (1 or 2 byte) address & reading back an array of bytes into a single
> transaction.

Afaik no one looked into this, but patches are highly welcome.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Daniel Kurtz <djkurtz@chromium.org>
Cc: Benson Leung <bleung@chromium.org>,
	keithp@keithp.com, airlied@linux.ie, chris@chris-wilson.co.uk,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Fix single msg gmbus_xfers writes
Date: Mon, 20 Feb 2012 14:30:40 +0100	[thread overview]
Message-ID: <20120220133040.GC4104@phenom.ffwll.local> (raw)
In-Reply-To: <CAGS+omD8e9dBen_kQkoY+vc4yP6HCAeoNRYhzK+OPw+99HDoFg@mail.gmail.com>

On Mon, Feb 20, 2012 at 07:22:00PM +0800, Daniel Kurtz wrote:
> On Feb 15, 2012 6:48 PM, "Daniel Vetter" <daniel@ffwll.ch> wrote:
> >
> > On Thu, Feb 09, 2012 at 12:03:17PM -0800, Benson Leung wrote:
> > > gmbus_xfer with a single message (particularly a single message write) would
> > > set Bus Cycle Select to 100b, the Gen Stop cycle, instead of 101b,
> > > No Index, Stop cycle. This would not start single message i2c transactions.
> > >
> > > Also, gmbus_xfer done: will disable the interface without checking if
> > > it is idle. In the case of writes, there will be no wait on status or delay
> > > to ensure the write starts and completes before the interface is turned off.
> > >
> > > Fixed the former issue by using the same cycle selection as used in the
> > > I2C_M_RD for the write case.
> > > GMBUS_CYCLE_WAIT | (i + 1 == num ? GMBUS_CYCLE_STOP : 0)
> > > Fixed the latter by waiting on GMBUS_ACTIVE to deassert before disable.
> > >
> > > Signed-off-by: Benson Leung <bleung@chromium.org>
> 
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> 
> >
> > Can you clarify the commit message a bit and say that the first hunk is
> > just for optics and the issue is only with the write path (because the
> > read path is correct already). Silly me is just to easily confused ;-)
> >
> > Btw, I've reworked the gmbus -> gpio bit-banging fallback code a bit and
> > if that passes review and all I'll reenable gmbus by default again. See
> >
> > http://cgit.freedesktop.org/~danvet/drm/log/?h=gmbus
> 
> If the write case is fixed by Benson's patch, is there any known use
> case that still requires i2c bit banging on these pins?  It would be a
> nice cleanup to remove it completely.

Let's first see how much things blow up when re-enabling gmbus again ;-)

> Also, I can think of at least two further potential performance
> improvements that I was wondering if anybody has yet pursued:
>   (1) Enabling the i915's gmbus interrupt.  This would eliminate the
> need for the (relatively slow) wait_for polling loop.
>   (2) Taking advantage of the i915's "INDEX" cycles to combine writing
> a (1 or 2 byte) address & reading back an array of bytes into a single
> transaction.

Afaik no one looked into this, but patches are highly welcome.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2012-02-20 13:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-09 20:03 [PATCH] drm/i915: Fix single msg gmbus_xfers writes Benson Leung
2012-02-13 20:38 ` Daniel Vetter
2012-02-13 21:49   ` Chris Wilson
2012-02-13 22:26     ` Daniel Vetter
2012-02-13 22:26       ` Daniel Vetter
2012-02-14  9:35       ` Chris Wilson
2012-02-14  9:35         ` Chris Wilson
2012-02-15 10:48 ` Daniel Vetter
2012-02-20 11:22   ` Daniel Kurtz
2012-02-20 13:30     ` Daniel Vetter [this message]
2012-02-20 13:30       ` Daniel Vetter
2012-02-29 19:12     ` Daniel Vetter

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=20120220133040.GC4104@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=bleung@chromium.org \
    --cc=djkurtz@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.