From: Matthias Urlichs <matthias-+qxcz+fHsVSELgA04lAiVw@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: State of arbitration and i2c_gpio?
Date: Tue, 17 Jul 2012 08:55:45 +0200 [thread overview]
Message-ID: <20120717065544.GF11678@smurf.noris.de> (raw)
In-Reply-To: <20120716225827.3425f4f8-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
Hi,
Jean Delvare:
> If both pins can trigger an interrupt
> when their level changes, we could use this feature
I'm reasonably sure, thinking about this, that safe multimaster without
interrupts on the data line (so that you can watch for Start and Stop
conditions) is basically impossible. Not if you want your computer to do
anything while it waits for the bus transaction to finish, that is.
> Note that "one and a half clock period" is not something which
> evaluates to a number. You have no idea at what frequency the other
> master, if it exists, would be driving the bus. And the I2C
> specification does not specify a minimum operating frequency, so in
> theory you'd have to wait... forever. To solve this problem, SMBus
> specifies a 50 µs maximum bus idle time (which corresponds to a 10 kHz
> clock, the minimum allowed under SMBus.) I suppose this is a sane
> setting in practice even for I2C controllers.
It does evaluate to a number if we assume that there's no good reason for
the Clock line to be High for much longer than 5µS, unless the bus is idle
of course.
Needless to say, there might be a number of *bad* reasons for that …
> At the other end of the
> spectrum, we have to deal with the maximum I2C frequency, 400 kHz in
> our context. This means you can't have more than 1.25 µs between polls.
Just wait until somebody implements Hs mode. :-P
> In all cases we'll certainly want to let adapters tell whether they are
> operating on a multi-master bus or not, so that the whole thing can be
> disabled when not needed.
They'll certainly notice that the first time they lose arbitration.
--
-- Matthias Urlichs
next prev parent reply other threads:[~2012-07-17 6:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-16 15:15 State of arbitration and i2c_gpio? Matthias Urlichs
[not found] ` <loom.20120710T223443-322-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2012-07-16 16:05 ` Laxman Dewangan
2012-07-16 20:58 ` Jean Delvare
[not found] ` <20120716225827.3425f4f8-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-07-17 6:55 ` Matthias Urlichs [this message]
[not found] ` <20120717065544.GF11678-ci3XGGwdvIcvfNposrsB4g@public.gmane.org>
2012-07-17 7:11 ` Jean Delvare
[not found] ` <20120717091115.44e28fd0-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-07-17 8:46 ` Matthias Urlichs
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=20120717065544.GF11678@smurf.noris.de \
--to=matthias-+qxcz+fhsvselga04laivw@public.gmane.org \
--cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
--cc=linux-i2c-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 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).