public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jlarmour@redhat.com>
To: Sandeep Rikhi <sr@cdotb.ernet.in>
Cc: "eCos Discussion Gp." <ecos-discuss@sourceware.cygnus.com>
Subject: Re: [ECOS] Nested Interrupts.
Date: Mon, 11 Sep 2000 07:53:00 -0000	[thread overview]
Message-ID: <39BCF202.89E5D376@redhat.com> (raw)
In-Reply-To: <Pine.OSF.4.21.0009111224581.28099-100000@ws9.cdotb.ernet.in>

Sandeep Rikhi wrote:
> 
>  In case an interrupt has occured and we are in the ISR part of it.
> Suppose at the same time a high priority interrupt ( say a
> reset) occurs... what would be the situation then? Do we leave the current
> ISR and switch over to new interrupt ( high priority ). If it is so, what
> was the effect of disabling the interrupts?

Interrupts are completely disabled while ISRs are running. ISRs are meant
to be very short with any substantial work deferred to a DSR, or better
still by the DSR then waking a thread. Typically, if more work is being
done in a DSR, then the ISR will mask the interrupt. This then allows other
interrupts to be processed.

With many systems, masking the interrupt will actually mask that interrupt
*and* all lower priority ones, so that you only receive higher priority
ones (until the interrupt is unmasked in the DSR). It depends on the
interrupt controller being used, although you could also write
HAL_INTERRUPT_MASK() for your particular platform to do this "manually" -
this isn't done by default, as this requires tracking what interrupts are
available in the system and their priority.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

  reply	other threads:[~2000-09-11  7:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-11  0:03 Sandeep Rikhi
2000-09-11  7:53 ` Jonathan Larmour [this message]
2001-01-17 23:51 [ECOS] nested interrupts Xavier Wang
2001-01-18  1:03 ` Jesper Skov
2001-01-18  4:15   ` Xavier Wang
2001-01-18  5:00     ` Nick Garnett
2001-01-18  4:59   ` Xavier Wang
2001-01-18  5:46     ` Nick Garnett
2001-01-18 21:52       ` Xavier Wang
2001-01-18 22:35         ` Jonathan Larmour
2001-01-18  8:26   ` Sergei Slobodov
2001-01-18 20:56     ` Xavier Wang
2001-01-18 22:37       ` Jonathan Larmour

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=39BCF202.89E5D376@redhat.com \
    --to=jlarmour@redhat.com \
    --cc=ecos-discuss@sourceware.cygnus.com \
    --cc=sr@cdotb.ernet.in \
    /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).