From: Philippe Gerum <rpm@xenomai.org>
To: Andre Tousch <andre.tousch@domain.hid>
Cc: adeos-main@gna.org
Subject: Re: [Adeos-main] End of interrupt scheduling
Date: Sun, 12 Dec 2004 00:33:08 +0100 [thread overview]
Message-ID: <1102807988.696.87.camel@domain.hid> (raw)
In-Reply-To: <41B974E9.7080801@domain.hid>
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.
prev parent reply other threads:[~2004-12-11 23:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-04 9:28 [Adeos-main] Signalling virtual interrupts to higher priority domains Neugebauer Manfred
2004-10-12 20:59 ` Philippe Gerum
2004-10-19 13:10 ` [Adeos-main] __adeos_handle_event André Tousch
2004-10-19 14:37 ` Philippe Gerum
2004-10-19 14:43 ` Philippe Gerum
2004-12-10 10:05 ` [Adeos-main] End of interrupt scheduling Andre Tousch
2004-12-10 12:36 ` Michael Neuhauser
[not found] ` <41B9A304.6060101@domain.hid>
2004-12-10 13:52 ` Michael Neuhauser
2004-12-11 23:40 ` Philippe Gerum
2004-12-11 23:33 ` Philippe Gerum [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1102807988.696.87.camel@domain.hid \
--to=rpm@xenomai.org \
--cc=adeos-main@gna.org \
--cc=andre.tousch@domain.hid \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.