From: Michael Lawnick <ml.lawnick-Mmb7MZpHnFY@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: Ben Dooks <ben-i2c-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>,
Linux I2C <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Matthias Zacharias
<Matthias.Zacharias-zGrmWZs6xXT+aS/vkh9bjw@public.gmane.org>
Subject: Re: [RFC] i2c-algo-bit: Disable interrupts while SCL is high
Date: Fri, 17 Dec 2010 13:09:54 +0100 [thread overview]
Message-ID: <4D0B5312.5080107@gmx.de> (raw)
In-Reply-To: <20101216175337.2b1ae6ee-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
Jean Delvare said the following:
> Hi Ben,
>
> On Thu, 16 Dec 2010 16:00:46 +0000, Ben Dooks wrote:
>> 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.
>
> So you consider that even disabling interrupts for 5 us is too long? Or
> are you only worried by the 50 us case?
Sorry to disturb, but
<MANTRA>
Disabling interrupts may be done only for a few instructions.</MANTRA>
Even 1 us is an eternity on modern systems.
JM2C
--
KR
Michael
WARNING: multiple messages have this Message-ID (diff)
From: Michael Lawnick <ml.lawnick@gmx.de>
To: Jean Delvare <khali@linux-fr.org>
Cc: Ben Dooks <ben-i2c@fluff.org>,
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: Fri, 17 Dec 2010 13:09:54 +0100 [thread overview]
Message-ID: <4D0B5312.5080107@gmx.de> (raw)
In-Reply-To: <20101216175337.2b1ae6ee@endymion.delvare>
Jean Delvare said the following:
> Hi Ben,
>
> On Thu, 16 Dec 2010 16:00:46 +0000, Ben Dooks wrote:
>> 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.
>
> So you consider that even disabling interrupts for 5 us is too long? Or
> are you only worried by the 50 us case?
Sorry to disturb, but
<MANTRA>
Disabling interrupts may be done only for a few instructions.</MANTRA>
Even 1 us is an eternity on modern systems.
JM2C
--
KR
Michael
next prev parent reply other threads:[~2010-12-17 12:09 UTC|newest]
Thread overview: 17+ 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 14:06 ` Jean Delvare
2010-12-16 16:00 ` Ben Dooks
[not found] ` <20101216160046.GE20097-SMNkleLxa3Z6Wcw2j4pizdi2O/JbrIOy@public.gmane.org>
2010-12-16 16:53 ` Jean Delvare
2010-12-16 16:53 ` Jean Delvare
[not found] ` <20101216175337.2b1ae6ee-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-12-17 12:09 ` Michael Lawnick [this message]
2010-12-17 12:09 ` Michael Lawnick
[not found] ` <4D0B5312.5080107-Mmb7MZpHnFY@public.gmane.org>
2010-12-17 23:09 ` Jean Delvare
2010-12-17 23:09 ` Jean Delvare
[not found] ` <20101218000924.546ad703-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-12-20 7:24 ` Michael Lawnick
2010-12-20 7:24 ` Michael Lawnick
[not found] ` <4D0F0497.7090306-Mmb7MZpHnFY@public.gmane.org>
2010-12-20 13:04 ` Jean Delvare
2010-12-20 13:04 ` Jean Delvare
2011-01-11 9:49 ` Antw: " Matthias Zacharias
2011-01-11 9:49 ` Matthias Zacharias
2011-11-03 12:59 ` Jean Delvare
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=4D0B5312.5080107@gmx.de \
--to=ml.lawnick-mmb7mzphnfy@public.gmane.org \
--cc=Matthias.Zacharias-zGrmWZs6xXT+aS/vkh9bjw@public.gmane.org \
--cc=ben-i2c-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
--cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@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.