From: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
To: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Naveen Krishna Chatradhi
<ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux I2C <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>,
kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>,
Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
naveenkrishna.ch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH 3/4] i2c-s3c2410: use exponential back off while polling for bus idle
Date: Tue, 20 Nov 2012 18:10:59 +0900 [thread overview]
Message-ID: <20121120091056.GZ10560@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAGS+omCKm+aN9ZXApmQJh1OrST-t2sA8WP7NyDOzKnv-xqJ5vg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]
On Tue, Nov 20, 2012 at 04:57:16PM +0800, Daniel Kurtz wrote:
> On Tue, Nov 20, 2012 at 12:49 PM, Mark Brown
> > 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.
Right, but this only works if we hit this on the very first spin.
> Remember, this loop only happens after the event_wait loop has been
> woken up by the i2c irq.
Duh.
> 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.
On some systems that can happen enormously reliably, finger in the air
it's your fast case on the A15s you're playing with scaled down to a
much slower CPU. The 20 spins I was setting the loop to was a massive
overestimate for conservativism but more than 1 was common enough, IIRC
spinning 5 times would have covered essentially everything.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
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 18:10:59 +0900 [thread overview]
Message-ID: <20121120091056.GZ10560@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAGS+omCKm+aN9ZXApmQJh1OrST-t2sA8WP7NyDOzKnv-xqJ5vg@mail.gmail.com>
On Tue, Nov 20, 2012 at 04:57:16PM +0800, Daniel Kurtz wrote:
> On Tue, Nov 20, 2012 at 12:49 PM, Mark Brown
> > 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.
Right, but this only works if we hit this on the very first spin.
> Remember, this loop only happens after the event_wait loop has been
> woken up by the i2c irq.
Duh.
> 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.
On some systems that can happen enormously reliably, finger in the air
it's your fast case on the A15s you're playing with scaled down to a
much slower CPU. The 20 spins I was setting the loop to was a massive
overestimate for conservativism but more than 1 was common enough, IIRC
spinning 5 times would have covered essentially everything.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121120/8c42a44d/attachment-0001.sig>
next prev parent reply other threads:[~2012-11-20 9:10 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
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 [this message]
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=20121120091056.GZ10560@opensource.wolfsonmicro.com \
--to=broonie-yzvpicuk2aatku/dhu1wvuem+bqzidxxqq4iyu8u01e@public.gmane.org \
--cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
--cc=ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=naveenkrishna.ch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.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.