Date: Fri, 16 Jan 2015 12:44:22 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: Andrew Turner <andrew@fubar.geek.nz> Cc: freebsd-arm@freebsd.org Subject: Re: interrupt framework Message-ID: <CAFHCsPW5q=jMsehuYro7V5g56pMXK1tENP-_ibpg0q76LLWxJQ@mail.gmail.com> In-Reply-To: <20150115192624.122066dd@bender.lan> References: <CAFHCsPX5kG_v-F-cjpyMQsT_b386eok=mqWW0%2BEUb_4-_1Otnw@mail.gmail.com> <20150115192624.122066dd@bender.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 15, 2015 at 8:26 PM, Andrew Turner <andrew@fubar.geek.nz> wrote: > On Thu, 15 Jan 2015 14:51:17 +0100 > Svatopluk Kraus <onwahe@gmail.com> wrote: > >> Hi community, >> >> I and Michal Meloun have done some work on ARM interrupt framework and >> this is the result. > > I haven't ad a chance to look though it yet, but how does this compare > with what is currently on the arm_intrng branch? I've also taken Ian's > WIP change and cleaned it up so it will build with the current > interrupt framework. I've also been working on allowing the simplebus > changes to work on architectures that aren't arm. > > I'm planning on importing the branch into head soon, after fixing the > last few cross-arch issues, to allow for wider testing. > > Andrew I looked at arm_intrng project this morning and more concrete remarks are here about difference between that and our design. (1) I do not think that nexus as root interrupt controller is good abstraction. All nexus PIC methods are empty. But mainly, an interrupt framework should be responsible of dispatching interrupts on first (root) level. Not nexus. In case of vector interrupts, again, it should be coded in framework not in nexus. And framework has no usage from knowing that nexus is root interrupt controller device. Thus in our design, nexus is not root interrupt controller. (2) Only root controller can do IPIs. In your design, nexus is root controller, so real root controller must claim that can do IPIs. (2) Unmasking IPI in init_secondary is useless as that is done in release_aps(). (3) In our design, we use separated IPI handlers as each of them needs different handling. See for example comments in smp_rendezvous_action(). (4) Using of critical_section() is not allowed for some IPIs. So using intr_event_handle() for IPIs is not wanted certainly in you design. (4) We do not use pic_ipi_read(). It's controller responsibility to serve IPIs interrupt, even if there could come more IPIs on one interrupt. (5) On GIC, EOI cannot be done in post_filter method as according to manual the register value used for EIO must correspond to most recent read value from active interrupt register. For example, in our design there is a possibility to save read value to ISRC and use it in post_filter method. However, we do not do that in GIC now. 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. Svata
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPW5q=jMsehuYro7V5g56pMXK1tENP-_ibpg0q76LLWxJQ>