From owner-freebsd-arm@FreeBSD.ORG Mon Jan 26 22:25:23 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 53E61D38 for ; Mon, 26 Jan 2015 22:25:23 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (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 11FBFAB1 for ; Mon, 26 Jan 2015 22:25:23 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id n4so8988204qaq.12 for ; Mon, 26 Jan 2015 14:25:22 -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=7LFyrIWPicnxXPQwyc5AwKxw326qo6G2FspRv0h63QE=; b=Zx6u5WV/xtTUbFBcnnJ8iRmRG4Vwm1iRXvCrZuJZXg2+mNwDzcp4KeOFb9rweoTTtH LvKZEuWMgdfMQvafNxtJg7/Z5OC0NUSDTO0U5sl+ZF3CnymZ0vRIj0/a8MAanTSw29He bkYWpE9g+MqRmE5bU94OyGhCDok2h0vkOksdBqCwDngu7IwsMhmdxoRHT4ztgzK3G6+f X1+yhwsJRIHPuqBQ/tD5fAFbPLqD98446zhTs6oBlAQIHWMI6eyVBbRmoTgz6wY+2hO/ x8+gOI9sgSYjnlzaX6SLIKZlB67o+M4BHLGFprGJVkajibqj6c9WvKNQzjdFd6KWZ0W5 RJbQ== MIME-Version: 1.0 X-Received: by 10.140.109.55 with SMTP id k52mr1402874qgf.99.1422311122327; Mon, 26 Jan 2015 14:25:22 -0800 (PST) Received: by 10.140.82.180 with HTTP; Mon, 26 Jan 2015 14:25:22 -0800 (PST) In-Reply-To: <54C65348.3000302@linaro.org> References: <54B94D71.90403@linaro.org> <54C65348.3000302@linaro.org> Date: Mon, 26 Jan 2015 23:25:22 +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: Mon, 26 Jan 2015 22:25:23 -0000 On Mon, Jan 26, 2015 at 3:46 PM, Julien Grall wrote: > Hi, > > Sorry for the late answer. > > On 17/01/15 15:41, Svatopluk Kraus wrote: >> 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. > > We don't have any FDT description for the event channel (xen interrupt). > The setup is retrieved from the hypervisor in various way. > > So we would need a function to manually setup an interrupt. > >> >> (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. > > The design seems to fit our need in Xen. I will give a try to use this > framework. > >> >> 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. > > In the case we don't have a standard framework, it would still be good > to have a method bus_setupintr. > > The function arm_setup_irqhandler is very similar to intr_add_handler > (x86 one). But as the name is different and few parameters, we have to > produce a stub function. > > Regards, > > -- > Julien Grall I'm in the middle of irq binding (to cpu) implemention and finally realized that some things should be changed a little bit. However, good news for you is that in a way I'm getting closer to x86 intr framework in some aspects. I hope that I will finish it in a day or two. Svata