Date: Fri, 04 Sep 2020 14:44:04 +0400 From: Alexander Mishin <mishin@mh.net.ru> To: freebsd-arm@freebsd.org Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) Message-ID: <451b7285054c35b03c3d5427afaf7d65@mh.net.ru> In-Reply-To: <28253dc7881eff6ae315d33f5156e335@mh.net.ru> References: <0496ebc5628a015c005c150549e1e70a@mh.net.ru> <20200901221839.GY4213@funkthat.com> <7498213a-28d8-f20c-35ae-97aaf2796c1e@FreeBSD.org> <8c4593191cccecfe6927c6628e62c742@mh.net.ru> <739e424429ecde302e11df4c183d4e62c263a6d6.camel@freebsd.org> <28253dc7881eff6ae315d33f5156e335@mh.net.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Mishin писал 2020-09-04 10:00: > Ian Lepore писал 2020-09-03 18:48: >> On Thu, 2020-09-03 at 15:02 +0400, Alexander Mishin wrote: >>> Andriy Gapon писал 2020-09-03 11:29: >>> > On 02/09/2020 01:18, John-Mark Gurney wrote: >>> > > So my reading of the twsi driver is that it handles things correctly >>> > > allowing devices pre-interrupts to attach, and using interrupts for >>> > > transfers post-cold. >>> > >>> > I just want to note that twsi uses _completely_ different code for >>> > polled and >>> > interrupt modes. So, while either mode should be active at correct >>> > times, I >>> > cannot certify that the polled mode works correctly for all transfer >>> > types. >>> > I haven't reviewed the polled mode code. >>> >>> This adds some more light on my question. >>> >>> As a result: >>> For twsi I use iicbb_transfer() (as Emmanuel Vadot recommended to >>> someone on the mailing list). >>> It is definitely not works for my driver, until interrupts went >>> enabled. >>> But it works perfectly well with the config_intrhook(). >>> >>> I have never tried iicbus_write() at boot time yet, but I think I'll >>> try, just to know for the future. >>> >>> Thanks >>> >> All i2c slave drivers should be using iicbus_transfer_excl() or the >> iicdev_readfrom()/iicdev_writeto() helper functions. The only time to >> use iicbus_transfer() directly is when you need to conduct a dialog >> with one or more slaves using multiple transactions and it's important >> to keep the bus locked across the entire series of transactions for >> some reason (meaning you must handle the acquire/release bus stuff >> yourself). There is virtually never a reason to call the low-level >> start/stop/read/write functions directly. >> >> It's a pity that this stuff is so horribly documented. It has evolved >> extensively over the years, not always in good ways, and documentation >> and examples either don't exist or haven't kept up. >> >> Bottom line: if the twsi driver has the config_intrhook logic in it >> then your driver shouldn't need it. If you do need it, something is >> broken, either in your driver or in the twsi driver, and we should >> figure out what the real problem is. >> >> -- Ian > > Many, many thanks for such a portion of valuable information. > Went to look for examples in the kernel sources. > Yes! I found the iiconf.c with iicdev_(readto|writeto) and iicbus_transfer_excl definitions. "Well, now all ducks are ours!" Thanks once more
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?451b7285054c35b03c3d5427afaf7d65>