Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Jan 2015 08:44:16 -0800
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        freebsd-arm@freebsd.org
Subject:   Re: interrupt framework
Message-ID:  <54B93FE0.7040403@freebsd.org>
In-Reply-To: <CAFHCsPX5kG_v-F-cjpyMQsT_b386eok=mqWW0%2BEUb_4-_1Otnw@mail.gmail.com>
References:  <CAFHCsPX5kG_v-F-cjpyMQsT_b386eok=mqWW0%2BEUb_4-_1Otnw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I think you missed attaching intrng.c. I'd be interested in taking a 
look at it.
-Nathan

On 01/15/15 05:51, Svatopluk Kraus wrote:
> Hi community,
>
> I and Michal Meloun have done some work on ARM interrupt framework and
> this is the result.
>
> We've started with intrng project with Ian's WIP changes, have looked
> at Andrew's ARM64 git repository, and this is how we think an
> interrupt framework should look like. We've implemented it with
> removable interrupt controllers in mind (PCI world). It's not finished
> from this point of view, however some functions are more complex
> because of it.
>
> It's tested on pandaboard and only GIC is implemented now. There is no
> problem to implement it to other controllers. We are open to questions
> and can finish our work considering any comments. Whoever is waiting
> for ARM interrupt framework as we were, you are welcome to test it.
> Whoever is welcome. The patches are done against FreeBSD-11-current
> revision 277210. There are two new files.
>
> ARM_INTRNG option must be added to board configuration file for new framework.
>
> There are still some things not implemented and some things which
> should be discussed like PPI support. For example, how to enable PPI
> interrupt on other CPUs when they are already running?
>
> We keep in mind that an interrupt framework should be helpfull but
> general enough to not dictate interrupt controlles too much. Thus we
> try to keep some things as much separated as possible. Each interrupt
> is represented by an interrupt source (ISRC) in the framework. An ISRC
> is described by an interrupt number which is much more an unique
> resource handle - totally independent on internal representation of
> interrupts in any interrupt controller.
>
> An interrupt is described by cells in FDT world. The cells can be
> decoded only by associated interrupt controller and as such, they are
> transparent for interrupt framework. The framework provides
> arm_fdt_map_irq() function which maps this transparent cells to an
> interrupt number. It creates an ISRC, saves cells on it, and once when
> associated interrupt controller is registered, it provides the ISRC
> with cells into the controller.
>
> It's a controller responsibility to save an ISRC associated with
> cells. An ISRC is transparent for any controller. However, an
> controller can set/get its data to/from an ISRC. Further, an
> controller should set a name to an ISRC according to internal
> representation of associated interrupt.
>
> An controller interrupt dispatch function can call framework only if
> it has associated ISRC to received interrupt.
>
> For legacy reason, there is arm_namespace_map_irq() function. An
> interrupt is described by namespace type and a number from the
> namespace. It's intented for use with no FDT drivers. Now, it's used
> for mapping an IPI on a controller.
>
> We think that it's better to call chained controllers (with filter
> only) without MI interrupt framework overhead, so we implemented
> shortcut. It could be utilized by INTR_SOLO flag during
> bus_setup_intr().
>
> Only an interrupt controller can really know its position in interrupt
> controller's tree. So root controller must claim itself as a root. In
> FDT world, according to ePAPR approved version 1.1 from 08 April 2011,
> page 30:
>
> "The root of the interrupt tree is determined when traversal of the
> interrupt tree reaches an interrupt controller node without an
> interrupts property and thus no explicit interrupt parent."
>
> Thus there are no need for any non-standard things in DTS files.
>
> Svata
>
>
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54B93FE0.7040403>