i2c/kernel i2c-algo-bit.c

i2c/kernel i2c-algo-bit.c

[Jean Delvare]

> Modified Files:
> 	i2c-algo-bit.c 
> Log Message:
> (Khali) Fix sclhi() for adapters that do not have getscl().
>         Enable bit_test for adapters that do not have getscl().
>         Mostly rewrite test_bus(), cleaner and probably faster.

I'd like reviewers and testers on this, since I plan to submit a similar
for Linux 2.6. There are two distinct changes:

1* Fixed sclhi() for adapters that do not have getscl(). It looks like
there was a udelay call missing in this case.

2* Rewrote test_bus() almost entirely, to allow adapters without
getscl() to be tested. It's still interesting to test SDA in this case.

I have a pair of questions with regard to i2c-algo-bit:

1* I don't understand how the whole thing works. Each of sdalo(),
sdahi(), scllo() and sclhi() are waiting adap->udelay before returning.
How in this condition can the driver change both SCL and SDA values in a
row?

2* It looks like i2c-algo-bit assumes that both SDA and SCL are high by
the time it is called. Why that? Looks like not all drivers will do so.
Especially, I tried my changes using i2c-matroxfb and it looks like this
driver doesn't set SDA not SCL before registering with i2c-algo-bit,
causing bit_test to sometimes fail with the message "seems to be busy".
I wonder if it wouldn't be easier (and safer) not to assume anything
about SDA and SCL in i2c-algo-bit.c:test_bus() (that is, remove that
"may be busy" test).

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

i2c/kernel i2c-algo-bit.c

[Mark M. Hoffman]

* Jean Delvare <khali@linux-fr.org> [2003-11-01 17:09:44 +0100]:
> > Modified Files:
> > 	i2c-algo-bit.c 
> > Log Message:
> > (Khali) Fix sclhi() for adapters that do not have getscl().
> >         Enable bit_test for adapters that do not have getscl().
> >         Mostly rewrite test_bus(), cleaner and probably faster.
> 
> I'd like reviewers and testers on this, since I plan to submit a similar
> for Linux 2.6. There are two distinct changes:

I haven't read the source in i2c-algo-bit.c, *ever*.  I'm sorry, but for
the moment I cannot allow myself to read it.  I may yet need to maintain
a bit-bashing I2C driver for a client that I wrote some years ago which
predates my involvement in this project.  At least the I2C bus spec is
publicly available. [1]

> 1* Fixed sclhi() for adapters that do not have getscl(). It looks like
> there was a udelay call missing in this case.

If you can't read SCL, you can't have a true I2C master.  SCL is
wired-AND which means that any device on the bus can hold it low
until that device is ready.

In theory, any I2C bus master which is implemented by bit-bashing
yet which cannot read SCL is fundamentally broken.  In practice,
such a system will work fine if the slaves never hold the clock low.
For bus arbitration (more than one master), the ability to read SCL
is definitely required.

> 2* Rewrote test_bus() almost entirely, to allow adapters without
> getscl() to be tested. It's still interesting to test SDA in this case.
> 
> I have a pair of questions with regard to i2c-algo-bit:
> 
> 1* I don't understand how the whole thing works. Each of sdalo(),
> sdahi(), scllo() and sclhi() are waiting adap->udelay before returning.
> How in this condition can the driver change both SCL and SDA values in a
> row?

Do you mean to transition SCL and SDA at the same time?  It cannot, nor
does it have to.  Take another look at the I2C protocol spec, especially
figure 4 on page 9.

> 2* It looks like i2c-algo-bit assumes that both SDA and SCL are high by
> the time it is called. Why that? Looks like not all drivers will do so.

Because that is the bus idle condition?  If the hardware has pullups
on SCL and SDA then the driver doesn't need to do anything to cause
bus idle.  OTOH if SCL/SDA are floating, then the driver might have
to manually establish bus idle first.  Again, I haven't looked at the
source... but it makes sense if that's how it's implemented.  The
algorithm simply expects an idle bus.  The driver does whatever it
must do (possibly nothing) to create that condition.

> Especially, I tried my changes using i2c-matroxfb and it looks like this
> driver doesn't set SDA not SCL before registering with i2c-algo-bit,
> causing bit_test to sometimes fail with the message "seems to be busy".
> I wonder if it wouldn't be easier (and safer) not to assume anything
> about SDA and SCL in i2c-algo-bit.c:test_bus() (that is, remove that
> "may be busy" test).

