Date: Sat, 17 Jan 2015 16:41:31 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: Julien Grall <julien.grall@linaro.org> Cc: freebsd-arm@freebsd.org, Roger Pau Monne <roger.pau@citrix.com> Subject: Re: interrupt framework Message-ID: <CAFHCsPXu2aN9Fb=GE0jJcZUyjJ6LJ6oyQMhnMS9V495U3bY%2B9g@mail.gmail.com> In-Reply-To: <54B94D71.90403@linaro.org> References: <CAFHCsPX5kG_v-F-cjpyMQsT_b386eok=mqWW0%2BEUb_4-_1Otnw@mail.gmail.com> <54B94D71.90403@linaro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 16, 2015 at 6:42 PM, Julien Grall <julien.grall@linaro.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPXu2aN9Fb=GE0jJcZUyjJ6LJ6oyQMhnMS9V495U3bY%2B9g>