From: Shawn Jin <shawnxjin@gmail.com>
To: ppcembed <linuxppc-embedded@ozlabs.org>
Subject: Re: Interrupt prioritization on linux for ppc440
Date: Mon, 18 Apr 2005 14:14:23 -0700 [thread overview]
Message-ID: <c3d0340b05041814144133a608@mail.gmail.com> (raw)
In-Reply-To: <20050416005026.GB1086@gate.ebshome.net>
On 4/15/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> I really think that if you need some special higher-priority IRQ
> context you'd better use RTAI or RTLinux. At least, they make clear
> (IIRC) that these IRQ contexts are special.
OK, I'll look into RTAI or RTLinux for priority issue.
> 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().
VR can be calculated automatically provided that VCR is set. What
should be the vector base address? One possible way is similar to the
way how IVPR is set to interrupt_base in head_44x.S but leave the
actual interrupt handler blank, which will be filled in later with a
jump instruction which jumps to the actual ISR once a device driver
request its irq. This means that request_irq() needs to modify kernel
code. Kinda of dangerous, isn't it? This might be part of
infrastructure change you mentioned?
Regards,
-Shawn.
next prev parent reply other threads:[~2005-04-18 21:14 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 [this message]
2005-04-18 22:06 ` Eugene Surovegin
2005-04-18 23:11 ` Shawn Jin
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=c3d0340b05041814144133a608@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.