From: David Gibson <david@gibson.dropbear.id.au>
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: __cli on 4xx - MSR:CE?
Date: Wed, 31 Jul 2002 11:27:28 +1000 [thread overview]
Message-ID: <20020731012728.GF27711@zax> (raw)
In-Reply-To: <3D47395D.8080805@broadon.com>
On Tue, Jul 30, 2002 at 06:11:57PM -0700, David Blythe wrote:
>
> Exactly. I hacked something up (badly) to use the watchdog critical
> interrupt as a low-overhead interrupt for kernel profiling including
> profiling normal interrupt routines. It would take a lot of mucking
> around to support critical interrupts well, but it would be nice support
> to have and should be independent of regular interrupts. When you say
> 2.5 should handle it, are you suggesting someone should make it so or
> asserting that it already does?
I'm asserting that the basic support is already there. It is untested
though, and so probably buggy.
> David Gibson wrote:
> >On Tue, Jul 30, 2002 at 12:30:51PM -0700, akuster wrote:
> >
> >>Hollis Blanchard wrote:
> >>
> >>>Shouldn't __cli on 4xx disable the MSR CE bit as well as EE?
> >>>
> >>>-Hollis
> >>>
> >>It should. Critical interrupts are currently not enabled in the kernel
> >>
> >>armin
> >>
> >
> >No, that isn't clear.
> >
> >As Armin says, (external) critical interrupts are not supported at the
> >moment in the 4xx kernel, so at the moment this is irrelevant.
> >
> >However if someone ever did implement the use of critical external
> >interrupts on a board, this would surely be because interrupts from
> >the relevant hardwware are, well, critical, and require extremely low
> >latency processing. It therefore seems sensible that such routines
> >should run even when normal interrupts are disabled. Obvioulsy the
> >critical interrupt handlers would have to be written very carefully to
> >avoid interfering with interrupted code.
> >
> >If critical interrupts are disabled everywhere that normal interrupts
> >are disabled, there seems little point in having them.
> >
> >I believe the interrupt handling code (head_4xx.S and entry.S) in 2.5
> >should be able to cope with critical external interrupts. When
> >transferring to a critical interrupt handler critical interrupts will
> >remain disabled until the handler has completed.
> >
>
>
>
>
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-07-31 1:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-30 18:46 __cli on 4xx - MSR:CE? Hollis Blanchard
2002-07-30 19:30 ` akuster
2002-07-31 0:52 ` David Gibson
2002-07-31 1:11 ` David Blythe
2002-07-31 1:27 ` David Gibson [this message]
2002-07-31 15:49 ` Hollis Blanchard
2002-08-01 0:14 ` David Gibson
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=20020731012728.GF27711@zax \
--to=david@gibson.dropbear.id.au \
--cc=linuxppc-embedded@lists.linuxppc.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 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.