Re: Interrupt handling and routing: The Big Picture

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Sat, 10 Mar 2012, Jochen Kunz wrote:

> Hi.
> 
> Finally I stated to hack port-ofppc to support my Efika.
> The Efika is a SBC based on the Freescale MPC5200 SOC with OpenFirmWare:
> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5200B
> http://www.efika.de/index_en.html
> 
> I have some prior experience in device driver hacking. I created a bus
> attachment with its own bus_space(9) for the on chip bus. I can attach
> ohci(4) to the build in USB host controller. There is still a strange
> timeout in ohci_init() that I try to analize, but things look promising
> for now.
> 
> Interrupts are next on the plan. The MPC5200 has its own, special
> interrupt controller that is not compatible to any other interrupt
> controller like OpenPIC. So everything in that area has to be coded new
> from the ground up.
> 
> I tried to reverse engineer the existing code.
> (arch/ofppc/ofppc/mainbus.c:init_ofppc_interrupt(),
> arch/powerpc/pci/pci_machdep_ofw.c:genofw_find_ofpics(), stuff in
> arch/powerpc/pic/) But I am lost. I simply don't get The Big Picture
> about how all this works and how different parts of the kernel
> interact. (Is genofw_find_ofpics() only usable on PCI busses? Seems not
> to me but it is located in pci_machdep_ofw.c) It would be a big help
> for me if a PPC guru would explain the general concepts of interrupt
> handling and routing in the NetBSD kernel in genral and in particular
> for PPC ports. A rough guide about how to work on this and a roadmap
> would be much appreciated.

IEEE 1275 interrupts mappings.  This is the part that's most often 
incorrect.

Take a look at the OpenFirmware home page.  There's a recommended 
practices document that describes how to do all the interrupt mapping:

http://www.openfirmware.org/ofwg/practice/imap/imap0_9d.html

It's too complicated to summarize, but you start with the "interrupts" 
property of the device you want to map and walk the tree applying the 
algorithm described there.  When you're done you should end up with a 
device node that implements the interrupt controller hardware, and a 
translated interrupt number that makes sense to that hardware.  The rest 
is hardware dependent magic.

Eduardo