Interrupt handling documentation

Interrupt handling documentation

[Laurent Pinchart]

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

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'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.

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 --]

Re: Interrupt handling documentation

[Michael Ellerman]

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

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.

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

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

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Interrupt handling documentation

[Laurent Pinchart]

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

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.

Thanks for your answer.

Cheers,

-- 
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 --]

Re: Interrupt handling documentation

[Laurent Pinchart]

[-- 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 --]

Re: Interrupt handling documentation

[Benjamin Herrenschmidt]

On Mon, 2008-03-17 at 17:13 +0100, Laurent Pinchart wrote:

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

Yes, exactly. To answer a previous question in the thread, the reason
there are two approaches to cascades is just that:

 - The "easy" approach using setup_irq(). The normal interrupt handling
is done for the cascade, it's masked/acked/whatever-is-needed as any
other interrupt before the second interrupt is fetched. This results
is slightly more kernel stack usage and overhead in getting to the
second interrupt, among other things, but is easier.

 - The "fast" approach using a chained handler. This, as you noticed,
bypass pretty much the whole stack and calls the chain handler directly.
That means that your chain handler is responsible to perform all the
necessary things to ensure the cascade interrupt is properly ack'ed
etc...
 
> 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. 

For an edge cascade, that would do, I suppose. But beware that if you
are only calling ack() and not mask(), then a subsequent chain interrupt
from the same cascade can (and will) potentially happen while you are
calling the handler as the cascade itself has been ack'ed and not
masked. In the case of cpm2, that also probably means you don't need to
call end().

That might be fine though, but it increases the chances of having of
stack overflows caused by interrupts stacking up.

> 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 ?

They can. The chain handling mechanism is an optimisation. It avoids a
spinlock and other bits & pieces which improve performance & latency of
handling cascaded interrupts, at the expense of that added complexity.

Ben.