Date: Fri, 16 Jan 2015 17:08:54 +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: <CAFHCsPVn=L=kk%2BKhkUAZY%2BbChhmDC2bHR-X0k7jnacJpABhetQ@mail.gmail.com> In-Reply-To: <20150116120315.7f343f66@bender.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. (2) We do not use per controller tables for interrupt sources in framework. It's controller responsibility to keep interrupt sources inside itself according to mapping that is transparent for framework. Further, we assume that a controller can need an internal data for its interrupt sources, so it needs to keep it in some form anyhow. Thus why to have one table for controller's interrupt sources in framework and one table for controller's interrupt sources data in controller. (3) A controller sets names to its interrupt sources. Only controller knows how an interrupt sources should be named. (4) We have three interrupt dispatch function. The need for extra IPI dispatch function I already described in previous email. However, PPI interrupts are quite different of SPI interrupts too. Now, the handling is same but we assume that could change. For example, PPI can be different on each CPU. Anyhow, PPI should be discussed more. (5) We only enable used PPI on other CPUs. (6) We only need to keep track of controllers (except the root one) to have translation from phandle_t to device_t in FDT case. There are more small differencies, different optimalizations and hacks which works, but the main thing is how the interrupt sources are organized. If you deside to give our design a try, we have no problem to arrange it to get general satisfaction. Svata
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPVn=L=kk%2BKhkUAZY%2BbChhmDC2bHR-X0k7jnacJpABhetQ>