[Adeos-main] Signalling virtual interrupts to higher priority domains

[Adeos-main] Signalling virtual interrupts to higher priority domains

[Neugebauer Manfred]

Hallo,

I'm using the Adeos nanokernel (2.6.8.1-i386-r7c2) within a project to
implement a specific realtime environment embedded within Linux. I
recognized the following problem sending virtual interrupts between Linux
and my realtime domain (having a higher priority):

First I created a virtual interrupt in my realtime domain using
adeos_alloc_irq() and adeos_virtualize_irq_from(). This worked fine. 

My first problem was to signal a virtual interrupt from the Linux domain.
adeos_schedule_irq() and adeos_propagate_irq() seem to start from the
current (or the next) domain to signal the interrupt to one domain down
within the domain chain. Since my receiving domain has a higher priority
than the Linux domain, no interrupts were signalled. I solved this problem
by using the call __adeos_schedule_irq() with (&__adeos_pipeline)->next as
starting point. An idea may be always to use __adoes_pipeline as a start
point when applying adeos_schedule_irq().

The second problem appeared when I looked at the specific timing sequence
between sending and receiving this interrupt. From my point of view it looks
this way that the interrupt is only signaled to the interrupt array in the
higher priority domain, but the domain is not started. This will be done
later, when a different (hardware) interrupt or a software event forces the
higher priority domain to be scheduled. This behavior is not in the way I
expected: I prefered an immediate start of the higher priority domain.

I don't know whether this behavior is planned (or I do something wrong).
Additional information is appreciated.

Manfred.

Re: [Adeos-main] Signalling virtual interrupts to higher priority domains

[Philippe Gerum]

On Mon, 2004-10-04 at 11:28, Neugebauer Manfred wrote:
> Hallo,
> 
> I'm using the Adeos nanokernel (2.6.8.1-i386-r7c2) within a project to
> implement a specific realtime environment embedded within Linux. I
> recognized the following problem sending virtual interrupts between Linux
> and my realtime domain (having a higher priority):
> 
> First I created a virtual interrupt in my realtime domain using
> adeos_alloc_irq() and adeos_virtualize_irq_from(). This worked fine. 
> 
> My first problem was to signal a virtual interrupt from the Linux domain.
> adeos_schedule_irq() and adeos_propagate_irq() seem to start from the
> current (or the next) domain to signal the interrupt to one domain down
> within the domain chain. Since my receiving domain has a higher priority
> than the Linux domain, no interrupts were signalled. I solved this problem
> by using the call __adeos_schedule_irq() with (&__adeos_pipeline)->next as
> starting point. An idea may be always to use __adoes_pipeline as a start
> point when applying adeos_schedule_irq().

> 
> The second problem appeared when I looked at the specific timing sequence
> between sending and receiving this interrupt. From my point of view it looks
> this way that the interrupt is only signaled to the interrupt array in the
> higher priority domain, but the domain is not started. This will be done
> later, when a different (hardware) interrupt or a software event forces the
> higher priority domain to be scheduled. This behavior is not in the way I
> expected: I prefered an immediate start of the higher priority domain.
> 

Use adeos_trigger_irq() to send interrupts to the head of the pipeline.
Linux will be preempted as you wish. propagate/schedule() are only used
to make the IRQ progress down the pipeline as you noticed, possibly
starting at the current stage if you want to log it and have it played
when the next sync occurs, or start with the next stage directly.

> I don't know whether this behavior is planned (or I do something wrong).
> Additional information is appreciated.
> 
> Manfred.
> 
> 
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
-- 

Philippe.

[Adeos-main] __adeos_handle_event

[André Tousch]

Hi,

I'm currently using Adeos 2.4/armnommu to run an RTOS with Linux. 
It works well but I have a problem with events.
I use __adeos_handle_event(ADEOS_USER_EVENT, &event) to send information
from Linux to the RTOS.
Reciprocally, I use adeos_propagate_irq(IRQ_A) to send information from
the RTOS to Linux.
Now I have the following scenario: Linux sends an event to the RTOS,
which replies from the event handler by propagating an IRQ. 

