All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-core] Missing IRQ end function on PowerPC
@ 2006-01-18 10:44 Wolfgang Grandegger
  2006-01-19 12:29 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 16+ messages in thread
From: Wolfgang Grandegger @ 2006-01-18 10:44 UTC (permalink / raw)
  To: xenomai

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.

Wolfgang.



^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [Xenomai-core] Missing IRQ end function on PowerPC
@ 2006-01-30  8:33 Wolfgang Grandegger
  2006-01-30  9:20 ` Jan Kiszka
  0 siblings, 1 reply; 16+ messages in thread
From: Wolfgang Grandegger @ 2006-01-30  8:33 UTC (permalink / raw)
  To: Jan Kiszka, Philippe Gerum, Gilles Chanteperdrix,
	Wolfgang Grandegger, xenomai



> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> 
> Philippe Gerum wrote:
> > 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?
> > 
> 
> Nope, rtdm_irq_enable() was never intended to re-enable an IRQ line
> after an interrupt, and the documentation does not suggest this either.
> I see no problem here.

But RTDM needs a rtdm_irq_end() functions as well in case the
user wants to reenable the interrupt outside the ISR, I think.

Wolfgang.



^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [Xenomai-core] Missing IRQ end function on PowerPC
@ 2006-01-30 11:09 Wolfgang Grandegger
  0 siblings, 0 replies; 16+ messages in thread
From: Wolfgang Grandegger @ 2006-01-30 11:09 UTC (permalink / raw)
  To: Jan Kiszka, Philippe Gerum, xenomai



> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> 
> Philippe Gerum wrote:
> > Jan Kiszka wrote:
> >> Wolfgang Grandegger wrote:
> >>
> >>>> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> >>>>
> >>>> Philippe Gerum wrote:
> >>>>
> >>>>> 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?
> >>>
> >>>> Nope, rtdm_irq_enable() was never intended to re-enable an IRQ line
> >>>> after an interrupt, and the documentation does not suggest this
either.
> >>>> I see no problem here.
> >>>
> >>> But RTDM needs a rtdm_irq_end() functions as well in case the
> >>> user wants to reenable the interrupt outside the ISR, I think.
> >>
> >>
> >> If this is a valid use-case, it should be really straightforward to add
> >> this abstraction to RTDM. We should just document that rtdm_irq_end()
> >> shall not be invoked from IRQ context -
> > 
> > It's the other way around: ->end() would indeed be called from the ISR
> > epilogue, and ->enable() would not.
> 
> I think we are talking about different things: Wolfgang was asking for
> an equivalent of RTDM_IRQ_ENABLE outside the IRQ handler. That's the
> user API. You are now referring to the back-end which had to provide
> some end-mechanism to be used both by the nucleus' ISR epilogue and that
> rtdm_irq_end(), and that mechanism shall be told apart from the IRQ
> enable/disable API. Well, that's at least how I think to have got it...

Yep, I was thinking of deferred interrupt handling in a real-time task.
Then rtdm_irq_end() would be required.
 
> > 
> >  to avoid breaking the chain in
> >> the shared-IRQ scenario. RTDM_IRQ_ENABLE must remain the way to
> >> re-enable the line from the handler.
> >>
> >> Jan
> >>
> >>
> > 
> > 
> 
> Jan
> 
> 
> 

Wolfgang.


^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2006-02-02 12:52 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-18 10:44 [Xenomai-core] Missing IRQ end function on PowerPC Wolfgang Grandegger
2006-01-19 12:29 ` Gilles Chanteperdrix
2006-01-19 13:06   ` Wolfgang Grandegger
2006-01-19 13:27     ` Gilles Chanteperdrix
2006-01-19 13:40       ` Wolfgang Grandegger
2006-01-24 10:20       ` Wolfgang Grandegger
2006-02-02 12:52         ` Philippe Gerum
2006-01-29 22:56       ` Philippe Gerum
2006-01-30  8:16         ` Jan Kiszka
2006-01-30 10:00           ` Philippe Gerum
  -- strict thread matches above, loose matches on Subject: below --
2006-01-30  8:33 Wolfgang Grandegger
2006-01-30  9:20 ` Jan Kiszka
2006-01-30  9:58   ` Philippe Gerum
2006-01-30 10:12     ` Jan Kiszka
2006-01-30 11:13       ` Philippe Gerum
2006-01-30 11:09 Wolfgang Grandegger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.