Re: Interrupt handling and routing: The Big Picture

[Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost>]

On Sat, 10 Mar 2012 23:37:02 +0000 (UTC)
Eduardo Horvath <eeh%NetBSD.org@localhost> wrote:

> IEEE 1275 interrupts mappings.
Thats not my problem. I already know imap0_9d.html. There is a much
better explanation on: http://devicetree.org/Device_Tree_Usage
I mostly worked that out. The only missing part is the decoding of the
"interrupts" properties as the Efika uses three cells for this.

My problem is: Where and how to hook up what code to deal with the
special PIC of the MPC5200.

1st Problem: How to get an interrupt to the handler of the device?

Up to now I discovered arch/powerpc/pic/intr.c:pic_do_pending_int().
It seems this gets called when a CPU gets a interrupt. This function
somehow extracts a "virq" (interrupt vector?) by means of some bit
operations. "imask" seems to be a bit mask that is used to mask out
some interrupts at the current interrupt priority level as in spl(9).

The resulting "virq" vector is used as index to "intrsources". This
seems to be an array with one element per interrupt vector in the
system. intr_deliver() then calls the actual interrupt handlers
assigned to that vector.

OK. Seems I don't need to fight with this.

2nd Problem: How to hook up the special MPC5200 PIC to the generic
interrupt handling stuff of the kernel.

The fun starts with intr_establish(). It walks "struct pic_ops
*pics[MAX_PICS]" by means of find_pic_by_hwirq(). So I have to fill a
"struct pic_ops" somewhere in my code and feed it to pic_add()?
How to deal with "hwirq"? (Hard Ware IRQ?) It seems each PIC gets a
range of hwirqs by means of "pic_intrbase" and "pic_numintrs". So each
possible interrupt in the system has its own "hwirq" number? Later this
hwirq can be used to determine the PIC that controles this IRQ. 

3rd Problem: How to hookup to autoconf(9).

In addition I have to provide something like "efika_intr_map()". It maps
the OFW interrupt properties as given by the device attach arguments to
a "hwirq" to feed this in turn to intr_establish()? This should be
enough to get the on chip peripherals running.

The PCI code has generic functions for this. (genofw_pci_intr_map()
genofw_setup_pciintr_map()) I still have no clue about how to shove
"efika_intr_map()" in there. As PCI is optional, I'll don't care about
this at the moment.


So the interrupt mapping / routing has two stages:
- Mapping the OFW properties to a hwirq: "efika_intr_map()"
- Mapping a hwirq to the actual PIC: find_pic_by_hwirq()
To make the later work I have to pic_add() a set of "struct pic_ops".
These in turn contain function pointers to the actual support code of
the PIC.

pic_add() has to be called by a new to write "mpc5200_intr_init()" and
this in turn by the existing init_ofppc_interrupt() in ofppc/mainbus.c.

Did I get this right? Anything that I missed?

Thanks for your attention.
-- 


\end{Jochen}

\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}