From: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
To: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Olof Johansson <olofj-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Subject: [PATCH] i2c: i2c-s3c2410: Remove recently introduced performance overheads
Date: Wed, 21 Nov 2012 13:12:11 +0900 [thread overview]
Message-ID: <1353471131-23975-1-git-send-email-broonie@opensource.wolfsonmicro.com> (raw)
The changes in "i2c-s3c2410: use exponential back off while polling for
bus idle" remove the initial busy wait for I2C transfers to complete and
replace it with usleep_range() calls which will schedule.
Since for older SoCs I2C transfers would usually complete within an
extremely small number of CPU cycles there is a win from not having to
schedule. This happens because on the older SoCs the cores run at a
smaller multiple of the speeds that the I2C bus is operating at; on more
modern SoCs the busy wait is less likely to be effective.
Fix the issue by restoring the busy wait, reducing the number of spins
from 20 to 3 which covers the overwhelming majority of I2C transfers on
the SoCs where the busy wait is effective.
Signed-off-by: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
---
drivers/i2c/busses/i2c-s3c2410.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 31f802b..25dc3e2 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -530,6 +530,7 @@ static void s3c24xx_i2c_wait_idle(struct s3c24xx_i2c *i2c)
unsigned long iicstat;
ktime_t start, now;
unsigned long delay;
+ int spins;
/* ensure the stop has been through the bus */
@@ -542,12 +543,23 @@ static void s3c24xx_i2c_wait_idle(struct s3c24xx_i2c *i2c)
* end of a transaction. However, really slow i2c devices can stretch
* the clock, delaying STOP generation.
*
- * As a compromise between idle detection latency for the normal, fast
- * case, and system load in the slow device case, use an exponential
- * back off in the polling loop, up to 1/10th of the total timeout,
- * then continue to poll at a constant rate up to the timeout.
+ * On slower SoCs this typically happens within a very small number of
+ * instructions so busy wait briefly to avoid scheduling overhead.
*/
+ spins = 3;
iicstat = readl(i2c->regs + S3C2410_IICSTAT);
+ while ((iicstat & S3C2410_IICSTAT_START) && --spins) {
+ cpu_relax();
+ iicstat = readl(i2c->regs + S3C2410_IICSTAT);
+ }
+
+ /*
+ * If we do get an appreciable delay as a compromise between idle
+ * detection latency for the normal, fast case, and system load in the
+ * slow device case, use an exponential back off in the polling loop,
+ * up to 1/10th of the total timeout, then continue to poll at a
+ * constant rate up to the timeout.
+ */
delay = 1;
while ((iicstat & S3C2410_IICSTAT_START) &&
ktime_us_delta(now, start) < S3C2410_IDLE_TIMEOUT) {
--
1.7.10.4
next reply other threads:[~2012-11-21 4:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-21 4:12 Mark Brown [this message]
[not found] ` <1353471131-23975-1-git-send-email-broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-11-21 5:08 ` [PATCH] i2c: i2c-s3c2410: Remove recently introduced performance overheads Olof Johansson
[not found] ` <CAOesGMhBZo6gKfzs1A954a_vaAMzy4px3TsgKE2rac_igH3sLw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-21 6:23 ` Daniel Kurtz
2012-11-22 21:35 ` Wolfram Sang
-- strict thread matches above, loose matches on Subject: below --
2012-11-20 5:57 Mark Brown
[not found] ` <1353391041-28943-1-git-send-email-broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-11-20 9:45 ` Daniel Kurtz
[not found] ` <CAGS+omAkOwq7m_zGCYjwgrFY_jjNfWqvFqS29F5b6GBPr62UFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-20 9:48 ` Mark Brown
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=1353471131-23975-1-git-send-email-broonie@opensource.wolfsonmicro.com \
--to=broonie-yzvpicuk2aatku/dhu1wvuem+bqzidxxqq4iyu8u01e@public.gmane.org \
--cc=bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=olofj-F7+t8E8rja9g9hUCZPvPmw@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).