Interrupt handling documentation
laurentp at cse-semaphore.com
Tue Mar 18 03:13:48 EST 2008
On Thursday 13 March 2008 14:56, Laurent Pinchart wrote:
> Hi Michael,
> On Wednesday 12 March 2008 01:51, Michael Ellerman wrote:
> > On Tue, 2008-03-11 at 11:58 +0100, Laurent Pinchart wrote:
> > > Hi everybody,
> > >
> > > is there any documentation describing interrupt handling for the
> > > powerpc architecture ? I'm writing a driver for a cascaded interrupt
> > > controller and the only source of information I found was the code.
> > I don't think there's much documentation.
> I feared so :-)
> > You might want to look at arch/powerpc/platforms/cell/axon_msi.c, it's a
> > reasonably simple example of how to setup an irq_host and so on - well I
> > think so :D
> Thanks for the pointer.
> > > I'm particularly interested in information about irq hosts (allocation
> > > and initialisation, especially the map and unmap callbacks) and irq
> > > chaining. Different drivers seem to implement cascaded irqs differently
> > > (for instance arch/powerpc/sysdev/uic.c uses setup_irq to register the
> > > cascaded irq handler, while
> > > arch/powerpc/platforms/82xx/pq2ads-pci-pic.c uses
> > > set_irq_chained_handler) so I'm a bit lost here.
> > uic.c uses set_irq_chained_handler() now, so that probably answers that
> > question. I don't think it makes all that much difference if you set it
> > up by hand, but set_irq_chained_handler() is the neat way to do it.
> That pretty much answers my question. It's always a bit disturbing when
> different drivers use different APIs to accomplish the same task,
> especially when the lack of documentation doesn't clearly state which API
> should be used and which API is internal/deprecated.
I've been struggling with spurious interrupts related to my irq host for a
day. Now that I've been able to solve the problem I thought I'd share the
The PIC I am working with is linked to a falling-edge external irq on the
CPM2. When the first PIC interrupt was generated the kernel called the PIC
chained irq handler endlessly.
After some investigation it turned out the external interrupt bit in the CPM2
interrupt pending register never got cleared. set_irq_chained_handler()
registers the chained irq handler at the lowest level in the irq stack,
bypassing all the interrupt acknowledgement/masking logic.
The fix was easy, all I had to do was to call desc->chip->ack(irq) at the
beginning on the chained irq handler and desc->chip->eoi(irq) at the end.
However, I'm wondering if this really belongs in the PIC code, or if PICs
shouldn't be registered at a higher level (setup_irq or even request_irq) so
that they would reuse the handle_*_irq handlers. Any opinion on this ?
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
T +32 (2) 387 42 59
F +32 (2) 387 42 75
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Linuxppc-dev