1) Linux does __adeos_handle_event(ADEOS_USER_EVENT). Domain switches to
RTOS
2) RTOS handles the event. It adeos_propagate_irq()'s to Linux.
3) RTOS does adeos_suspend_domain(). Domain switches back to Linux.
4) Linux runs from just after the context switch in
__adeos_handle_event(). No __adeos_sync_stage() is made, and the IRQ_A
handler is not called before next hardware IRQ.

Why is there no call to __adeos_sync_stage() in __adeos_handle_event()? 
Or do I miss something?
Thanks for you support

Regards,
André Tousch

Re: [Adeos-main] __adeos_handle_event

[Philippe Gerum]

On Tue, 2004-10-19 at 15:10, André Tousch wrote:
> Hi,
> 
> I'm currently using Adeos 2.4/armnommu to run an RTOS with Linux. 
> It works well but I have a problem with events.
> I use __adeos_handle_event(ADEOS_USER_EVENT, &event) to send information
> from Linux to the RTOS.
> Reciprocally, I use adeos_propagate_irq(IRQ_A) to send information from
> the RTOS to Linux.
> Now I have the following scenario: Linux sends an event to the RTOS,
> which replies from the event handler by propagating an IRQ. 
> 
> 1) Linux does __adeos_handle_event(ADEOS_USER_EVENT). Domain switches to
> RTOS
> 2) RTOS handles the event. It adeos_propagate_irq()'s to Linux.
> 3) RTOS does adeos_suspend_domain(). Domain switches back to Linux.
> 4) Linux runs from just after the context switch in
> __adeos_handle_event(). No __adeos_sync_stage() is made, and the IRQ_A
> handler is not called before next hardware IRQ.
> 
> Why is there no call to __adeos_sync_stage() in __adeos_handle_event()? 

It's on purpose. Flushing the IRQ log inside the event handling loop has
a dreadful side-effect on 2.6.
2.4 code has converged to the 2.6 implementation here. This said,
running:

__adeos_handle_event()
adeos_unstall_stage()

should work as expected. 

> Or do I miss something?
> Thanks for you support
> 
> Regards,
> André Tousch
> 
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
-- 

Philippe.

Re: [Adeos-main] __adeos_handle_event

[Philippe Gerum]

On Tue, 2004-10-19 at 16:37, Philippe Gerum wrote:
> On Tue, 2004-10-19 at 15:10, André Tousch wrote:
> > Hi,
> > 
> > I'm currently using Adeos 2.4/armnommu to run an RTOS with Linux. 
> > It works well but I have a problem with events.
> > I use __adeos_handle_event(ADEOS_USER_EVENT, &event) to send information
> > from Linux to the RTOS.
> > Reciprocally, I use adeos_propagate_irq(IRQ_A) to send information from
> > the RTOS to Linux.
> > Now I have the following scenario: Linux sends an event to the RTOS,
> > which replies from the event handler by propagating an IRQ. 
> > 
> > 1) Linux does __adeos_handle_event(ADEOS_USER_EVENT). Domain switches to
> > RTOS
> > 2) RTOS handles the event. It adeos_propagate_irq()'s to Linux.
> > 3) RTOS does adeos_suspend_domain(). Domain switches back to Linux.
> > 4) Linux runs from just after the context switch in
> > __adeos_handle_event(). No __adeos_sync_stage() is made, and the IRQ_A
> > handler is not called before next hardware IRQ.
> > 
> > Why is there no call to __adeos_sync_stage() in __adeos_handle_event()? 
> 
> It's on purpose. Flushing the IRQ log inside the event handling loop has
> a dreadful side-effect on 2.6.
> 2.4 code has converged to the 2.6 implementation here. This said,
> running:
> 
> __adeos_handle_event()
> adeos_unstall_stage()
    ^^^^
adeos_unstall_pipeline()

> 
> should work as expected. 
> 
> > Or do I miss something?
> > Thanks for you support
> > 
> > Regards,
> > André Tousch
> > 
> > 
> > _______________________________________________
> > Adeos-main mailing list
> > Adeos-main@domain.hid
> > https://mail.gna.org/listinfo/adeos-main
-- 

Philippe.

[Adeos-main] End of interrupt scheduling

[Andre Tousch]

Hi,

