On Mon, 16 Feb 2009 08:04:20 +1100
Benjamin Herrenschmidt <b...@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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
