Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined?

[Andriy Gapon]

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
> achieve:
> 
>     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
> it.

Indeed, these are the most used patterns, so makes sense to have common routines
for them.

-- 
Andriy Gapon