APIC IRQs

APIC IRQs

[Mark Knecht]

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

Re: APIC IRQs

[James Cleverdon]

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

Re: APIC IRQs

[Maciej W. Rozycki]

On Mon, 16 Sep 2002, James Cleverdon wrote:

> 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 

 Vectors start from 0x31.  That's what IRQ 0 gets.  The interval is 8, so
the following vectors are 0x39, 0x41, and so on.

> last PCI interrupt source in the MPS table will be the highest priority.  

 Not necessarily -- after reaching the reserved range, i.e. 0xef, the
allocation wraps around to the previous base plus one.  So for the second
pass vectors start from 0x32, for the third -- 0x33, etc.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +