From owner-freebsd-arm@freebsd.org Fri Sep 4 07:45:14 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0FC973D9E0F for ; Fri, 4 Sep 2020 07:45:14 +0000 (UTC) (envelope-from mishin@mh.net.ru) Received: from frog.mh.net.ru (mh.balakovo.san.ru [88.147.158.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BjV883t6bz4f7n for ; Fri, 4 Sep 2020 07:45:11 +0000 (UTC) (envelope-from mishin@mh.net.ru) Received: from webmail.mh.net.ru (mouse.home [192.168.5.6]) by frog.mh.net.ru (Postfix) with ESMTPSA id 246B419643 for ; Fri, 4 Sep 2020 11:45:07 +0400 (+04) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 04 Sep 2020 11:45:06 +0400 From: Alexander Mishin To: freebsd-arm@freebsd.org Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) In-Reply-To: <739e424429ecde302e11df4c183d4e62c263a6d6.camel@freebsd.org> References: <0496ebc5628a015c005c150549e1e70a@mh.net.ru> <20200901221839.GY4213@funkthat.com> <7498213a-28d8-f20c-35ae-97aaf2796c1e@FreeBSD.org> <8c4593191cccecfe6927c6628e62c742@mh.net.ru> <739e424429ecde302e11df4c183d4e62c263a6d6.camel@freebsd.org> User-Agent: Roundcube Webmail/1.4.2 Message-ID: <9a2b66d4d8b8528b2656b629a5813999@mh.net.ru> X-Sender: mishin@mh.net.ru X-Rspamd-Queue-Id: 4BjV883t6bz4f7n X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=mh.net.ru (policy=none); spf=fail (mx1.freebsd.org: domain of mishin@mh.net.ru does not designate 88.147.158.22 as permitted sender) smtp.mailfrom=mishin@mh.net.ru X-Spamd-Result: default: False [1.82 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_FAIL(1.00)[-all]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.50)[0.503]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(0.27)[0.270]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; NEURAL_SPAM_LONG(0.05)[0.051]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12389, ipnet:88.147.128.0/17, country:RU]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; DMARC_POLICY_SOFTFAIL(0.10)[mh.net.ru : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 07:45:14 -0000 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 >> > > iicbb_transfer() is for bit-bang i2c; hopefully that was a typo. > > 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 Yes, it was a typo. Of course I meant iicbus_transfer() (not iicbb_transfer), sorry for misleading.