From owner-freebsd-arm@freebsd.org Thu Sep 3 14:48:27 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 483233C0562 for ; Thu, 3 Sep 2020 14:48:27 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 4Bj3Zy4pcMz4X6L for ; Thu, 3 Sep 2020 14:48:26 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1599144505; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=QnMHuovpyCnhDEsbpnnk6zHH7fQFyIlhSrCw9WpyQCGvPoehu2e9thQz/hWcdUjT19gnRNfGXNF53 N/wS2RyaSvyK57oD1bjEeXchT/L63hrbK8rd346kPLJvmmZnidwRRjzTNwjfp0fKP9yoYX3ChI6umH 8GKFRy8c+6DZqmknvLkltcPP8whiskiprZP+0rnl6sIwhoyrPrFvYchjrBOF/aC8Kocq/0lh0W4/Q3 qVg0x1+uUwVUQE5oJtU7rlazsXII0vNLZR9ZgtGP6qvFL2OmFkrcWFw1U9y6ow0G7DxHJzaVtnUfk8 jS22Q0iODV6tmELtYVS3yZcYVQwz7eA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=9/WseZpBJ7ktk6LXGxTiPIxCG5BQo289MWOLgAV/fsc=; b=HtHhz/la5lvr5MNhFTjULl4rX/xfYiErj0q5sfYP2teUGmHupv5VDohseAl33ZKfhdcDNfK6JbiMj h4m09YHpnVK+O4E7Rr3moXN+APMYUW+eg89xWMDRESyKmxCA8c/xLqOjKXjztRQBBC4Y4fZdq8/Lpl lF/WLfQFazXzZuDHNk/ZNYe3IZpzqN3+tyiXc72x/A+PdxFfbz0E0/QsWFfD/u6PDbld1aTW8zxFOP 4PuWoC8Hb5y+J0d02FpBPhM0Ve9tEwmRq76z9jV2/ie6nko8Sf8OMlVYtApsiM5VguL/FY0MqYMkxU q6r2eOfJnSjtVt6dJ0KherplSxmNt2w== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=9/WseZpBJ7ktk6LXGxTiPIxCG5BQo289MWOLgAV/fsc=; b=IyJpMGA0j0ZJMJ0KCaolfMm4UlbCilbQxYG/TYyedf6R9s4nYh2mF7u6CE7LQql9prU1VTrfkwaqp gMD8bJWyuSVBhv0YC9zuYzC9gmv9GIMwgSNYEI31nuZ8UrdA+EGdNvcwQe7fT3Q2LsazLxq05Fsuyc Atf+KxhBmC80KcYxdLdhBl31/5O4+PmlD11miHBDT2m9MA5m9AclAWVFq72WFQJFXoiqOrP+dx840q FwQrDFicBgduhusUcFiw9xsEX4ODDy2L6VW20qMIAGg0ZKKlri0N3DnCAmZR9P+MMaO7GYab5r416R PBzcNsklL0RvP2NeQVwlchKEZjZhE1w== X-MHO-RoutePath: aGlwcGll X-MHO-User: 81bc82da-edf4-11ea-9e11-df46ed8f892f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 81bc82da-edf4-11ea-9e11-df46ed8f892f; Thu, 03 Sep 2020 14:48:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 083EmIT6050101; Thu, 3 Sep 2020 08:48:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <739e424429ecde302e11df4c183d4e62c263a6d6.camel@freebsd.org> Subject: Re: Re: Re: Re: Re: Kmod driver at iicbus. attach() and config_intrhook(9) From: Ian Lepore To: Alexander Mishin , freebsd-arm@freebsd.org Date: Thu, 03 Sep 2020 08:48:18 -0600 In-Reply-To: <8c4593191cccecfe6927c6628e62c742@mh.net.ru> References: <0496ebc5628a015c005c150549e1e70a@mh.net.ru> <20200901221839.GY4213@funkthat.com> <7498213a-28d8-f20c-35ae-97aaf2796c1e@FreeBSD.org> <8c4593191cccecfe6927c6628e62c742@mh.net.ru> Content-Type: text/plain; charset="koi8-r" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Bj3Zy4pcMz4X6L X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] 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: Thu, 03 Sep 2020 14:48:27 -0000 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