From owner-freebsd-arm@FreeBSD.ORG Mon Jan 19 23:00:18 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 3E140E9D; Mon, 19 Jan 2015 23:00:18 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (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 EA5AA752; Mon, 19 Jan 2015 23:00:17 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id s11so7914631qcv.5; Mon, 19 Jan 2015 15:00:16 -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=kJ+JaxPF22N/xmeW6wv2t74y8iFl81RVqZYGz5KdVzk=; b=p+vByMTGltofcbba/Xw/39gaYaND/YtX6GkMK7APrhpj8m2ydKzli1f3XU8YD6/PJu Dvr/K6vaZ14qcp+95YHY+yM1cDubOFrFpYUMn6eAFdIwWhZyJO6AQXtPxMw/hPbeiju2 18Ryj6IustbIdnFR0TamVWH0GQbqLn8QAtmvMamUJua5d/xvmTxKrbaZ90PEiI6fp6+M yBfXjbANDJhWqZHx2fdBVsq6876kKSO8ofpDsXa1Ynp8h4ONENTAPW9E/iIe4B87r+Q5 cp0MpOypdIcBoe4U+gf9bR4DkmcvMJtngttAFWHQ3bi8uHic1bUwzHZn5WKT81K0BdZz M3ng== MIME-Version: 1.0 X-Received: by 10.140.49.5 with SMTP id p5mr50114970qga.15.1421708413942; Mon, 19 Jan 2015 15:00:13 -0800 (PST) Received: by 10.140.82.180 with HTTP; Mon, 19 Jan 2015 15:00:13 -0800 (PST) In-Reply-To: <54BD3F86.3010901@freebsd.org> References: <54BA9888.1020303@freebsd.org> <54BD3F86.3010901@freebsd.org> Date: Tue, 20 Jan 2015 00:00:13 +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: Mon, 19 Jan 2015 23:00:18 -0000 On Mon, Jan 19, 2015 at 6:31 PM, Nathan Whitehorn wrote: > > On 01/19/15 08:42, Svatopluk Kraus wrote: >> >> On Sat, Jan 17, 2015 at 6:14 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. >>>> >>>> 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 >>> >> Thanks. I did changes due to (1). Considering (2), I understand what >> you are doing in PowerPC, but it's not something I could adapt so >> easily. Hiding phandle_t behind uint32_t is clever, saves a few FDT >> #ifdefs, but makes things a little mysterious. Even if we will think >> about this uint32_t like some kind of key, there should be a function >> which convert phandle_t to that uint32_t key. >> >> I'm attaching new version of intrng.c with change (1) and with some >> more little adjustments. >> >> Svata > > > Thanks! How do you plan to support multiple PICs on non-FDT platforms then? > It looks like it just fails at the moment. > -Nathan There is the following mapping function: u_int arm_namespace_map_irq(device_t dev, uint8_t type, uint16_t num); I named it "namespace" but it can be named another way. I think it does same like in PowerPC when node is NULL. However, there is one more argument - type. For example, it's used for IPI mapping in intrng.c. Svata