From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 17:52:54 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEA4B215 for ; Wed, 21 Jan 2015 17:52:54 +0000 (UTC) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (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 7147B600 for ; Wed, 21 Jan 2015 17:52:54 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id g201so5076397oib.4 for ; Wed, 21 Jan 2015 09:52:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=iFP1JdWHp728xD1DVYt2CwjimiIjJ66TNobVWh/aesU=; b=FN2RQ1hg7mDFffvLIyZgMxMgRbaJwOopk+wJehilDLBTr3qjn7FwB9DPD8NCAsWtP4 DLVEN/1QGqhv/Xong0xNx3fP3sVO3pU6RFL9wfd5N/NI5PK8ffjC5+3flBaPOBNCO3vi zl97JDSNv449yWM/EgSwb+/5ddqhkPwp4FyaOUUKfBmgSMAe3qoPLr6BjD8xufWpImBL 9mYLoguQNt0jsfNVQD0z5mLF7QLh1Gph605eq7lDOI+rH5ACQD25+KNggCGDxIwQhXrs nUr9XVp8ssUHC9bZWDBKUwzl8JvKaBNGmmLEg11k9gCGje3kJgKpbu/B3qhZUTfuQQR0 KEKA== X-Gm-Message-State: ALoCoQmnrVVq8ONwJhyryYyZn+dvxGBDzT4m/SWtma6btur6+DVplNOIZfU9OlPzr8Slb1po51VZ X-Received: by 10.60.124.194 with SMTP id mk2mr18008952oeb.79.1421862773272; Wed, 21 Jan 2015 09:52:53 -0800 (PST) Received: from [192.168.43.169] (mc42636d0.tmodns.net. [208.54.38.196]) by mx.google.com with ESMTPSA id a129sm3784694oih.17.2015.01.21.09.52.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 09:52:48 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: interrupt framework From: Warner Losh In-Reply-To: <54BE7E6D.6060800@freebsd.org> Date: Wed, 21 Jan 2015 10:50:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54BA9888.1020303@freebsd.org> <54BD3F86.3010901@freebsd.org> <54BD9794.4080204@freebsd.org> <54BE7E6D.6060800@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1993) 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: Wed, 21 Jan 2015 17:52:54 -0000 > On Jan 20, 2015, at 9:12 AM, Nathan Whitehorn = wrote: >=20 >=20 > On 01/20/15 03:19, Svatopluk Kraus wrote: >> On Tue, Jan 20, 2015 at 12:47 AM, Nathan Whitehorn >> wrote: >>> On 01/19/15 15:00, Svatopluk Kraus wrote: >>>> 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, >>>>>>>>=20 >>>>>>>> I and Michal Meloun have done some work on ARM interrupt = framework and >>>>>>>> this is the result. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> ARM_INTRNG option must be added to board configuration file for = new >>>>>>>> framework. >>>>>>>>=20 >>>>>>>> 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? >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> An controller interrupt dispatch function can call framework = only if >>>>>>>> it has associated ISRC to received interrupt. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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(). >>>>>>>>=20 >>>>>>>> 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: >>>>>>>>=20 >>>>>>>> "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." >>>>>>>>=20 >>>>>>>> Thus there are no need for any non-standard things in DTS = files. >>>>>>>>=20 >>>>>>>> Svata >>>>>>>>=20 >>>>>>> I took a look through intrng.c and had a couple comments about = the FDT >>>>>>> mapping stuff: >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> I'm attaching new version of intrng.c with change (1) and with = some >>>>>> more little adjustments. >>>>>>=20 >>>>>> Svata >>>>>=20 >>>>> Thanks! How do you plan to support multiple PICs on non-FDT = platforms >>>>> then? >>>>> It looks like it just fails at the moment. >>>>> -Nathan >>>>=20 >>>> There is the following mapping function: >>>> u_int arm_namespace_map_irq(device_t dev, uint8_t type, uint16_t = num); >>>>=20 >>>> 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. >>>>=20 >>>> Svata >>>>=20 >>> So you need the PIC's device_t to allocate an interrupt? That = doesn't seem >>> workable in the real world. What's wrong with just exposing the FDT >>> interface with the phandle_t as an opaque key? You don't do anything = with it >>> except use it as a table lookup key, so it does not in any way = matter what >>> it actually is. >>> -Nathan >>=20 >> Yes, some identification of a PIC is needed always. In FDT case, xref >> is that identification. In not FDT case, I thought that PIC's = device_t >> should be that identification. If you are saying that PIC's device_t >> cannot be used for in some cases, then some else identification must >> be used and associated mapping function too. I already wrote about >> that before. But to be clear, I have no problem with opaque key to >> identify a PIC. I have a problem with how to ensure that the key is >> unique. IMHO, it's not good to mix FDT xref type of a key with = various >> other types of a key and hope that the identification is still >> correct. Some rules have to be definined ar least. >>=20 >> Tell me, how do you think a PIC should be identified with neither >> device_t nor FDT xref? >>=20 >> FYI, I was hoping that FDT xref is a kernel virtual address which is >> unique itself enough. But I was told that FDT xref is more like >> offset. >>=20 >> Svata >>=20 >=20 > Right, it's just a number, though a guaranteed unique one within the = device tree. Usually, a system is going to be 100% FDT based or 100% = non-FDT based, so you don't have to worry about collisions. This is the = case, for example, for ACPI. What we've done on PowerPC is that some = platform logic is responsible for maintaining uniqueness of identifiers = that knows about whatever hardware mapping scheme there is. Andrew can = probably comment on whether a uint32_t will be easy to work with for = ACPI. =E2=80=9Cusually=E2=80=9D? I thought it was always 100%: We=E2=80=99re = wither using FDT or we=E2=80=99re not. Some platforms allow compiling = for both (mostly as a transition aid to FDT), but I=E2=80=99m not aware = of any that would be a mix. Warner