From: James Cleverdon <jamesclv@us.ibm.com>
To: "Mark Knecht" <mknecht@controlnet.com>, <linux-kernel@vger.kernel.org>
Subject: Re: APIC IRQs
Date: Mon, 16 Sep 2002 17:17:02 -0700 [thread overview]
Message-ID: <200209161717.02057.jamesclv@us.ibm.com> (raw)
In-Reply-To: <000301c25da9$38b92870$b50aa8c0@mknecht>
On Monday 16 September 2002 10:48 am, Mark Knecht wrote:
> Hi,
> Sorry for the intrusion. I'm working in the Linux audio areas and am
> looking for information on how IRQ priorities are handled when using APIC
> under Linux. Google searches have not yielded much for me. I'm a hardware
> guy, so code stubs are probably not the best answer, but I'm interested in
> most anything on the subject.
>
> Can someone point me towards any non-developer information on this
> subject? HOWTOs, explanations, whatever? Mostly just looking for how to
> best configure audio cards and disk controllers to get the lowest latencies
> in this specific application. I understand the traditional model quite
> well, so even a doc that talked about the differences would be very
> helpful.
>
> Thanks in advance!
>
> With best regards,
> Mark
>
Mark,
The current Linux kernel does not use the Task Priority Register (TPR) to set
interrupt priority levels in the classic Unix splX() fashion. Instead, the
TPR is set to zero at boot and left there for the life of the kernel. (I
have a patch out to change this.)
Linux interrupt routines are expected to be fast and return quickly, so the OS
does do not use the priority hardware or enable interrupts during their
execution. One notable exception is the IDE interrupt handler when operating
in port I/O mode. It will re-enable interrupts while it is servicing an IDE
device.
For APICs, when two interrupts are present when interrupts are enabled, the
one with the highest interrupt vector number will be taken first. Vectors
are statically assigned to the PCI slots, starting at 0x40 or 0x41. So, the
last PCI interrupt source in the MPS table will be the highest priority.
However, I don't think that the MPS table spec specifies any kind of order.
The interrupt source records are sorted however the BIOS wishes. Usually,
they will be sorted by slot number, but that is not guaranteed.
ACPI's ordering is more predictable. The last pin of the last I/O APIC
mentioned in the PCI Routing Table (PRT) will have the highest vector number.
--
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
next prev parent reply other threads:[~2002-09-17 0:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-16 17:48 Mark Knecht
2002-09-17 0:17 ` James Cleverdon [this message]
2002-09-17 11:22 ` Maciej W. Rozycki
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=200209161717.02057.jamesclv@us.ibm.com \
--to=jamesclv@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mknecht@controlnet.com \
/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
all inboxes | Powered by JetHome®