Re: Interrupt handling documentation

[Laurent Pinchart <laurentp@cse-semaphore.com>]

[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]

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 
results here.

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 ?

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]