From owner-svn-src-all@FreeBSD.ORG Wed Jan 2 21:03:48 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D4796F9F; Wed, 2 Jan 2013 21:03:48 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp-out3.electric.net (smtp-out3.electric.net [72.35.12.187]) by mx1.freebsd.org (Postfix) with ESMTP id A5BA4301; Wed, 2 Jan 2013 21:03:47 +0000 (UTC) Received: from [204.11.168.155] (helo=securemail.onebox.com) by lada.electric.net with esmtp (Exim 4.77) (envelope-from ) id 1TqVTR-0005HB-Ut; Wed, 02 Jan 2013 13:03:41 -0800 Received: from localhost (unverified [49.224.182.145]) by securemail.onebox.com (Rockliffe SMTPRA 9.3.1) with ESMTP id ; Wed, 2 Jan 2013 16:03:44 -0500 Date: Thu, 3 Jan 2013 10:02:58 +1300 From: Andrew Turner To: "Robert N. M. Watson" Subject: Re: svn commit: r244899 - head/sys/mips/beri Message-ID: <20130103100258.2e22763f@fubar.geek.nz> In-Reply-To: <0E1E1A5C-BB34-4B82-828F-6FEE770A6037@FreeBSD.org> References: <201212311106.qBVB6chM016661@svn.freebsd.org> <20130102081746.5435db05@fubar.geek.nz> <20130102110856.7c280fd5@fubar.geek.nz> <0E1E1A5C-BB34-4B82-828F-6FEE770A6037@FreeBSD.org> Organization: SMTP: smtp.paradise.net.nz X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) X-Pirate: Arrrr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 21:03:48 -0000 On Wed, 2 Jan 2013 11:01:27 +0000 "Robert N. M. Watson" wrote: > > On 1 Jan 2013, at 22:08, Andrew Turner wrote: > > >> On a semi-related note: the current obstacle to moving more devices > >> over to using FDT on BERI is that our FDT implementation appears to > >> require a PIC to be configured. We're not actually using a PIC on > >> BERI currently. It works fine attached to nexus, as the implied > >> fallback for not having a PIC is to simply use the suitably > >> numbered interrupt wires direct into the MIPS. However, trying the > >> same setup described using FDT leads to an interrupt-related > >> warning at boot, and no interrupt being provided to the driver. I > >> suspect I need to provide a PIC-alike software component as a > >> fall-back for the non-PIC case. From a brief e-mail exchange with > >> JC, it sounds like the XLP FDT setup is actually not using > >> interrupts either, currently. > > > > I'm not sure if a PIC is required. From my reading of the code it > > appears not. By the look of it if you are using the nexus to > > handle interrupts you need to put an interrupts property in the > > device and "#interrupt-cells = <1>;" in the soc node. > > > > You will also need to implement an interrupt decode function and > > add it to the fdt_pic_table array. ARM has a number of almost > > identical copies of this function you can use for inspration. > > > This seemed to do the trick; what do you think of the attached? This > isn't a board-specific change, so I dropped it into the common > fdt_mips.c code. On the other hand, this left it a bit open as to > what the right compatible= line to use was, so feedback there most > welcome. The patch looks good. From my reading of [1] the compatible value should be something like "mips,mips4k" as it's value is of the form ",". I have been thinking the best way of merging these almost identical decode functions. Linux appears to do it by providing a per-controller function that can translate between the interrupt spec and the configuration allowing them to have a generic parsing function that doesn't need to check if the controller is compatible. I would like us to have something similar as it will remove the duplicate function. Andrew [1] http://www.devicetree.org/Device_Tree_Usage