All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kurtz <djkurtz@chromium.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Naveen Krishna Chatradhi <ch.naveen@samsung.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org,
	Linux I2C <linux-i2c@vger.kernel.org>,
	Ben Dooks <ben-linux@fluff.org>,
	kgene.kim@samsung.com, Jean Delvare <khali@linux-fr.org>,
	Wolfram Sang <w.sang@pengutronix.de>,
	naveenkrishna.ch@gmail.com
Subject: Re: [PATCH 3/4] i2c-s3c2410: use exponential back off while polling for bus idle
Date: Tue, 20 Nov 2012 16:57:16 +0800	[thread overview]
Message-ID: <CAGS+omCKm+aN9ZXApmQJh1OrST-t2sA8WP7NyDOzKnv-xqJ5vg@mail.gmail.com> (raw)
In-Reply-To: <20121120044859.GA10154@sirena.org.uk>

Hi Mark,

On Tue, Nov 20, 2012 at 12:49 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> On Thu, Nov 15, 2012 at 05:43:32PM +0530, Naveen Krishna Chatradhi wrote:
>
> > +     iicstat = readl(i2c->regs + S3C2410_IICSTAT);
> > +     delay = 1;
> > +     while ((iicstat & S3C2410_IICSTAT_START) &&
> > +            ktime_us_delta(now, start) < S3C2410_IDLE_TIMEOUT) {
> > +             usleep_range(delay, 2 * delay);
> > +             if (delay < S3C2410_IDLE_TIMEOUT / 10)
> > +                     delay <<= 1;
> > +             now = ktime_get();
> > +             iicstat = readl(i2c->regs + S3C2410_IICSTAT);
> > +     }
>
> > -     /* first, try busy waiting briefly */
> > -     do {
> > -             cpu_relax();
> > -             iicstat = readl(i2c->regs + S3C2410_IICSTAT);
> > -     } while ((iicstat & S3C2410_IICSTAT_START) && --spins);
>
> On the hardware I was using when I wrote the original code here we were
> hitting 1-2 spins often enough to be interesting - starting off with a
> direct busy wait was definitely useful when doing large batches of I/O,
> especially compared to sleeps which might cause us to schedule.

We check the status first to avoid any sleep()/schedule() in the case,
that the CPU is slower than I2C transaction.
Remember, this loop only happens after the event_wait loop has been
woken up by the i2c irq.
Since you are talking about hitting a tiny window of time at some
arbitrary point after an irq, the CPU time to this point & I2C
finishing would have to be very precisely aligned for the 1-2 loops
(at CPU clock rate) to matter.

HTH,
-Dan

>
> > -     /* if that timed out sleep */
> > -     if (!spins) {
> > -             msleep(1);
> > -             iicstat = readl(i2c->regs + S3C2410_IICSTAT);
> > -     }
>
> It seems like it'd be better to do the exponential backoff bit here
> instead of removing the busy wait completely.

WARNING: multiple messages have this Message-ID (diff)
From: djkurtz@chromium.org (Daniel Kurtz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] i2c-s3c2410: use exponential back off while polling for bus idle
Date: Tue, 20 Nov 2012 16:57:16 +0800	[thread overview]
Message-ID: <CAGS+omCKm+aN9ZXApmQJh1OrST-t2sA8WP7NyDOzKnv-xqJ5vg@mail.gmail.com> (raw)
In-Reply-To: <20121120044859.GA10154@sirena.org.uk>

Hi Mark,