I'm currently using an RTOS with Linux/Adeos on ARM. The original 
behaviour of the RTOS interrupt handler is:

- Lock interrupts
- Call high-level interrupt handler
- Unlock interrupts
- Schedule()

Adeos behaviour on sync_stage is:
- Stall domain
- Call interrupt handler
-  Unstall Domain

If I want to imitate the original RTOS behaviour, I have to schedule 
(RTOS scheduler) at end of interrupt.
I cannot do that in this domain's interrupt handler, since it would 
Schedule() with domain stalled, and thus the domain would not receive 
the interrupts until it gives control back to Adeos by suspending itself.
So the only way I've found to do that was to had a hook in Adeos which 
would be called at sync_stage, just after interrupt handler call.
Thus the modified Adeos behaviour on sync_stage is:

- Stall domain
- Call interrupt handler
-  Unstall Domain
- Call EndOfInterrupt Handler.

Now I have exactly the behaviour expected from my RTOS.

My question is, was there already a way to obtain this behaviour in Adeos?

Best regards,
André

Re: [Adeos-main] End of interrupt scheduling

[Michael Neuhauser]

On Fri, 2004-12-10 at 11:05, Andre Tousch wrote:
> Hi,
> 
> I'm currently using an RTOS with Linux/Adeos on ARM.

What CPU & Kernel are you using? FYI: I'm currently working with an
ARM920T CPU on Linux 2.4.21-rmk1-crus1.4.2 and found some issues - if
this is relevant for you: I will post about it here soon.

> [...]
>
> If I want to imitate the original RTOS behaviour, I have to schedule 
> (RTOS scheduler) at end of interrupt.
> I cannot do that in this domain's interrupt handler, since it would 
> Schedule() with domain stalled, and thus the domain would not receive 
> the interrupts until it gives control back to Adeos by suspending itself.
>
>[...]
>
> My question is, was there already a way to obtain this behaviour in Adeos?

Maybe I'm overlooking something, but why don't you unstall the pipeline
in your interrupt handler? You don't have to wait for
__adeos_sync_stage() to unstall it. Outline of interrupt handler:

	do_irq_work();
	adeos_unstall_pipeline();
	rtos_schedule();

Of course you need to have registered a high priority domain in which
the irq handler runs (irqs are hard disabled when entering a root domain
irq-handler).

Mike
-- 
Dr. Michael Neuhauser                phone: +43 1 789 08 49 - 30
Firmix Software GmbH                   fax: +43 1 789 08 49 - 55
Vienna/Austria/Europe                      email: mike@domain.hid
Embedded Linux Development and Services    http://www.firmix.at/

Re: [Adeos-main] End of interrupt scheduling

[Michael Neuhauser]

On Fri, 2004-12-10 at 14:22, Andre Tousch wrote:
> Hi,
> thanks for your reply.

I hope you don't mind when we continue this on the mailing list, other
people might also be interested in it or have something to say on these
matters.

> [...]
> 
> >Maybe I'm overlooking something, but why don't you unstall the pipeline
> >in your interrupt handler? 
>
> Adeos stalls the domain before calling its interrupt handler, and 
> unstalls the domain after the handler returns.
> This prevents reentrance on the interrupt handler.
> If I unstall the pipeline, I make the handler reentrant, while Adeos 
> assumes it is not.

As far as I know, Adeos does not make such an assumption. Take for
instance the Linux timer interrupt. It has SA_INTERRUPT set, therefore
arch/arm/kernel/irq.c:__do_irq() enables interrupts with
local_irq_enable() before calling the real handler. With Adeos this
translates to a pipe unstall inside an irq-handler. This allows *other*
interrupts to occur while the timer irq handler is running. Another
timer interrupt can't happen while the old one is handled: the timer-irq
will be unmasked *after* the handler has finished (see 
arch/arm/kernel/irq.c:do_IRQ()).

Mike
-- 
Dr. Michael Neuhauser                phone: +43 1 789 08 49 - 30
Firmix Software GmbH                   fax: +43 1 789 08 49 - 55
Vienna/Austria/Europe                      email: mike@domain.hid
Embedded Linux Development and Services    http://www.firmix.at/

