Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Hello,
>
> with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai
> does not distinguish between a normal IRQ enable and an IRQ unmask at
> the end of an ISR (to reenable the IRQ). In the latter case the IRQ
> should be enabled on PowerPC as shown:
>
> if (rthal_irq_descp(irq)->handler->end != NULL)
> rthal_irq_descp(irq)->handler->end(irq);
> else
> rthal_irq_descp(irq)->handler->enable(irq);
>
> To handle this case properly, we need to different functions, I think.
I am not sure I understand what you mean. Would you want functions
rthal_end_irq and xnarch_end_irq added and that this xnarch_end_irq
would be called in xnintr_irq_handler when XN_ISR_ENABLE is set ?
Yes, that's what I have basically done to get the RTnet SCC enet driver
working on my MPC8xx module. In arch/ppc/kernel/irq.c you can see how
Linux re-enables interrupts at the end of it's ISR (see
http://cvs.gna.org/cvsweb/linux/v2.4/2.4.25-ppc/arch/ppc/kernel/irq.c?rev=1.1;cvsroot=adeos):
507: * The ->end() handler has to deal with interrupts which got
508: * disabled while the handler was running.
509: */
510: if (desc->handler) {
511: if (desc->handler->end)
512: desc->handler->end(irq);
513: else if (desc->handler->enable)
514: desc->handler->enable(irq);
In PPC Linux 2.6 things are a bit different. The "end" functions seems
to be mandatory now (I have to check more carefully).
Therefore we need a dedicated function to re-enable interrupts in the
ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more
obvious. On non-PPC archs it would translate to *_irq_enable. I
realized, that *_irq_enable is used in various place/skins and therefore
I have not yet provided a patch.
Wolfgang.
