Re: [Xenomai-core] Missing IRQ end function on PowerPC

[Philippe Gerum <rpm@xenomai.org>]

Gilles Chanteperdrix wrote:
> Wolfgang Grandegger wrote:
>  > 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.
> 
> The function xnarch_irq_enable seems to be called in only two functions,
> xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set.
> 
> In any case, since I am not sure if this has to be done at the Adeos
> level or in Xenomai, we will wait for Philippe to come back and decide.
> 

->enable() and ->end() all mixed up illustrates a silly x86 bias I once had. We do 
need to differentiate the mere enabling from the IRQ epilogue at PIC level since 
Linux does it - i.e. we don't want to change the semantics here.

I would go for adding xnarch_end_irq -> rthal_irq_end to stick with the Linux 
naming scheme, and have the proper epilogue done from there on a per-arch basis.

Current uses of xnarch_enable_irq() should be reserved to the non-epilogue case, 
like xnintr_enable() i.e. forcibly unmasking the IRQ source at PIC level outside 
of any ISR context for such interrupt (*). XN_ISR_ENABLE would trigger a call to 
xnarch_end_irq, instead of xnarch_enable_irq. I see no reason for this fix to leak 
to the Adeos layer, since the HAL already controls the way interrupts are ended 
actually; it just does it improperly on some platforms.

(*) Jan, does rtdm_irq_enable() have the same meaning, or is it intended to be 
used from the ISR too in order to revalidate the source at PIC level?

-- 

Philippe.