* OpenPIC / CPM2 PIC and cascading interrupt priorities
@ 2009-02-15 4:50 Guillaume Knispel
2009-02-15 21:04 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 3+ messages in thread
From: Guillaume Knispel @ 2009-02-15 4:50 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
I'm programming a board with an MPC8555E on which an external chip can
raise low priority interrupts through the port C of the CPM2. Under
nominal conditions it generates few interrupts, but they take a
relatively long time to be processed.
I also use some CPM2 controllers in such a way that their interrupts
need to be served with a short latency. At first I thought that this
would not be a problem if IRQF_DISABLED is not set for the port C ISR,
because the CPM2 controller interrupt has a higher priority.
But the thing is: the primary interrupt controller of the MPC8555E is
an OpenPIC and the CPM2 PIC is cascaded behind.
=46rom the behavior I observe and if I understand both Linux code and the
MPC8555E manual correctly, if the CPM2 PIC is idle and then a port C
interrupt arrives on it, it will put its code in SIVEC and send a
signal to the OpenPIC, which will assert the interrupt signal of the
core, then some assembly language magic happens and eventually do_IRQ()
is called with external interrupts masked, which calls *handle_irq
which in this case is cpm2_cascade() which is consistently written in
every platform where it exists as :
static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
{
int cascade_irq;
while ((cascade_irq =3D cpm2_get_irq()) >=3D 0)
generic_handle_irq(cascade_irq);
desc->chip->eoi(irq);
}
cascade_irq will be retrieved thanks to SIVEC and this time the flow
handler will be handle_edge_irq (set in cpm2_set_irq_type() ) which
will ack it (to the CPM2 PIC) and call the ISR (IRQF_DISABLED not set).
Now if the CPM2 controller interrupt occurs while the port C ISR is
running (at a higher CPM2 PIC priority), the CPM2 PIC will tell the
OpenPIC. But the OpenPIC won't interrupt the core again because for the
OpenPIC this is just yet another CPM2 interrupt, the same that the one
being handled, which has not yet been cleared by the ->eio() call at the
end of cpm2_cascade.
So, IRQF_DISABLED or not IRQF_DISABLED, the port C ISR won't be
interrupted by the controller ISR.
Now the big question: does anybody think it could be interesting to
reorganize the Linux irq layers such as the priorities of cascaded
interrupts are respected (that would need some changes in the
architecture independent code), or is this a stupid idea and I should
just use a tasklet?
Cheers,
Guillaume KNISPEL
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: OpenPIC / CPM2 PIC and cascading interrupt priorities
2009-02-15 4:50 OpenPIC / CPM2 PIC and cascading interrupt priorities Guillaume Knispel
@ 2009-02-15 21:04 ` Benjamin Herrenschmidt
2009-02-15 23:32 ` Guillaume Knispel
0 siblings, 1 reply; 3+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-15 21:04 UTC (permalink / raw)
To: Guillaume Knispel; +Cc: Linuxppc-dev
> static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
> {
> int cascade_irq;
>
> while ((cascade_irq = cpm2_get_irq()) >= 0)
> generic_handle_irq(cascade_irq);
>
> desc->chip->eoi(irq);
> }
You can try doing an early EOI see that helps. Ie, stick it inside the loop,
after cpm_2_get_irq() and before generic_handle_irq() and see if that helps,
but make sure you do that EOI only once, ie, only on the first iteration.
Depending on how the CPM2 works, you may also be able to just get rid
of the loop... ie, if CPM2 output is level sensitive.
Ben.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: OpenPIC / CPM2 PIC and cascading interrupt priorities
2009-02-15 21:04 ` Benjamin Herrenschmidt
@ 2009-02-15 23:32 ` Guillaume Knispel
0 siblings, 0 replies; 3+ messages in thread
From: Guillaume Knispel @ 2009-02-15 23:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev
On Mon, 16 Feb 2009 08:04:20 +1100
Benjamin Herrenschmidt <benh@kernel•crashing.org> wrote:
> > static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
> > {
> > int cascade_irq;
> >
> > while ((cascade_irq = cpm2_get_irq()) >= 0)
> > generic_handle_irq(cascade_irq);
> >
> > desc->chip->eoi(irq);
> > }
>
> You can try doing an early EOI see that helps. Ie, stick it inside the loop,
> after cpm_2_get_irq() and before generic_handle_irq() and see if that helps,
> but make sure you do that EOI only once, ie, only on the first iteration.
>
> Depending on how the CPM2 works, you may also be able to just get rid
> of the loop... ie, if CPM2 output is level sensitive.
>
> Ben.
Well the CPM2 -> OpenPIC signal is level sensitive and cpm2_get_irq()
just read SIVEC (register containing the CPM2 interrupt code) with no
side effect so doing an EOI just after cpm2_get_irq() will
unconditionally schedule a new (spurious) interrupt (which is latched
in the OpenPIC) which will reach the core as soon as it
local_irq_enable(), which is just before the ISR is called.
So I think to respect priorities of cascaded interrupts without
generating spurious interrupts, EOI of the master must be called from
within the flow handler of the slave after the slave has been acked,
that's why I wrote "that would need some changes in the architecture
independent code".
And now, after having explicitly written all of the above and thought
about the various possible modes of the master and of the slave and
their combinations (in the general case for Linux, not just for OpenPIC
and CPM2), I'm starting to think that it would be quite complicated and
error prone, so i guess i'll happily use a tasklet :)
Thanks!
Guillaume Knispel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-02-15 23:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-15 4:50 OpenPIC / CPM2 PIC and cascading interrupt priorities Guillaume Knispel
2009-02-15 21:04 ` Benjamin Herrenschmidt
2009-02-15 23:32 ` Guillaume Knispel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox