From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 16:31:45 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 5798FDCB for ; Thu, 15 Jan 2015 16:31:45 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B73CB24 for ; Thu, 15 Jan 2015 16:31:44 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id t0FGVZ00013648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Jan 2015 08:31:36 -0800 Message-ID: <54B7EB67.6010702@freebsd.org> Date: Thu, 15 Jan 2015 08:31:35 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: interrupt framework References: In-Reply-To: X-Sonic-CAuth: UmFuZG9tSVboWSKzPGiV1xetyw+wDS3RM26bfU/hs+XNezxSl2v8QqTgKJu9nfkBEofQm1n6jooieGxtkEcL5Ae6sCVmKXuCHmhCjOHiDeI= X-Sonic-ID: C;vCPp+NOc5BGjT/CsS5uE/A== M;DvFB+dOc5BGjT/CsS5uE/A== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 16:31:45 -0000 On 01/15/15 05:51, Svatopluk Kraus wrote: > Hi community, > > I and Michal Meloun have done some work on ARM interrupt framework and > this is the result. > > We've started with intrng project with Ian's WIP changes, have looked > at Andrew's ARM64 git repository, and this is how we think an > interrupt framework should look like. We've implemented it with > removable interrupt controllers in mind (PCI world). It's not finished > from this point of view, however some functions are more complex > because of it. > > It's tested on pandaboard and only GIC is implemented now. There is no > problem to implement it to other controllers. We are open to questions > and can finish our work considering any comments. Whoever is waiting > for ARM interrupt framework as we were, you are welcome to test it. > Whoever is welcome. The patches are done against FreeBSD-11-current > revision 277210. There are two new files. > > ARM_INTRNG option must be added to board configuration file for new framework. > > There are still some things not implemented and some things which > should be discussed like PPI support. For example, how to enable PPI > interrupt on other CPUs when they are already running? > > We keep in mind that an interrupt framework should be helpfull but > general enough to not dictate interrupt controlles too much. Thus we > try to keep some things as much separated as possible. Each interrupt > is represented by an interrupt source (ISRC) in the framework. An ISRC > is described by an interrupt number which is much more an unique > resource handle - totally independent on internal representation of > interrupts in any interrupt controller. This is a good design. > An interrupt is described by cells in FDT world. The cells can be > decoded only by associated interrupt controller and as such, they are > transparent for interrupt framework. The framework provides > arm_fdt_map_irq() function which maps this transparent cells to an > interrupt number. It creates an ISRC, saves cells on it, and once when > associated interrupt controller is registered, it provides the ISRC > with cells into the controller. > > It's a controller responsibility to save an ISRC associated with > cells. An ISRC is transparent for any controller. However, an > controller can set/get its data to/from an ISRC. Further, an > controller should set a name to an ISRC according to internal > representation of associated interrupt. I'm assuming you are referring to arm_describe_irq? I had three comments on that: 1. Can you please make it part of the same API as ofw_bus_map_irq() rather than an out-of-band thing? This will let other platforms use it. 2. Once you've done that, you can remove all the #ifdef from simplebus. I would strongly prefer it not gain platform-specific #ifdef. 3. We should not be adding new things to machine/fdt.h unless they are really internal platforms APIs for reading the FDT. And even then, the header should probably disappear soon. FDT_MAP_IRQ() is used only in arm/intr.c, for example, and should be replaced by a direct invocation of arm_fdt_map_intr(). arm_describe_irq() should not join it there. > An controller interrupt dispatch function can call framework only if > it has associated ISRC to received interrupt. > > For legacy reason, there is arm_namespace_map_irq() function. An > interrupt is described by namespace type and a number from the > namespace. It's intented for use with no FDT drivers. Now, it's used > for mapping an IPI on a controller. > > We think that it's better to call chained controllers (with filter > only) without MI interrupt framework overhead, so we implemented > shortcut. It could be utilized by INTR_SOLO flag during > bus_setup_intr(). Can you describe the shortcut? We never ended up needing something like this on PowerPC. > Only an interrupt controller can really know its position in interrupt > controller's tree. So root controller must claim itself as a root. In > FDT world, according to ePAPR approved version 1.1 from 08 April 2011, > page 30: > > "The root of the interrupt tree is determined when traversal of the > interrupt tree reaches an interrupt controller node without an > interrupts property and thus no explicit interrupt parent." > > Thus there are no need for any non-standard things in DTS files. Right, this is what we did on PPC. -Nathan > Svata > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"