Date: Sat, 17 Jan 2015 09:14:48 -0800 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-arm@freebsd.org Subject: Re: interrupt framework Message-ID: <54BA9888.1020303@freebsd.org> In-Reply-To: <CAFHCsPX5kG_v-F-cjpyMQsT_b386eok=mqWW0%2BEUb_4-_1Otnw@mail.gmail.com> References: <CAFHCsPX5kG_v-F-cjpyMQsT_b386eok=mqWW0%2BEUb_4-_1Otnw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > 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. > > 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(). > > 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. > > Svata > I took a look through intrng.c and had a couple comments about the FDT mapping stuff: 1. You use the device tree node handles as lookup keys rather than xref handles. These are not necessarily stable, so you should use xref handles instead. 2. If you make change (1), you don't depend on any OF_* stuff and can use the same code with the PIC node ID as an opaque key on non-FDT platforms. We do this on PowerPC as well, which has been very useful. It will also save some #ifdef. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54BA9888.1020303>