On Tue, Nov 20, 2012 at 12:49 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> On Thu, Nov 15, 2012 at 05:43:32PM +0530, Naveen Krishna Chatradhi wrote:
>
> > +     iicstat = readl(i2c->regs + S3C2410_IICSTAT);
> > +     delay = 1;
> > +     while ((iicstat & S3C2410_IICSTAT_START) &&
> > +            ktime_us_delta(now, start) < S3C2410_IDLE_TIMEOUT) {
> > +             usleep_range(delay, 2 * delay);
> > +             if (delay < S3C2410_IDLE_TIMEOUT / 10)
> > +                     delay <<= 1;
> > +             now = ktime_get();
> > +             iicstat = readl(i2c->regs + S3C2410_IICSTAT);
> > +     }
>
> > -     /* first, try busy waiting briefly */
> > -     do {
> > -             cpu_relax();
> > -             iicstat = readl(i2c->regs + S3C2410_IICSTAT);
> > -     } while ((iicstat & S3C2410_IICSTAT_START) && --spins);
>
> On the hardware I was using when I wrote the original code here we were
> hitting 1-2 spins often enough to be interesting - starting off with a
> direct busy wait was definitely useful when doing large batches of I/O,
> especially compared to sleeps which might cause us to schedule.

We check the status first to avoid any sleep()/schedule() in the case,
that the CPU is slower than I2C transaction.
Remember, this loop only happens after the event_wait loop has been
woken up by the i2c irq.
Since you are talking about hitting a tiny window of time at some
arbitrary point after an irq, the CPU time to this point & I2C
finishing would have to be very precisely aligned for the 1-2 loops
(at CPU clock rate) to matter.

HTH,
-Dan

>
> > -     /* if that timed out sleep */
> > -     if (!spins) {
> > -             msleep(1);
> > -             iicstat = readl(i2c->regs + S3C2410_IICSTAT);
> > -     }
>
> It seems like it'd be better to do the exponential backoff bit here
> instead of removing the busy wait completely.

  reply	other threads:[~2012-11-20  8:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-15 12:13 [PATCH 0/4] i2c-s3c2410: Fix a bug and optimize code Naveen Krishna Chatradhi
2012-11-15 12:13 ` Naveen Krishna Chatradhi
2012-11-15 12:13 ` [PATCH 1/4] i2c-s3c2410: grab adapter lock while changing i2c clock Naveen Krishna Chatradhi
2012-11-15 12:13   ` Naveen Krishna Chatradhi
2012-11-15 12:13 ` [PATCH 2/4] i2c-s3c2410: do not generate STOP for QUIRK_HDMIPHY Naveen Krishna Chatradhi
2012-11-15 12:13   ` Naveen Krishna Chatradhi
2012-11-15 12:13 ` [PATCH 3/4] i2c-s3c2410: use exponential back off while polling for bus idle Naveen Krishna Chatradhi
2012-11-15 12:13   ` Naveen Krishna Chatradhi
2012-11-20  4:49   ` Mark Brown
2012-11-20  4:49     ` Mark Brown
2012-11-20  8:57     ` Daniel Kurtz [this message]
2012-11-20  8:57       ` Daniel Kurtz
     [not found]       ` <CAGS+omCKm+aN9ZXApmQJh1OrST-t2sA8WP7NyDOzKnv-xqJ5vg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-20  9:10         ` Mark Brown
2012-11-20  9:10           ` Mark Brown
     [not found] ` <1352981613-2098-1-git-send-email-ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2012-11-15 12:13   ` [PATCH 4/4] i2c-s3c2410: do not special case HDMIPHY stuck bus detection Naveen Krishna Chatradhi
2012-11-15 12:13     ` Naveen Krishna Chatradhi
2012-11-16 12:05 ` [PATCH 0/4] i2c-s3c2410: Fix a bug and optimize code Wolfram Sang
2012-11-16 12:05   ` Wolfram Sang

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=CAGS+omCKm+aN9ZXApmQJh1OrST-t2sA8WP7NyDOzKnv-xqJ5vg@mail.gmail.com \
    --to=djkurtz@chromium.org \
    --cc=ben-linux@fluff.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=ch.naveen@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=khali@linux-fr.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=naveenkrishna.ch@gmail.com \
    --cc=w.sang@pengutronix.de \
    /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.