Re: i2c bit banging timeout for SCL

On Mon, 2019-07-01 at 11:25 -0600, Warner Losh wrote:
> On Mon, Jul 1, 2019 at 11:14 AM Poul-Henning Kamp <phk_at_phk.freebsd.dk
> >
> wrote:
> 
> > --------
> > In message <
> > CANCZdfoFBvmxPtnEL4GOqXTvp6Zd-xrtja4rmUO1rAcy0JdeSw_at_mail.gmail.com>
> > ,
> > Warner Losh writes:
> > 
> > > The only issue, really, is that this timeout is a busy loop and
> > > there may
> > > be I/O bus contention introduced on these systems.
> > 
> > Does it have to be a busy loop for the entire duration ?
> > 
> > Spin for the median, timeout+poll for the rest of the time ?
> > 
> 
> That's a good suggestion. I'd be inclined to spin for 1 tick or so,
> then do
> a timeout per tick after that (eg, shift from DELAY to pause(1)). It
> won't
> be super accurate or high performance, but when the devices are slow,
> that
> would add only a little extra time.
> 
> Ideally, that's what we'd do. In the short term, bumping the timeout
> wouldn't be horrible.
> 
> Warner

Most of the DELAY() in i2c bitbang is just the idle time before
toggling the clock line to achieve the 100khz bus rate.  That's a 10us
delay, and on modern hardware those delays should be pause() calls
because that's enough time to get useful work done.  When polling for
ack at the end of a byte, using a DELAY(1) loop makes more sense
(actually, just polling without delay may make even more sense, since
DELAY() is generally just polling a clock register).

Hmm, actually, it looks like iicbb hardcodes the bus frequency delay as
10us and delays after every toggle, so I guess it's really running the
bus at 50khz.

-- Ian