interrupt framework

[Svatopluk Kraus]

On Fri, Jan 16, 2015 at 5:25 PM, Ian Lepore <ian at freebsd.org> wrote:
> On Fri, 2015-01-16 at 17:08 +0100, Svatopluk Kraus wrote:
>> On Fri, Jan 16, 2015 at 1:03 PM, Andrew Turner <andrew at fubar.geek.nz> wrote:
>> > On Fri, 16 Jan 2015 12:44:22 +0100
>> > Svatopluk Kraus <onwahe at gmail.com> wrote:
>> > ...
>> >> It's just a few things from quick look now which are different in our
>> >> design. However, my intention is not read our code on behalf of you. I
>> >> still think that our design is more general mainly and can serve for
>> >> interrupt controllers better.
>> >
>> > I was asking on the differences as I'm already in the process of
>> > importing the arm_intrng project branch as I need something like it on
>> > arm64. It is also based on the same code from Jakub and Ian, I haven't
>> > looked at changing the design, just cleaning up the code to import into
>> > head.
>> >
>> > I would be happy to merge your code instead, along with my existing
>> > cleanups, however I would need to know why I should spend time on it as
>> > opposed to the current development branch. If we do decide to with your
>> > change I would like to import it into the arm_intrng project branch
>> > first to assist the import into head.
>> >
>> > Andrew
>>
>>
>> Well, this is the main difference in our design:
>>
>> (1) We use one global table for all interrupt sources for framework
>> needs. Each interrupt source is allocated only once and has been
>> assigned to unique interrupt number from the beginning.
>>
>
> While we don't have any existing examples of it, interrupt controllers
> can actually come and go at runtime; they can be associated with hotplug
> hardware.  An example would be something like an i2c-based gpio extender
> that can generate interrupts on its gpio pins.
>
> Does the single global table allow for hotplug things to be added?  Even
> trickier, what about when those things disappear later?  I don't think
> we need to support this right away, I'm just asking if supporting it
> some day will be impossible or not.
>
> -- Ian
>
>


Yes, we keep it in our minds. Michal reminds me of that at least once
a day. ;) However, you know, we are in kernel. Interrupt framework
does not support a removing of an interrupt handler (mean disappearing
of handler code) without disabling of its source. The same way an
interrupt controller cannot be detached without some actions done
before.

Svata