Re: i2c bit banging timeout for SCL

On Mon, Jul 1, 2019 at 10:30 AM Ian Lepore <ian_at_freebsd.org> wrote:

> On Mon, 2019-07-01 at 19:03 +0300, Andriy Gapon wrote:
> > iicbb driver has a hardcoded timeout that defines how long the driver
> waits for
> >  SCL line to go high after the driver releases it to float.  Sometimes
> slaves
> > hold the line low until they are ready to continue with the
> communication.
> > As a side note, the timeout means that the driver just goes on as if the
> line
> > became high.  Maybe it should produce an error instead.
> >
> > Anyway, I would like to increase the current timeout of 100 x 10us to
> 1000 x
> > 10us.  The rationale is that there are many slave devices, like sensors,
> that
> > take about 10 ms to return a result.  So, I think that it makes sense to
> play
> > nice with such devices by default.
> >
> > Probably I'll add a sysctl for that parameter while I'll be there.
> >
> > Any objections?
>
> Many (perhaps most?) modern i2c slave devices are both i2c and smbus
> compatible, and the smbus slave timeout is 35ms, so that wouldn't be a
> bad default value.
>

I'd concur here. Someone else will have a device that takes 20ms to reply
and wonder why we're broken...

The only issue, really, is that this timeout is a busy loop and there may
be I/O bus contention introduced on these systems. My gut tells me that we
should look out for that, but bump the default timeout to the limit of the
spec we implement. There's no I2C limit, and there is a smbus one, so let's
go with the latter. Most of the time, most of the devices will react within
a millisecond anyway, which isn't terrible for a bit-banged situation.


> I don't think ignoring the error and forging ahead is a good idea.  It
> should return an error, and perhaps it should use the bitbang bus-
> recovery sequence (from iic_recover_bus.c) to unwedge the slave device.
>

Also agreed.

Warner