In this case, do you remove and reload the modules, or are you forced
to reboot the machine?  The bus really might just be stuck.  The I2C
bus is especially vulnerable to SCL stuck low because start, idle, and
stop conditions are all impossible in that case; and the wired-AND-ness
of SCL means it only takes one confused slave to kill the bus.

[1] http://www.semiconductors.philips.com/acrobat/literature/9398/39340011.pdf

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

i2c/kernel i2c-algo-bit.c

[Jean Delvare]

> Fix #1 looks fine.
> Fix #2 (test_bus) I'm sure is an improvement.
> If you are really motivated, try fixing the printk's for debug=1.
> As I recall from long ago some of them are not correct.

Could be a feature. Maybe the author considered that someone askin for
the test shouldn't have to also set i2c_debug in order to see the result
of the test.

My opinion is that I would rather do the test as the default (that is,
default to bit_test=1) and not show anything about it unless
i2c_debug>=1. The reason why I suggest this should be the default is
that I plan to write a unified i2c-over-parport driver as a replacement
for the 5 different drivers out there. Idealy, that driver would be able
to autodetect which kind of parallel port adapter is present. This can't
be done without bit_test=1 as far as I can tell. So, unless bit_test is
likely to cause trouble (shouldn't since we check the bus isn't busy) I
would like it to be the default.

This also solves other problems, such as sensors-detect taking forever
to scan i2c-matroxfb busses with non DDC-compliant monitor plugged-in.

> If you want to be truly frightened try debug=9.

I don't want to be frightened. I already live right in front of a
graveyard, that's enough ;)

> The actual cycle time is 2/3 of advertised (yes it's 3 states total,
> not 2 or 4).

I guess you mean 3/2 of advertised. If I read you (and the code)
carefully, this means that SCL isn't a square signal, is it? Does this
really comply with the I2C standard?

(Just took a look at TODO... Let me be clear. All this stuff is way
beyond me.)

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

i2c/kernel i2c-algo-bit.c

[Jean Delvare]

> > 1* Fixed sclhi() for adapters that do not have getscl(). It looks
> > like there was a udelay call missing in this case.
> 
> If you can't read SCL, you can't have a true I2C master.  SCL is
> wired-AND which means that any device on the bus can hold it low
> until that device is ready.

You're of course right. Still some masters can't read SCL back. This is
the case for the ADM1032 evaluation I received from Analog Devices. The
i2c-algo-bit module was supposed to handle that case already, so it must
not be that uncommon.

> In theory, any I2C bus master which is implemented by bit-bashing
> yet which cannot read SCL is fundamentally broken.  In practice,
> such a system will work fine if the slaves never hold the clock low.
> For bus arbitration (more than one master), the ability to read SCL
> is definitely required.

I guess that evalution boards must be matching that criteria. Mine must
be, at least, since it's working OK.

> > 1* I don't understand how the whole thing works. Each of sdalo(),
> > sdahi(), scllo() and sclhi() are waiting adap->udelay before
> > returning. How in this condition can the driver change both SCL and
> > SDA values in a row?
> 
> Do you mean to transition SCL and SDA at the same time?  It cannot,
> nor does it have to.  Take another look at the I2C protocol spec,
> especially figure 4 on page 9.

Yes, I know that. I've read the I2C spec, mind you ;) OK, I stopped
before the end, I admit. But I've at least understood that SDA changes
on SCL low, and "sampled" (if that make sense for a one-bit value) on
SCL high.

What confuses me is that comment in i2c-algo-bit.h:

  int udelay;  /* half-clock-cycle time in microsecs */
               /* i.e. clock is (500 / udelay) KHz */

Since each of sdalo(), sdahi(), scllo() and sclhi() is waiting udelay
before returning, the clock-cycle would more likely be four times
udelay, not two. Or am I missing something? Sending one bit on the bus
being setting SCL low, setting SDA to the wanted value, setting SCL
high, waiting for SDA to be sampled. Four times udelay, no less. Please
tell me if I'm wrong somehow.


