From: Ben Dooks <ben-i2c@fluff.org>
To: Jean Delvare <khali@linux-fr.org>
Cc: Linux I2C <linux-i2c@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Matthias Zacharias <Matthias.Zacharias@bmk-solutions.de>
Subject: Re: [RFC] i2c-algo-bit: Disable interrupts while SCL is high
Date: Thu, 16 Dec 2010 16:00:46 +0000 [thread overview]
Message-ID: <20101216160046.GE20097@trinity.fluff.org> (raw)
In-Reply-To: <20101216150638.7d3850b5@endymion.delvare>
On Thu, Dec 16, 2010 at 03:06:38PM +0100, Jean Delvare wrote:
> Add a spinlock to every user of i2c-algo-bit, which is taken before
> raising SCL and released after lowering SCL. We don't really need
> the exclusion functionality, but we have to disable local interrupts.
> This is needed to comply with SMBus requirements that SCL shouldn't
> be high for longer than 50 us.
>
> SMBus slaves can consider SCL being high for 50 us as a timeout
> condition. This has been observed to happen reproducibly with the
> Melexis MLX90614.
>
> The drawback of this approach is that spin_lock_irqsave() and
> spin_unlock_irqrestore() will be called once for each bit going on the
> I2C bus in either direction. This can mean up to 100 kHz for standard
> I2C and SMBus and up to 250 kHz for fast I2C. The good thing is that
> this limits the latency to reasonable values (2us at 250 kHz, 5 us at
> 100 kHz and 50 us at 10 kHz).
Hmm, this is going to be a drain on interrupt latency... disabling
interrupts in a system for that long could cause other things to
jitter.
I think if there's a time constraint, we should look at a method of
using a high-resolution timer to run the clocks so that we don't
have to wait around polling stuff.
> An alternative would be to keep the lock held for the whole transfer
> of every single byte. This would divide the number of calls to
> spin_lock_irqsave() and spin_unlock_irqrestore() by 9 (i.e. up to 11
> kHz for standard I2C and up to 28 kHz for fast I2C) at the price of
> multiplying the latency by 18 (i.e. 36 us at 250 kHz, 90 us at 100 kHz
> and 900 us at 10 kHz).
>
> I would welcome comments on this. I sincerely have no idea what is
> considered a reasonable duration during which local interrupts can be
> disabled, and I have also no idea above what frequency taking and
> releasing a (never busy) spinlock is considered unreasonable.
The cost of IRQ-spinlock on UP-ARM is about 4 instructions for each lock
and unlock. So taking it a-lot isn't costly in this place... not sure
for the MP variants.
> /* ----- global defines ----------------------------------------------- */
> @@ -130,12 +131,17 @@ static void i2c_start(struct i2c_algo_bi
>
> static void i2c_repstart(struct i2c_algo_bit_data *adap)
> {
> + unsigned long flags;
> +
> /* assert: scl is low */
> sdahi(adap);
> + spin_lock_irqsave(&adap->lock, flags);
> sclhi(adap);
> setsda(adap, 0);
> udelay(adap->udelay);
> - scllo(adap);
> + setscl(adap, 0);
> + spin_unlock_irqrestore(&adap->lock, flags);
> + udelay(adap->udelay / 2);
> }
would be nice to document why we're taking this lock here... or in the
header add some more explanation other than 'whilst clock is high'
anyway, the rest looks fine from reading through, there's no obvious
problems.
--
Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
next prev parent reply other threads:[~2010-12-16 16:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-16 14:06 [RFC] i2c-algo-bit: Disable interrupts while SCL is high Jean Delvare
2010-12-16 16:00 ` Ben Dooks [this message]
[not found] ` <20101216160046.GE20097-SMNkleLxa3Z6Wcw2j4pizdi2O/JbrIOy@public.gmane.org>
2010-12-16 16:53 ` Jean Delvare
[not found] ` <20101216175337.2b1ae6ee-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-12-17 12:09 ` Michael Lawnick
[not found] ` <4D0B5312.5080107-Mmb7MZpHnFY@public.gmane.org>
2010-12-17 23:09 ` Jean Delvare
[not found] ` <20101218000924.546ad703-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-12-20 7:24 ` Michael Lawnick
[not found] ` <4D0F0497.7090306-Mmb7MZpHnFY@public.gmane.org>
2010-12-20 13:04 ` Jean Delvare
2011-01-11 9:49 ` Antw: " Matthias Zacharias
2011-11-03 12:59 ` Jean Delvare
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=20101216160046.GE20097@trinity.fluff.org \
--to=ben-i2c@fluff.org \
--cc=Matthias.Zacharias@bmk-solutions.de \
--cc=khali@linux-fr.org \
--cc=linux-i2c@vger.kernel.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 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).