From owner-freebsd-arm@FreeBSD.ORG Mon Jan 26 14:47:09 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 4F15EA87 for ; Mon, 26 Jan 2015 14:47:09 +0000 (UTC) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (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 D8444C86 for ; Mon, 26 Jan 2015 14:47:08 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id p10so9466222wes.6 for ; Mon, 26 Jan 2015 06:47:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=k6xVRQd9ci+3LtlygDACbrB/tP16JPFGLb2os718I6o=; b=RBTc4otyJAWgrjpVcoWTl1/Tj7OX0V4SRzD5OrbzOV1orFp+Ar2q0cyzbuuNGYiCvY dDeln5lDCQHaWHORpz2hypb/rqE2SDxBtAYdB2ORwIAe0RZN14sqt1iCxgXo4BWyZf58 aBnFb+E0DUEBW+Sp+dEksi/3453japEXdbH10MOhycNJgHZ2HS3qvQYFnDi3n8KrhCIC MAvYbu3sZ8gxkceUrbNt3rbv1LHqh0K9o+lxCWTkkW21GskAZ4WopZ9ADNI5trEfyufM 18rfwZh8cHJzN2G9D8qf6cCGejdtBpoLKV7p5yCPdV5rfhgw50NdR++J62yz0csMTvrY hPrg== X-Gm-Message-State: ALoCoQlt3evQIHavGpS2MSboNkre7LC4M7Euzc48ez3ccp7EIYQLdTWlTucXhHGjpVPSg7KF47GT X-Received: by 10.180.210.234 with SMTP id mx10mr32548685wic.37.1422283621338; Mon, 26 Jan 2015 06:47:01 -0800 (PST) Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id mx4sm1324637wic.24.2015.01.26.06.46.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jan 2015 06:47:00 -0800 (PST) Message-ID: <54C65348.3000302@linaro.org> Date: Mon, 26 Jan 2015 14:46:32 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Svatopluk Kraus Subject: Re: interrupt framework References: <54B94D71.90403@linaro.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 14:47:09 -0000 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