> > 2* It looks like i2c-algo-bit assumes that both SDA and SCL are high
> > by the time it is called. Why that? Looks like not all drivers will
> > do so.
> 
> Because that is the bus idle condition?  If the hardware has pullups
> on SCL and SDA then the driver doesn't need to do anything to cause
> bus idle.  OTOH if SCL/SDA are floating, then the driver might have
> to manually establish bus idle first.  Again, I haven't looked at the
> source... but it makes sense if that's how it's implemented.  The
> algorithm simply expects an idle bus.  The driver does whatever it
> must do (possibly nothing) to create that condition.

That makes sense - providing all bus drivers play the game. The
parallel-port bus driver, for example, has to set the lines high
manually. The pins have to be set or not, they can't be left floating.

> > Especially, I tried my changes using i2c-matroxfb and it looks like
> > this driver doesn't set SDA not SCL before registering with
> > i2c-algo-bit, causing bit_test to sometimes fail with the message
> > "seems to be busy". I wonder if it wouldn't be easier (and safer)
> > not to assume anything about SDA and SCL in
> > i2c-algo-bit.c:test_bus() (that is, remove that"may be busy" test).
> 
> In this case, do you remove and reload the modules, or are you forced
> to reboot the machine?  The bus really might just be stuck.  The I2C
> bus is especially vulnerable to SCL stuck low because start, idle, and
> stop conditions are all impossible in that case; and the
> wired-AND-ness of SCL means it only takes one confused slave to kill
> the bus.

Reloading the i2c-matroxfb module didn't help, but reloading
i2c-algo-bit without the bit_test parameter worked without a hitch.
That's what made me think the test wasn't good. Now I understand that
i2c-algo-bit doesn't want to trouble the bus if someone else is talking
(multi-master case for example), but in my case it looks like
something's not working as intended. I don't see what bad could happen
setting the lines high at the beginning of the test. If someone else is
holding the line low at the same time, if my understanding of the I2C
bus is correct, that other device won't even notice it, since setting
low always wins over setting high. This is why I believe we could set
the lines high in i2c-algo-bit rather than in drivers (or at least set
the lines high before trying to test wether the lines are stuck or not).

Of course, the other possibility is to fix i2c-matroxfb, if it is
actually broken.

Thanks for your advice :)

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

i2c/kernel i2c-algo-bit.c

[Mark Studebaker]

Fix #1 looks fine.
Fix #2 (test_bus) I'm sure is an improvement.
If you are really motivated, try fixing the printk's for debug=1.
As I recall from long ago some of them are not correct.
If you want to be truly frightened try debug=9.

As far as the timing, yes it's horrid.
And not checking for the bus being high, that's a byproduct of
not really implementing multi-master. See the TODO file.

The actual cycle time is 2/3 of advertised (yes it's 3 states total, not
2 or 4).
What you're starting to see is the problems that caused Kyosti to
start a totally new driver i2c-algo-biths. I'll try and find some of
the discussions about the i2c-algo-bit driver, and what Kyosti hoped to
accomplish with i2c-algo-biths, and put it in the TODO file.
What's in TODO now is only part of the problems. 

mds