Re: [Adeos-main] End of interrupt scheduling

[Philippe Gerum]

On Fri, 2004-12-10 at 13:36, Michael Neuhauser wrote:
> On Fri, 2004-12-10 at 11:05, Andre Tousch wrote:
> > Hi,
> > 
> > I'm currently using an RTOS with Linux/Adeos on ARM.
> 
> What CPU & Kernel are you using? FYI: I'm currently working with an
> ARM920T CPU on Linux 2.4.21-rmk1-crus1.4.2 and found some issues - if
> this is relevant for you: I will post about it here soon.

If you want those fixes to become part of the standard Adeos patch for
ARM, please send them. This is the only way for such support to improve.

> 
> > [...]
> >
> > If I want to imitate the original RTOS behaviour, I have to schedule 
> > (RTOS scheduler) at end of interrupt.
> > I cannot do that in this domain's interrupt handler, since it would 
> > Schedule() with domain stalled, and thus the domain would not receive 
> > the interrupts until it gives control back to Adeos by suspending itself.
> >
> >[...]
> >
> > My question is, was there already a way to obtain this behaviour in Adeos?
> 
> Maybe I'm overlooking something, but why don't you unstall the pipeline
> in your interrupt handler? You don't have to wait for
> __adeos_sync_stage() to unstall it. Outline of interrupt handler:
> 
> 	do_irq_work();
> 	adeos_unstall_pipeline();
> 	rtos_schedule();
> 
> Of course you need to have registered a high priority domain in which
> the irq handler runs (irqs are hard disabled when entering a root domain
> irq-handler).
> 
> Mike
-- 

Philippe.

Re: [Adeos-main] End of interrupt scheduling

[Philippe Gerum]

On Fri, 2004-12-10 at 11:05, Andre Tousch wrote:
> Hi,
> 
> I'm currently using an RTOS with Linux/Adeos on ARM. The original 
> behaviour of the RTOS interrupt handler is:
> 
> - Lock interrupts
> - Call high-level interrupt handler
> - Unlock interrupts
> - Schedule()
> 
> Adeos behaviour on sync_stage is:
> - Stall domain
> - Call interrupt handler
> -  Unstall Domain
> 
> If I want to imitate the original RTOS behaviour, I have to schedule 
> (RTOS scheduler) at end of interrupt.
> I cannot do that in this domain's interrupt handler, since it would 
> Schedule() with domain stalled, and thus the domain would not receive 
> the interrupts until it gives control back to Adeos by suspending itself.
> So the only way I've found to do that was to had a hook in Adeos which 
> would be called at sync_stage, just after interrupt handler call.
> Thus the modified Adeos behaviour on sync_stage is:
> 
> - Stall domain
> - Call interrupt handler
> -  Unstall Domain
> - Call EndOfInterrupt Handler.
> 
> Now I have exactly the behaviour expected from my RTOS.
> 
> My question is, was there already a way to obtain this behaviour in Adeos?
> 

In short, the answer is: you don't need to put any hooks.

Your rtos_schedule() routine is expected to reinstate the interrupt mask
of the resumed thread, after having saved it on entry as it was
scheduled out, thus overriding the current setting inherited by your
interrupt handler. Unless your thread called rtos_schedule() with
interrupts off, the resumption will thus unstall your domain's stage as
a side-effect. Even in the former case (i.e. called with interrupts
off), the resuming thread is expected to unstall the pipeline at some
point in time, or at the very least schedule out asap if it happens to
always run interrupts off.

i.e.

void rtos_schedule (void)

{
    unsigned long flags;

   /* Entering with interrupts on */
   flags = adeos_test_and_stall_pipeline_from(&your_rt_domain);

   /* Now running interrupt-free for performing critical stuff involved
       by switching contexts */
   ... pick next thread and switch context...

 adeos_restore_pipeline_from(&your_rt_domain,flags);
  /* Exiting with interrupts on */
}

If rtos_schedule() leads to a no-op because no thread switch has taken
place, then your IRQ handler will return to __adeos_sync_stage() which
will in turn unlock the stage.

You can find a complete illustration of this in the RTAI implementation
btw.

> Best regards,
> André
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
-- 

Philippe.