interrupt framework

[Svatopluk Kraus]

On Mon, Jan 26, 2015 at 3:46 PM, Julien Grall <julien.grall at linaro.org> 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