public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Parlane <andrewp@carallon.com>
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] interrupts disabled during DSRs on ARM
Date: Fri, 01 Nov 2013 16:30:00 -0000	[thread overview]
Message-ID: <5273D735.8060505@carallon.com> (raw)

Hi,

Another question regarding the ARM interrupt handling code.

When an IRQ occurs we jump to IRQ: in hal\arm\arch\current\src\vectors.s 
we save the previous state, potentially switch stack, take the scheduler 
lock, find the IRQ number, call the ISR, and then call interrupt_end.

interrupt_end() in kernel\current\src\intr\intr.cxx queues up the DSR if 
asked to, and then unlocks the scheduler. As long as the scheduler 
wasn't locked before the IRQ, this causes the scheduler to call any DSRs 
that are queued up. This happens in call_pending_DSRs_inner() in the 
same file. We disable interrupts, get the pointer to the DSR to call, 
restore interrupts and call the DSR.

In the case I've been describing we are still in the IRQ handler, and as 
such the interrupts are disabled throughout the entirety of this, and 
hence disabled in the DSR.

Looking at: http://ecos.sourceware.org/docs-1.3.1/ref/ecos-ref.c.html in 
the first paragraph it states: "This separation explicitly allows for 
the DSRs to be run with interrupts enabled, thus allowing other 
potentially higher priority interrupts to occur and be processed while 
processing a lower priority interrupt."

Am I missing something here?

Any comments would be welcome.
Andrew Parlane
Carallon ltd.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

             reply	other threads:[~2013-11-01 16:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 16:30 Andrew Parlane [this message]
2013-11-01 17:11 ` Nick Garnett
2013-11-01 17:43   ` Andrew Parlane

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=5273D735.8060505@carallon.com \
    --to=andrewp@carallon.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).