Setting IRQ's and ACPI

I am still trying to learn what’s going on with newer PC’s and the fact that some BIOS
setup screens
no longer provide a way to specify the IRQ of real-time devices such as a/d converters.
This is very important if one is going to use a standard PC as a realtime platform.
If we cannot set the IRQ so that it is unshared and ahead of things like the EIDE
than we can forget about hard realtime.

I would appreciate any light anyone can shed on this. What I think I know:

1.) Newer PC’s (such as the latest Dell Dimension, Optiplex, XPS) no longer have
a BIOS setup screen to specify the IRQ of PCI cards.

2.) Microsoft wants the OS (W2K and XP) to do the configuring
of IRQ’s using ACPI.

3.) RTP doenst have a way to use ACPI to set IRQ’s. It takes what the BIOS
inits.

And what I dont know:

1.) Is there still an area in an ACPI BIOS equivalent to ESCD where IRQ assignments are
saved across
boots?

2.) Is there any way to write this area so that IRQ’s can be assigned and persist for an
OS that
doesnt use ACPI?

3.) Will RTP have to support ACPI in the future? That is, the BIOS will no longer init
IRQ’s?


Art Hays
avhays@nih.gov

Art Hays wrote:

I am still trying to learn what’s going on with newer PC’s and the fact that some BIOS
setup screens
no longer provide a way to specify the IRQ of real-time devices such as a/d converters.
This is very important if one is going to use a standard PC as a realtime platform.
If we cannot set the IRQ so that it is unshared and ahead of things like the EIDE
than we can forget about hard realtime.

I would appreciate any light anyone can shed on this. What I think I know:

1.) Newer PC’s (such as the latest Dell Dimension, Optiplex, XPS) no longer have
a BIOS setup screen to specify the IRQ of PCI cards.


2.) Microsoft wants the OS (W2K and XP) to do the configuring
of IRQ’s using ACPI.

Microsoft wants newer PCs to use I/O APICs for interrupt routing. The
difference is, you can have hundreds of IRQs, so no need for sharing. It
is important for Windows (or any other large kernel) since all their
internal locks (of which there’s a lot) in the kernel do change IRQL (to
maximize concurrency in the kernel). That operation in case of 8259 PIC
will be out() that goes to southbridge and back, in case of APIC it will
be ‘mov’.

QNX only uses ‘local’ (built-in in the CPU) APICs on SMP hadrware. It
does not support I/O APIC mode. They can get away with it because their
device drivers and more of other stuff are out of kernel so they can
afford locking it completely by one of the CPUs (except for a special
case of message passing operation). However if they did support I/O
APICs they’d benefit too.

3.) RTP doenst have a way to use ACPI to set IRQ’s. It takes what the BIOS
inits.

You don’t have to use ACPI. It makes sense because problems of device
enumeration and resource allocation are common between initial boot and
hot-plug and wakeup from standby, but it is not the only way.

You can assign IRQs using pci_map_irq() but then you have to bring the
whole enchilada, at least for the initial boot scenario.

And what I dont know:

1.) Is there still an area in an ACPI BIOS equivalent to ESCD where IRQ assignments are
saved across
boots?

AFAIK, ACPI is just a spec for interface (i.e., it adds extended BIOS
calls and describes what hardware/software is supposed to do). Whether
ESCD is still there and what BIOS does with it is up to BIOS.

2.) Is there any way to write this area so that IRQ’s can be assigned and persist for an
OS that
doesnt use ACPI?

Maybe. But once you start assigning IRQs yourself, you’re better off not
relying on BIOS for that at all. If you can do it once, you can do it
again on next boot.

3.) Will RTP have to support ACPI in the future? That is, the BIOS will no longer init
IRQ’s?

BIOS will init IRQs as long as BIOS is there, that’s requirement of PCI
BIOS spec. BIOS may go the way of dodo, when stuff like EFI will take
off. When and if that happens, there will be answer to your question but
we don’t know it yet.

Cheers,
– igor

“Igor Kovalenko” <kovalenko@attbi.com> wrote in message news:basn4h$sdi$1@inn.qnx.com

Art Hays wrote:
2.) Is there any way to write this area so that IRQ’s can be assigned and persist for
an
OS that
doesnt use ACPI?

Maybe. But once you start assigning IRQs yourself, you’re better off not
relying on BIOS for that at all. If you can do it once, you can do it
again on next boot.

How would I assign them myself? Suppose the BIOS has assigned the ethernet
and video to IRQ9. I want IRQ9 for my a/d converter. How do I move the ethernet
and video while RTP is running so that the drivers are aware of the change?

And furthermore, suppose the slot I have my a/d converter in has a hardwire shared
interrupt with a USB controller. What happens if I only change the a/d converter IRQ?
Is the BIOS call that sets the IRQ intelligent enough to know to change the USB at the
same time? Then
how does the RTP driver find out?

All of the above is why I was thinking the best solution for RTP is to somehow change
a table in CMOS that would store the last assignments, like the old ESCD.

“Art Hays” <avhays@nih.gov> wrote in message
news:batga3$oum$1@inn.qnx.com

“Igor Kovalenko” <> kovalenko@attbi.com> > wrote in message
news:basn4h$sdi$> 1@inn.qnx.com> …
Art Hays wrote:
2.) Is there any way to write this area so that IRQ’s can be assigned
and persist for
an
OS that
doesnt use ACPI?

Maybe. But once you start assigning IRQs yourself, you’re better off not
relying on BIOS for that at all. If you can do it once, you can do it
again on next boot.



How would I assign them myself?

Using pci_map_irq().

Suppose the BIOS has assigned the ethernet
and video to IRQ9. I want IRQ9 for my a/d converter. How do I move the
ethernet
and video while RTP is running so that the drivers are aware of the
change?

This would be done by PCI management layer, that runs before drivers start.
Linux does this already. QNX also runs pci-bios server before any PCI
drivers load, however it simply assumes that BIOS has assigned resources.
You can extend it (source is part of PE).

The trouble of course is that there’s usually no suitable storage available
at that point where you’d read your IRQ routing table from. I suppose one
way to solve it for QNX would be to have a writable section in the image
filesystem (or one could just make a lame solution with regenerating image
every time that table needs to be changed - if you have mkifs of course).

And furthermore, suppose the slot I have my a/d converter in has a
hardwire shared
interrupt with a USB controller.

That depends on your motherboard design. They can have IRQ routing
‘hardwired’ or programmable. I don’t think that BIOS supports APIC mode, so
it will normally set the routing to slots in the usual ‘interleaved’ way. An
OS can later reassign IRQs as it wishes, either using some sort of ‘hints
table’ from user or by avoiding sharing altogether (if motherboard really
supports APIC mode).

What happens if I only change the a/d converter IRQ?
Is the BIOS call that sets the IRQ intelligent enough to know to change
the USB at the
same time?

Apparently you have to call it for each device on shared IRQ.

Then
how does the RTP driver find out?

I believe you can find out IRQ routing wrt slots using
pci_irq_routing_options().

All of the above is why I was thinking the best solution for RTP is to
somehow change
a table in CMOS that would store the last assignments, like the old ESCD.

I don’t think there’s a hardware-independent way to update ESCD from OS. You
can probably do it for a particular hardware with particular BIOS version,
but if you want a general solution for ‘a generic modern PC’ you probably
need to look for some other solution.

– igor