From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 15:41:32 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 9F5AA1C9 for ; Sat, 17 Jan 2015 15:41:32 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (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 59B537C3 for ; Sat, 17 Jan 2015 15:41:32 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id bm13so19191943qab.0 for ; Sat, 17 Jan 2015 07:41:31 -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=yTKa2UXolt2fPHlPr55VLfAbna8hMvloaaxfNhtUQcY=; b=ZAE+qBMaJEZYNf4T3UVAhmxcp9IYOoObx8hxC9SJEQWvGFZXSM4WaPXms+OEDkYgcX zTagfZMLyY7htr8ezEO097KQ66mzqH7iscsMLplU8NQR/GUXe3coTJIwNjFLjBtEPqNV GELQiSfKDZKqUDMV16RiR8BASb9ewr07oI+/PJTVTluCWBC3faErBI5pxHSw8ZaxspiU yFWqAh9wyZT/I7PKPguNEs0bWo1VTSZ9WNnrimeO7uK/AcHETsSbDi2/gaFauqXwql0E Hcax+ROqO6HkxhCsiPovyDNuEgdF4UX9N0HUGmn8t6xQFBJbNIEiXEkKmVPU/BCKd4Ki ELDA== MIME-Version: 1.0 X-Received: by 10.224.95.71 with SMTP id c7mr10372976qan.70.1421509291535; Sat, 17 Jan 2015 07:41:31 -0800 (PST) Received: by 10.140.82.180 with HTTP; Sat, 17 Jan 2015 07:41:31 -0800 (PST) In-Reply-To: <54B94D71.90403@linaro.org> References: <54B94D71.90403@linaro.org> Date: Sat, 17 Jan 2015 16:41:31 +0100 Message-ID: Subject: Re: interrupt framework From: Svatopluk Kraus To: Julien Grall Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org, Roger Pau Monne 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: Sat, 17 Jan 2015 15:41:32 -0000 On Fri, Jan 16, 2015 at 6:42 PM, Julien Grall wrote: > On 15/01/15 13:51, Svatopluk Kraus wrote: >> Hi community, > > Hello, > >> 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. > > Is there any plan to make this framework generic across all the > architectures? > > Some of our drivers as to create new interrupt controllers to handle > event channel, it's an event notifications provided by Xen which is very > similar to an interrupt (eoi/mask/unmask...). They are used by virtual > devices in order to send/receive interrupts. > > The current code [1] already supports x86 which has a similar > framework [2]. > > If your framework is used on all the architecture (especially ARM, ARM64 > and x86), it would allow us to share the code between the architectures > supported by Xen. > > Regards, > > [1] sys/x86/xen/xen_intr.c > [2] sys/x86/x86/intr_machdep.c > > -- > Julien Grall Yes, I forgot to get a credit to sys/x86/x86/intr_machdep.c as this is what we know for a long time. It's inspired us certainly. Thus our designs are very close from some points of view. And we have no problem to make some common interrupt framework across more architectures. However, if we will push too hard, the result could become too complex. And that is not our aim. We like simple frameworks if it's possible. Anyhow, it's not only about us. I do not know XEN architecture, so maybe I describe ARM architecture needs and you would tell me if there is a way for common framework. In ARM, interrupt tree is not same as bus (memory) tree. In other words, when you will go down a tree to its root thru standard bus methods because of looking for your interrupt controller, you likely will not find it. Thus there must be some other method how to describe where your controller is. In current, FTD is used for that. However, when FDT data is read, any interrupt controller does not have to be attached. Thus interrupt sources and their numbers are allocated in the order how are coded in FDT. (1) An interrupt source is allocated before its controller is attached in general. Thus an interrupt number (vector) must be allocated by framework itself and so must be its interrupt source. This interrupt number is more like resource handle and has nothing to do with a way how an interrupt source is represented in hardware. (2) As an interrupt number is transparent for a controller, a mapping function must exist for each type of interrupt description. On the other hand, considering identical points of our designs: (1) an interrupt source as a transparent framework description of an interrupt is common, (2) keeping interrupt sources in one global table is common, (3) using an interrupt source as an argument in controllers methods is common, (4) most controllers methods are common, however we use KOBJ methods instead of table of functions, (5) MI interrupt framework (kern_intr.c) using is common. Is it enough for some kind of common framework? I can imagine that standard bus methods like bus_setupintr() could be same to some extent, mapping functions could be same, controller's managing functions could be same, hmm, it looks that quite a lot of things could be same. However, it could just look like that on first look now. Svata