Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Jan 2015 15:07:57 +0100
From:      Svatopluk Kraus <onwahe@gmail.com>
To:        Ian Lepore <ian@freebsd.org>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: interrupt framework
Message-ID:  <CAFHCsPUP%2BPh9NPh=tcKEkeY1BQ78LxskMxYNpK5rNvecMt-ORA@mail.gmail.com>
In-Reply-To: <1421425502.14601.294.camel@freebsd.org>
References:  <CAFHCsPX5kG_v-F-cjpyMQsT_b386eok=mqWW0%2BEUb_4-_1Otnw@mail.gmail.com> <20150115192624.122066dd@bender.lan> <CAFHCsPW5q=jMsehuYro7V5g56pMXK1tENP-_ibpg0q76LLWxJQ@mail.gmail.com> <20150116120315.7f343f66@bender.lan> <CAFHCsPVn=L=kk%2BKhkUAZY%2BbChhmDC2bHR-X0k7jnacJpABhetQ@mail.gmail.com> <1421425502.14601.294.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 16, 2015 at 5:25 PM, Ian Lepore <ian@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@fubar.geek.nz> wrote:
>> > On Fri, 16 Jan 2015 12:44:22 +0100
>> > Svatopluk Kraus <onwahe@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPUP%2BPh9NPh=tcKEkeY1BQ78LxskMxYNpK5rNvecMt-ORA>