On Mon, 2019-07-01 at 11:25 -0600, Warner Losh wrote: > On Mon, Jul 1, 2019 at 11:14 AM Poul-Henning Kamp <p...@phk.freebsd.dk > > > wrote: > > > -------- > > In message < > > canczdfofbvmxptnel4goqxtvp6zd-xrtja4rmuo1racy0jd...@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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
