Date: Sun, 16 May 2021 10:43:13 -0600 From: Ian Lepore <ian@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: hackers@freebsd.org Subject: Re: patch: make i2c(8) usable for scripting Message-ID: <058b3056a0adf05ac6e124a989b9b8250ff36ce3.camel@freebsd.org> In-Reply-To: <13972.1621147890@critter.freebsd.dk> References: <12056.1621109641@critter.freebsd.dk> <8d232feb354bf404426c51efe4953551ae2476c9.camel@freebsd.org> <13972.1621147890@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2021-05-16 at 06:51 +0000, Poul-Henning Kamp wrote: > -------- > Ian Lepore writes: > > > On Sat, 2021-05-15 at 20:14 +0000, Poul-Henning Kamp wrote: > > > The /dev/iic%d filedescriptor is opened and closed for every > > > single > > > command, in the hope that it will aid multiple separate programs > > > sharing I2C busses. I have not actually tried that yet, so it > > > may > > > need more work (exclusive opens etc.). > > > > There should be no need to do that. The i2c bus is arbitrated in > > iicbus/iiconf.c and most all the in-tree drivers now use either > > explicit iicbus_request_bus() calls, or use > > iicbus_transfer_excl(). > > Certainly users of iic(4) don't need to be protected from each > > other; > > everything in the driver that uses the bus does so inside of > > request_bus / release_bus calls. > > How does that work when i2c(8) (by default) issues discrete > start/stop commands ? > > Related to that: Should i2c(8)'s -m default be changed to 'tr' ? > Start locks the bus and stop releases it. Yeah, that's a marginal design, it lets userland keep everybody including kernel drivers off the bus indefinitely. i2c(8) is very much a "you have all the power, use it wisely" type of tool. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?058b3056a0adf05ac6e124a989b9b8250ff36ce3.camel>