State of arbitration and i2c_gpio?

State of arbitration and i2c_gpio?

[Matthias Urlichs]

Hello people,

I'd like to ask whether anybody is working on adding arbitration support to
i2c_algo_bit.c. The code still has the old "FIXME do arbitration here" comments,
added five years ago when the I²C was imported into Linux 2.3.34pre1. :-/

If not, and I'm going to have to do that myself … my main question is, even
before I get to that -- how do I even detect that the bus is idle? Turn
interrupts off and busy-loop-check that both SCL and SDA stay high for at least
one and a half clock periods?

Ugh.

-- 
-- Matthias Urlichs

Re: State of arbitration and i2c_gpio?

[Laxman Dewangan]

Hi Matthias,
I remember Viresh was working on this support sometimes ago where he 
added gpio based arbitration recovery on i2c-core.

http://lwn.net/Articles/485046/

I am also looking to use the gpio based arb recovery mechanism for the 
i2c-tegra.c.

As this recovery will be generic, better to have this in common place so 
that many driver can use this. Also the provision should be there to 
configure pin as gpio and non-gpio mode.

Thanks,
Laxman


On Monday 16 July 2012 08:45 PM, Matthias Urlichs wrote:
> Hello people,
>
> I'd like to ask whether anybody is working on adding arbitration support to
> i2c_algo_bit.c. The code still has the old "FIXME do arbitration here" comments,
> added five years ago when the I²C was imported into Linux 2.3.34pre1. :-/
>
> If not, and I'm going to have to do that myself … my main question is, even
> before I get to that -- how do I even detect that the bus is idle? Turn
> interrupts off and busy-loop-check that both SCL and SDA stay high for at least
> one and a half clock periods?
>
> Ugh.
>

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Re: State of arbitration and i2c_gpio?

[Jean Delvare]

Hallo Matthias,

On Mon, 16 Jul 2012 15:15:29 +0000 (UTC), Matthias Urlichs wrote:
> I'd like to ask whether anybody is working on adding arbitration support to
> i2c_algo_bit.c. The code still has the old "FIXME do arbitration here" comments,
> added five years ago when the I²C was imported into Linux 2.3.34pre1. :-/

Not that I am aware of.

> If not, and I'm going to have to do that myself … my main question is, even
> before I get to that -- how do I even detect that the bus is idle? Turn
> interrupts off and busy-loop-check that both SCL and SDA stay high for at least
> one and a half clock periods?

I was staring at this very FIXME comment in i2c-algo-bit a few weeks
ago and my thoughts were along the lines of "can this be implemented at
all?" We can't monitor SCL and SDA continuously with a pure software
implementation. We can do best effort, but the closer to perfection we
want to be, the more expensive. If both pins can trigger an interrupt
when their level changes, we could use this feature, but OTOH we
certainly don't want to receive interrupts the rest of the time, so
we'd have to repeatedly enable/disable these interrupts. If we don't
have such interrupts then indeed busy polling (or close to that) is the
only way I can think of.

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. 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.
Not sure we can actually guarantee that...

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.

-- 
Jean Delvare

Re: State of arbitration and i2c_gpio?

[Matthias Urlichs]

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

Re: State of arbitration and i2c_gpio?

[Jean Delvare]

On Tue, 17 Jul 2012 08:55:45 +0200, Matthias Urlichs wrote:
> Jean Delvare:
> > 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

Arbitration under HS-mode is handled differently: it is settled early
in the transaction. So this might not actually be a problem.

> > 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.

They won't notice if the code is disabled. My point was that we don't
want to put an additional burden on single-master buses because
arbitration is never needed for them.

-- 
Jean Delvare

Re: State of arbitration and i2c_gpio?

[Matthias Urlichs]

Hi,

Jean Delvare:
> > They'll certainly notice that the first time they lose arbitration.
> 
> They won't notice if the code is disabled. My point was that we don't
> want to put an additional burden on single-master buses because
> arbitration is never needed for them.
> 
Checking whether Data is High after setting Clock to High is not something
I'd call a burden ...

-- 
-- Matthias Urlichs