Jean Delvare wrote:
> 
> > > 1* Fixed sclhi() for adapters that do not have getscl(). It looks
> > > like there was a udelay call missing in this case.
> >
> > If you can't read SCL, you can't have a true I2C master.  SCL is
> > wired-AND which means that any device on the bus can hold it low
> > until that device is ready.
> 
> You're of course right. Still some masters can't read SCL back. This is
> the case for the ADM1032 evaluation I received from Analog Devices. The
> i2c-algo-bit module was supposed to handle that case already, so it must
> not be that uncommon.
> 
> > In theory, any I2C bus master which is implemented by bit-bashing
> > yet which cannot read SCL is fundamentally broken.  In practice,
> > such a system will work fine if the slaves never hold the clock low.
> > For bus arbitration (more than one master), the ability to read SCL
> > is definitely required.
> 
> I guess that evalution boards must be matching that criteria. Mine must
> be, at least, since it's working OK.
> 
> > > 1* I don't understand how the whole thing works. Each of sdalo(),
> > > sdahi(), scllo() and sclhi() are waiting adap->udelay before
> > > returning. How in this condition can the driver change both SCL and
> > > SDA values in a row?
> >
> > Do you mean to transition SCL and SDA at the same time?  It cannot,
> > nor does it have to.  Take another look at the I2C protocol spec,
> > especially figure 4 on page 9.
> 
> Yes, I know that. I've read the I2C spec, mind you ;) OK, I stopped
> before the end, I admit. But I've at least understood that SDA changes
> on SCL low, and "sampled" (if that make sense for a one-bit value) on
> SCL high.
> 
> What confuses me is that comment in i2c-algo-bit.h:
> 
>   int udelay;  /* half-clock-cycle time in microsecs */
>                /* i.e. clock is (500 / udelay) KHz */
> 
> Since each of sdalo(), sdahi(), scllo() and sclhi() is waiting udelay
> before returning, the clock-cycle would more likely be four times
> udelay, not two. Or am I missing something? Sending one bit on the bus
> being setting SCL low, setting SDA to the wanted value, setting SCL
> high, waiting for SDA to be sampled. Four times udelay, no less. Please
> tell me if I'm wrong somehow.
> 
> > > 2* It looks like i2c-algo-bit assumes that both SDA and SCL are high
> > > by the time it is called. Why that? Looks like not all drivers will
> > > do so.
> >
> > Because that is the bus idle condition?  If the hardware has pullups
> > on SCL and SDA then the driver doesn't need to do anything to cause
> > bus idle.  OTOH if SCL/SDA are floating, then the driver might have
> > to manually establish bus idle first.  Again, I haven't looked at the
> > source... but it makes sense if that's how it's implemented.  The
> > algorithm simply expects an idle bus.  The driver does whatever it
> > must do (possibly nothing) to create that condition.
> 
> That makes sense - providing all bus drivers play the game. The
> parallel-port bus driver, for example, has to set the lines high
> manually. The pins have to be set or not, they can't be left floating.
> 
> > > Especially, I tried my changes using i2c-matroxfb and it looks like
> > > this driver doesn't set SDA not SCL before registering with
> > > i2c-algo-bit, causing bit_test to sometimes fail with the message
> > > "seems to be busy". I wonder if it wouldn't be easier (and safer)
> > > not to assume anything about SDA and SCL in
> > > i2c-algo-bit.c:test_bus() (that is, remove that"may be busy" test).
> >
> > In this case, do you remove and reload the modules, or are you forced
> > to reboot the machine?  The bus really might just be stuck.  The I2C
> > bus is especially vulnerable to SCL stuck low because start, idle, and
> > stop conditions are all impossible in that case; and the
> > wired-AND-ness of SCL means it only takes one confused slave to kill
> > the bus.
> 
> Reloading the i2c-matroxfb module didn't help, but reloading
> i2c-algo-bit without the bit_test parameter worked without a hitch.
> That's what made me think the test wasn't good. Now I understand that
> i2c-algo-bit doesn't want to trouble the bus if someone else is talking
> (multi-master case for example), but in my case it looks like
> something's not working as intended. I don't see what bad could happen
> setting the lines high at the beginning of the test. If someone else is
> holding the line low at the same time, if my understanding of the I2C
> bus is correct, that other device won't even notice it, since setting
> low always wins over setting high. This is why I believe we could set
> the lines high in i2c-algo-bit rather than in drivers (or at least set
> the lines high before trying to test wether the lines are stuck or not).
> 
> Of course, the other possibility is to fix i2c-matroxfb, if it is
> actually broken.
> 
> Thanks for your advice :)
> 
> --
> Jean Delvare
> http://www.ensicaen.ismra.fr/~delvare/

i2c/kernel i2c-algo-bit.c

[Jean Delvare]

> correct. cycle time is 3/2 of advertised, frequency is 2/3 of
> advertised,
> clock is not a 50/50 duty cycle.

OK, I at least understood at least this well ;)

> I'm uneasy with bit_test the default, but if you've identified the
> reason for matroxfb problems and that's the best way to fix it then
> perhaps it's best.

No, it's something different from the matroxfb issue. The problem I
suspect with i2c-matroxfb is that the driver doesn't set the bus in idle
state when loaded (scl and sda high), and this sometimes cause it to
fail if I use bit_test=1 (because the test checks for the bus being idle
before going on). I'll contact Petr Vandrovec, the author of the module,
and see with him how/if that can be changed. Am I correct thinking it
can never hurt to set the lines high, even if another master would be
controling the bus at that time? If I correctly understood how the I2C
bus is working, setting lines low is always winning over setting them
high - so if that other master wants the line low at this time, our
command won't do anything. If there is no other master, the bus will
correctly go in idle state.

The idea of making bit_test the default comes from my plans of writing a
unified i2c-parport driver. With bit_test set, I can walk through the
different modes and the good one will be detected (providing it is in
the list of known ones). Without bit_test, detection seems to be
impossible and the user will have to specify the mode (which in turn
cause a problem if there are more than one adapter present on the
system, of different types). More generally, bit_test sounds like a very
good idea to improve detection in bus drivers providing these drivers
are ensuring the bus will be idle after they initialize.

I might need to read some more code, but that's how I basically see the
things for now.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

i2c/kernel i2c-algo-bit.c

[Kyösti Mälkki]

As noted before, bit-banging puts some limitations on the type of
devices the bus may have. My (unverified) comments in the order of TODO.

1. Even if both SCL and SDA lines are temporarily high, another master
may have issued Start sequence and the bus is considered Busy until a Stop
sequence is issued. Detecting these sequences requires (minimal)
external hardware, a status changed flag, or fast (<1us) sampling of
SCL and SDA lines. It will work most of the time, but messages from
other hosts on the same bus may get corrupted. For a multi-master
configuration, choose a hardware based i2c approach instead.

2. SMBus has 50 usec of SCL (hi) to detect a free bus. Pretty easy if
the GPIO can trigger on edge or has status change flag.

3. If the adapter hardware cannot read SCL line status, client devices
that may hold SCL low must not be used. This is crucial, otherwise
system looses sync of data and acknowledge bits (missing SCL pulse).
Even Stop may fail (SCL still low). Once released SCL, client will hold
SDA low to signal acknowledge. Master cannot signal Start. Get the
point already?

4. SDA arbitration. Strictly a multi-master issue. Pointless unless we
implement (1) or (2) above. I think i2c-algo-biths implements this as
part of being always so paranoid.


I did put some thought on the various timing issues while writing
i2c-algo-biths. I thought that one could create a queue of i2c bus
changes (ie. timed mem/io operations) and empty this queue within an
"approriate" timer interrupt. Kind of a RISC machine that ticks forwards
a predetermined program if no error flag is set.

-- 
  Ky?sti M?lkki  <kyosti.malkki@welho.com>  +358 50 462 8786

i2c/kernel i2c-algo-bit.c

[Mark Studebaker]

Ky?sti M?lkki wrote:
> 
> 1. You called? Sincere apologies. Yes, still alive.
> 2. About 3k of unread messages in sensors :)
>

Really great to hear from you. I thought something bad happened
since you vanished so suddenly. Think I even googled once
trying to find clues...



> No need for Cc:, old address is still valid. Nowadays, who should I
> contact to get list and CVS logs at a different address? Phil?
> 


yes

i2c/kernel i2c-algo-bit.c

[Mark Studebaker]

correct. cycle time is 3/2 of advertised, frequency is 2/3 of
advertised,
clock is not a 50/50 duty cycle.

I'm uneasy with bit_test the default, but if you've identified the
reason for matroxfb problems and that's the best way to fix it then
perhaps it's best.

On the TODO, that was for background. I think our goal should be to
port the most important improvements from i2c-algo-biths back to
i2c-algo-bit.
It was unfortunate that Kyosti decided to start a new driver...

Jean Delvare wrote:
> 
> > Fix #1 looks fine.
> > Fix #2 (test_bus) I'm sure is an improvement.
> > If you are really motivated, try fixing the printk's for debug=1.
> > As I recall from long ago some of them are not correct.
> 
> Could be a feature. Maybe the author considered that someone askin for
> the test shouldn't have to also set i2c_debug in order to see the result
> of the test.
> 
> My opinion is that I would rather do the test as the default (that is,
> default to bit_test=1) and not show anything about it unless
> i2c_debug>=1. The reason why I suggest this should be the default is
> that I plan to write a unified i2c-over-parport driver as a replacement
> for the 5 different drivers out there. Idealy, that driver would be able
> to autodetect which kind of parallel port adapter is present. This can't
> be done without bit_test=1 as far as I can tell. So, unless bit_test is
> likely to cause trouble (shouldn't since we check the bus isn't busy) I
> would like it to be the default.
> 
> This also solves other problems, such as sensors-detect taking forever
> to scan i2c-matroxfb busses with non DDC-compliant monitor plugged-in.
> 
> > If you want to be truly frightened try debug=9.
> 
> I don't want to be frightened. I already live right in front of a
> graveyard, that's enough ;)
> 
> > The actual cycle time is 2/3 of advertised (yes it's 3 states total,
> > not 2 or 4).
> 
> I guess you mean 3/2 of advertised. If I read you (and the code)
> carefully, this means that SCL isn't a square signal, is it? Does this
> really comply with the I2C standard?
> 
> (Just took a look at TODO... Let me be clear. All this stuff is way
> beyond me.)
> 
> --
> Jean Delvare
> http://www.ensicaen.ismra.fr/~delvare/

