From owner-freebsd-arm@FreeBSD.ORG Mon May 25 00:36:27 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C713E84 for ; Mon, 25 May 2015 00:36:27 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) by mx1.freebsd.org (Postfix) with SMTP id 054BEF20 for ; Mon, 25 May 2015 00:36:26 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 25 May 2015 00:36:37 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4P0aJil009148; Sun, 24 May 2015 18:36:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1432514179.1200.17.camel@freebsd.org> Subject: Re: panic: arm_unmask_irq [was: Re: TI platforms code update: switching to vendor FDT data] From: Ian Lepore To: Marcel Moolenaar Cc: Oleksandr Tymoshenko , "freebsd-arm@freebsd.org List" Date: Sun, 24 May 2015 18:36:19 -0600 In-Reply-To: <8EC96924-4D33-4AF8-87B7-586441601D0B@xcllnt.net> References: <72E1D87A-1CEF-4719-907E-CF8E9D720FD1@xcllnt.net> <3741A6A7-1185-4E5A-9E98-22F5A6C730DC@freebsd.org> <1432512966.1200.15.camel@freebsd.org> <8EC96924-4D33-4AF8-87B7-586441601D0B@xcllnt.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 00:36:27 -0000 On Sun, 2015-05-24 at 17:33 -0700, Marcel Moolenaar wrote: > > On May 24, 2015, at 5:16 PM, Ian Lepore wrote: > > > > Shouldn't the driver attach order be controlled with BUS_PASS numbers > > now? That's been required with other socs that moved to the standard > > dts data where we don't control the order of the nodes in the file. > > The problem is different in my case, but yes it was the first > thing I suspected without digging deeper: > > fbsdvm64% svn diff sys/arm > Index: sys/arm/ti/aintc.c > =================================================================== > --- sys/arm/ti/aintc.c (revision 283321) > +++ sys/arm/ti/aintc.c (working copy) > @@ -156,7 +156,8 @@ > > static devclass_t ti_aintc_devclass; > > -DRIVER_MODULE(aintc, simplebus, ti_aintc_driver, ti_aintc_devclass, 0, 0); > +EARLY_DRIVER_MODULE(aintc, simplebus, ti_aintc_driver, ti_aintc_devclass, > + 0, 0, BUS_PASS_ORDER_EARLY); > > int > arm_get_next_irq(int last_irq) > > > -- > Marcel Moolenaar > marcel@xcllnt.net > For an interrupt controller that should probably be BUS_PASS_INTERRUPT + BUS_PASS_ORDER_MIDDLE We have to do some fine-grained tuning in some cases and there are only a few predefined categories and they're spaced really close together. -- Ian