From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 22:42:55 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 0048B3E5; Thu, 15 Jan 2015 22:42:54 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADF0ABA9; Thu, 15 Jan 2015 22:42:54 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id v8so13214206qal.8; Thu, 15 Jan 2015 14:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4KXmoYn4yn+vhsx2xMC5atSKR2GI96f+pkGx2XUWOVo=; b=ILtL1WgjbT5CwJ+tl4Fix9TJYhXslotLQq+N89fFWADVFo5MhlnjfxRn6JQ1LsLfX/ D7SJKiDcox2Uq0AZiEGUwIVNLrQxR4Vn8Pt9hdIeS9nP8sz5vmwWPaivH6yGowWLQB5Q iIJ8d5Sg/wec1P9purTa2lwGrKntoPAMpaW+0Bc03S/rC5FKiXOa/GzD+FhuIGfykddJ +HyTUsWv4Kfmafpv3CGswGW1aAWLAFrtbnmI4is887GMkElzv/bWJFXOS5O3zF1sNYHm OeZSonaQh1I8yzYEp0faartpZiWNenBKQG5dmGNn4KONp+uMnKvqymDPM+GEJVRzIcJ6 A0+A== MIME-Version: 1.0 X-Received: by 10.140.39.167 with SMTP id v36mr19321732qgv.77.1421361773851; Thu, 15 Jan 2015 14:42:53 -0800 (PST) Received: by 10.140.82.180 with HTTP; Thu, 15 Jan 2015 14:42:53 -0800 (PST) In-Reply-To: <54B7EB67.6010702@freebsd.org> References: <54B7EB67.6010702@freebsd.org> Date: Thu, 15 Jan 2015 23:42:53 +0100 Message-ID: Subject: Re: interrupt framework From: Svatopluk Kraus To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org 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 22:42:55 -0000 On Thu, Jan 15, 2015 at 5:31 PM, Nathan Whitehorn wrote: > > 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. > Hmm, we was not aware of that as we have taken something what was already designed this way. However, it's not problem to arrange things according to you comments. >> 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. > In standard MI interrupt framework, an interrupt event is created for an interrupt and intr_event_handle() is called to handle an interrupt when it comes. Many things happen in this functions before real filters and/or handlers are called. In former design, when controllers are chained, it's done on each of them - on each layer. So if a controller is fast enough and handles interrupts by a filter, we can call the filter without MI framework overhead. Thus we save time and stack space. And we do not have a problem to pass trapframe thru chained controllers. Further, it can be utilized by any interrupt where time is critical. >> 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" > > > _______________________________________________ > 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"