Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined?
avg at FreeBSD.org
Sat Mar 24 16:47:29 UTC 2018
On 24/03/2018 17:43, Ian Lepore wrote:
> I think our whole interface for transfers is conceptually broken. I
> would like to just redefine the behavior of the interface. I think what
> I want is basically the same thing that nostop ivar was trying to
> Ignore the existing start/stop flags in the transfer structures.
> When you pass an array of transfers, there is one bus START at the
> beginning, one bus STOP at the end, and an automatic REPEAT_START
> between any two transfers in the array where the slave address or
> direction changes. When there are two adjacent transfers in the
> array with the same address and direction, that's just one long
> continuous flow of bytes -- effectively, it's scatter/gather IO.
I completely agree. If you have a transfer / transaction, then why have
STOP+START in the middle it. The current default behavior just does not make
sense to me.
> As an optimization, we could define an IICBUS_STOP flag that could be
> added to any transfer in the array to force a full STOP/START sequence
> after that transfer and before the next. That would amount to basically
> a minor optimization... it would be identical to just calling transfer
> twice. So I'm not even sure it's a good idea.
Linux has I2C_M_STOP to force a stop. I guess that it's a workaround for some
broken slaves that are confused by repeated start. But as you say, just
splitting the transfers would work as well.
> We might need to leave the current broken interface in place for out-
> of-tree code like proprietary drivers, and define a new transfer method
> that works the new way.
That would make sense to do.
> When I started looking at all existing callers of iicbus_transfer() I
> came to the conclusion that almost all of them followed such identical
> patterns that I wrote the iicdev_readfrom()/writeto() functions. I
> figured I would run through the system converting everything I could to
> those new functions, then whatever changes need to be made to the
> interface would almost all be in just a couple functions. But that
> project bogged down then other things came along and I forgot all about
Indeed, these are the most used patterns, so makes sense to have common routines
More information about the freebsd-hackers