From: Shawn Jin <shawnxjin@gmail.com>
To: Shawn Jin <shawnxjin@gmail.com>, ppcembed <linuxppc-embedded@ozlabs.org>
Subject: Re: Interrupt prioritization on linux for ppc440
Date: Mon, 18 Apr 2005 16:11:02 -0700 [thread overview]
Message-ID: <c3d0340b050418161112b879b5@mail.gmail.com> (raw)
In-Reply-To: <20050418220605.GE25352@gate.ebshome.net>
On 4/18/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Mon, Apr 18, 2005 at 02:14:23PM -0700, Shawn Jin wrote:
> >
> > > What could be interesting, though, is to to make all 4xx IRQs
> > > critical, in this case we could use VR to quickly determine which IRQ
> > > was asserted, instead of current implementation when we use bit
> > > operations. Not sure, if performance gain is really worth the
> > > effort :)
> >
> > If we use VR to determine which IRQ was asserted, it's kind of
> > reverse. We usually fetch a handler by its IRQ number. It could
> > require to change irq_desc[] and request_irq().
>=20
> You seems don't undestand what I'm talking about. VR can help us with
> determining what IRQ was asserted. It has nothing to do with irq_desc.
I guess I understand your statement of using VR to quickly determin
IRQ number. (VR - VCR) >> 9 is the irq number if UIC0_SR0 has the
highest priority, which is quicker than bit searching.
However there could be a possible problem when a 2nd critical
interrupt is asserted before the 1st one is served. Then fetching the
VR returns the address for the 2nd interrupt. Of course if UIC can
queue interrupts when calculating VRs, there wouldn't be such a
problem.
Regards,
-Shawn.
next prev parent reply other threads:[~2005-04-18 23:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-15 21:36 Interrupt prioritization on linux for ppc440 Shawn Jin
2005-04-15 22:12 ` Eugene Surovegin
2005-04-15 23:09 ` Shawn Jin
2005-04-16 0:50 ` Eugene Surovegin
2005-04-18 21:14 ` Shawn Jin
2005-04-18 22:06 ` Eugene Surovegin
2005-04-18 23:11 ` Shawn Jin [this message]
2005-04-19 0:27 ` Eugene Surovegin
2005-04-18 17:01 ` Lawrence E. Bakst
2005-04-18 17:25 ` Eugene Surovegin
2005-04-18 20:54 ` Lawrence E. Bakst
2005-04-18 22:27 ` Eugene Surovegin
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=c3d0340b050418161112b879b5@mail.gmail.com \
--to=shawnxjin@gmail.com \
--cc=linuxppc-embedded@ozlabs.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.