i2c/kernel i2c-algo-bit.c

[Kyösti Mälkki]

1. You called? Sincere apologies. Yes, still alive.
2. About 3k of unread messages in sensors :)
3. You can compile -bit compliant version of -biths. Adapter code
needs no changes. You can't go as fast but are able to test for
other features.
4. Other features include verbose bit-level debugging.
5. Anyone with approriate hardware, comments and experience with -biths
is welcome. Year ago I got none. I hope someone could make sure it
still compiles. I will explain logic behind -biths #defines later.

6. The Story: Writing of i2c-algo-biths ...

About bit_test. Yes, good practise to check the hw we are about to use,
test pattern should be valid i2c transitions, between Start and Stop.
Otherwise, the bus may appear as busy for possible other master.
With display adapters, one concern is fighting over bus control with X
server, and leaving the bus in the correct state.

I would describe that i2c-algo-bit does its job blindfolded -- assuming
it has full control over the lines and hardware never fails. It does
this fairly well.

A big issue to solve with i2c-algo-bit, and the main reason why I chose
for almost complete rewrite, is monitoring the bus lines, and graceful
returning if there was any error. I found return codes to be
uncomprehensible, ignored and missing.

In opposite, i2c-algo-biths is paranoid every single time the bus
state is changed. It detects for bus lock-ups on the run, SCL low
extensions and even SDA arbitration. It provides option of using timer
more accurate than udelay. While not strictly necessary, it implements
nominal 50/50 SCL duty cycle.

Since this type of adapter cannot detect when another master issues
Start or Stop sequence on the bus, bit-banging (alone) cannot be
reliably used on a multi-master system. I think it takes 2 NAND gates
or like for the test, and one more input on the adapter.

As earlier, I have some time at this time of year. I will post more
critics about original i2c-algo-bit once I browse through it.
And I see some of the old notes found their way in the TODO.

No need for Cc:, old address is still valid. Nowadays, who should I
contact to get list and CVS logs at a different address? Phil?

-- 
  Ky?sti M?lkki  <kyosti.malkki@welho.com>  +358 50 462 8786

i2c/kernel i2c-algo-bit.c

[Kyösti Mälkki]

On Sat, 1 Nov 2003, Jean Delvare wrote:

> > Modified Files:
> > 	i2c-algo-bit.c
> > Log Message:
> > (Khali) Fix sclhi() for adapters that do not have getscl().
> >         Enable bit_test for adapters that do not have getscl().
> >         Mostly rewrite test_bus(), cleaner and probably faster.
>
> I'd like reviewers and testers on this, since I plan to submit a similar
> for Linux 2.6. There are two distinct changes:
>
> 1* Fixed sclhi() for adapters that do not have getscl(). It looks like
> there was a udelay call missing in this case.

1*

Your fix for adapters not capable of reading SCL looks correct.
I introduced this bug as I moved udelay() call _after_ SCL is read back
as HIGH. Purpose of udelay() there is to guarantee SCL HIGH time.
I think we agree upon this change?

But, the bus has some capacitance and first call(s) to getscl() after
setscl(1) are likely to return LOW. This may slow down transmission and
generate undesirable amount of scheduling as cond_resched() is called.

Results of my bug fix: Earlier it could, rarely, output very short SCL
high pulses. Now it will, likely, output very long SCL high pulses.

To see i2c-algo-biths solution, search for "rdcount".

-- 
  Ky?sti M?lkki  <kyosti.malkki@welho.com>  +358 50 462 8786