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