From owner-freebsd-arm@freebsd.org Thu Aug 20 22:51:41 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 B75573AB439 for ; Thu, 20 Aug 2020 22:51:41 +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 4BXfz11mZdz46ss for ; Thu, 20 Aug 2020 22:51:40 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1597963899; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Jbi0jmM+rpql1MVHfBeccLeWmRqMHpGvY7x/8nMjFkUzsq9h6c/Y7CRGQQT5wdseecuGdZsIStCuX rkH4hkUeptMmWrgDIUX7iDfWv7N+qSjv8lpfTVI/1Ey7pXXUqOHPgVIHuIFpIr0YmvQTMSwGYW72Gb fAG8I5T/n47SjUdXj5Ow8x5Tl2zhPOr+6WDc/t6yh7p30m/VbAKcESdvhWbAE9kHoz/AbWLthaJbJ8 x3wbHJSWxF3MOVWyoCJDmdFIElVT0M6r2Leq1q2z7sG0P/qyYaklQ+bbWXiMJ1wqsd67nZgdY+Scuu ar2YM8jjF1C7MhVzcUawrDBEoyAFBAg== 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:cc:to:from:subject:message-id:dkim-signature:from; bh=9x1eIqhHeX+oNg7aQNH6AECjJIz2fepwaXJPAdClg34=; b=r9GrSr+4w8jEmbjknqW8Z1yI4F8WFXKIphxRbS0Uxgs3GUR5etwwmYWWtie9rwOR1aV48YLVUXGJg 01xmRS6lIleZ4VnVxAPzUh9v3TQ2pZ53/sdlVO3Iu8ffjq54FQbf38HcURzLjjkRNbnCC4TxHCSNYe iQZnfvii+sN+hqySlPi7NzkwtKewlfB+t85y10EyYFe3kK9T60XdxAuEdIBtDwUNtacKhWOI+NGBtr xRnIXEi7i9g96+J3J+pO6TFkrUf4A6K3FQcf65q1lkxVvQxvQ6tyQiJoxR8v/w5tN2Hb8482BInO2I E/4X9SswZyRFbndSvKAfwYqMelD4FHg== 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:cc:to:from:subject:message-id:from; bh=9x1eIqhHeX+oNg7aQNH6AECjJIz2fepwaXJPAdClg34=; b=pP6m+f5OiDTyokrF3Ej9/W0FbkkQIiEMxzyHzu3sRXrPeYGBCHWCSxIR08vUhn11sA8zRu+s2jotg 0f4Gv/uVDjFM74hYXUKv7bNSXP1Hbg1J3RlfwqtsHu4j7/Qochjvb0aPmSbvNsNEoHWMABVFDb0AR8 bwxpml1ISfhn10B7uon0TiATz3WV5oJL6/DuIc7sDZrKpmPb1J4Be1PEmQtvYby+CVNwHwVTPkgK46 CEK4ra0763JcjYTqS2HUXoOaa1nM+7L/CrFbXMJoPVW3DQyJIWNsoFDjJ5RNpoPf9l3C/T5G0xHZR5 Ht/M5bWYAii5554VMpid4/t8q6oBwjQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: b073419d-e337-11ea-b630-6b8aa7872eb8 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 b073419d-e337-11ea-b630-6b8aa7872eb8; Thu, 20 Aug 2020 22:51:38 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 07KMpUgP094345; Thu, 20 Aug 2020 16:51:30 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Kmod driver at iicbus. attach() and config_intrhook(9) From: Ian Lepore To: John-Mark Gurney , Alexander Mishin Cc: freebsd-arm@freebsd.org Date: Thu, 20 Aug 2020 16:51:30 -0600 In-Reply-To: <20200820223918.GC4213@funkthat.com> References: <7fabb65d99aaa74775c1daa91bffb873@mh.net.ru> <3249fa7e-554a-83ef-57b2-7c38aa0b4591@FreeBSD.org> <20200819072409.GA59949@bluezbox.com> <05145b71692af74b103bb226a2e93a15e1e851cb.camel@freebsd.org> <20200820223918.GC4213@funkthat.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BXfz11mZdz46ss X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; local_wl_from(0.00)[freebsd.org] 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, 20 Aug 2020 22:51:41 -0000 On Thu, 2020-08-20 at 15:39 -0700, John-Mark Gurney wrote: > Alexander Mishin wrote this message on Thu, Aug 20, 2020 at 10:07 > +0400: > > Ian Lepore ?????????? 2020-08-19 19:39: > > > On Wed, 2020-08-19 at 00:24 -0700, Oleksandr Tymoshenko wrote: > > > > Andriy Gapon (avg@FreeBSD.org) wrote: > > > > > On 18/08/2020 22:05, Alexander Mishin wrote: > > > > > > Hi > > > > > > ... > > > > > > But I see that some other devices (from /usr/src/sys/dev) > > > > > > uses > > > > > > CONFIG_INTRHOOK(9) > > > > > > on attach() for initialize themselfs. > > > > > > I wonder if I need this too? ... > > > > > > > > > > This is usually needed when a driver needs to talk to its > > > > > device > > > > > while > > > > > attaching. E.g., to set some initial configuration or to > > > > > confirm > > > > > device's > > > > > identity, etc. > > > > > > > > To extend Andriy's explanation a bit: all these operations may > > > > perform > > > > I2C transfers and most I2C controllers use interrupts to get > > > > notified > > > > about tranfer status change (finished, error, etc...). There is > > > > no > > > > guarantee that when driver's attach method is called interrupts > > > > are > > > > globally enabled. What would happen in this case is: I2C > > > > controller > > > > is going to initiate I2C operation and wait for an interrupt > > > > that's > > > > never going to be delivered. CONFIG_INTRHOOK is a solution for > > > > this > > > > problem, if your attach method requires interrupts - just split > > > > it > > > > in two parts and postpone running interrupt-dependent part > > > > until > > > > after > > > > interrupts are globally enabled. > > > > > > > > > > A note about all this: It should never be necessary for an i2c > > > slave > > > device driver to do this. The reason it's needed is because many > > > i2c > > > controller drivers attach the iicbus from their attach() routine > > > even > > > though they can't actually do i2c IO until interrupts are > > > available. > > > It is these controller drivers that should have the intrhook > > > logic to > > > not call bus_generic_attach() until interrupts are available if > > > they > > > can't do IO until interrupts are available. > > > > > > It has long been my goal to fix all our i2c controller drivers to > > > behave correctly, so that i2c slave device drivers don't all need > > > the > > > intrhook logic. But somehow I never get around to it. > > > > I think, it would be helpful, as it would be possible to return an > > error > > on early stage, from attach(), if there is no connection with the > > configured device. > > Looks like there's a function bus_delayed_attach_children designed > exactly for this: > * Many buses can't run transactions on the bus which children need > to probe and > * attach until after interrupts and/or timers are running. This > function > * delays their attach until interrupts and timers are enabled. > > and it looks like a couple controllers are already using it, imx_i2c > and ti_i2c... > > It looks like maybe a simple replace of bus_generic_attach w/ > bus_delayed_attach_children should be enough on those w/ > interrupts... > > Is there any argument for doing it for ALL controllers instead of > just > some? > > Poking around some, and it looks like some (one) drivers "pretend" to > use interrupts, but just busy wait instead, e.g. exynos5... > Hmm, yeah, it looks like more has been done along these lines than I remembered. In fact, the work may be done. Some i2c controllers have to work properly before interrupts are available, to control things like PMIC chips that are required very early in device configuration. Typically they have some sort of polling mechanism that's used early, and revert to using interrupts once they're available. The allwinner and rockchip drivers work that way. -- Ian