Date: Sat, 24 Mar 2018 18:47:24 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Ian Lepore <ian@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Cc: Konstantin Belousov <kib@freebsd.org> Subject: Re: Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined? Message-ID: <2b49cfed-1aeb-47c8-4722-2cf2ceb4dc40@FreeBSD.org> In-Reply-To: <1521906199.51564.19.camel@freebsd.org> References: <CANC_bnOVAb7R%2Bc_8x66Gz5A1nNjJQ8NXpkaF4A85N0gnEjyO%2Bw@mail.gmail.com> <1521383420.99081.87.camel@freebsd.org> <0b0dee4b-e958-e25c-72d9-1ca296495802@FreeBSD.org> <1521906199.51564.19.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2b49cfed-1aeb-47c8-4722-2cf2ceb4dc40>