The AC'97 has an IRQ register which allows for IRQ's 1, and 3 thru 14
(page 107 of the VT82C686 datasheet, under section "Offset 3C, Interrupt Line")
The problem I'm seeing is that on a SMB machine, the IRQ's get reassigned by
the I/O APIC code, and my AC'97 gets assigned an IRQ of 18 (which won't fit into
4 bits :(
Is there any way to reassign an IRQ to one that teh AC'97 will be happy with ?
Does any other device already have to do this ?
thx, and rgds,
-Greg
+---------------------------------------------------------------------+
"DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and
millions of others are by far the most popular, with about 70 million
machines in use wordwide. Macintosh fans, on the other hand, may note that
cockroaches are far more numerous than humans, and that numbers alone do
not denote a higher life form." (New York Times, November 26, 1991)
| Greg Hosler i-net: [email protected] |
+---------------------------------------------------------------------+
On Mon, 30 Apr 2001, Greg Hosler wrote:
> The AC'97 has an IRQ register which allows for IRQ's 1, and 3 thru 14
> (page 107 of the VT82C686 datasheet, under section "Offset 3C, Interrupt Line")
>
> The problem I'm seeing is that on a SMB machine, the IRQ's get reassigned by
> the I/O APIC code, and my AC'97 gets assigned an IRQ of 18 (which won't fit into
> 4 bits :(
>
> Is there any way to reassign an IRQ to one that teh AC'97 will be happy with ?
>
> Does any other device already have to do this ?
>
> thx, and rgds,
>
> -Greg
Observe that the PCI DWORD (long) register at DWORD offset 15 consists
of 4 byte-wide registers (from the PCI specification), Max_lat, Min_Gnt,
Interrupt pin, and interrupt line. Nothing has to fit into 4 bits, you
have 8 bits. I haven't looked at the Linux code, but if it provides only 4
bits for the IRQ, it's broken.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
"Richard B. Johnson" wrote:
> Observe that the PCI DWORD (long) register at DWORD offset 15 consists
> of 4 byte-wide registers (from the PCI specification), Max_lat, Min_Gnt,
> Interrupt pin, and interrupt line. Nothing has to fit into 4 bits, you
> have 8 bits. I haven't looked at the Linux code, but if it provides only 4
> bits for the IRQ, it's broken.
Non-IO-APIC Via audio hardware only decodes the lower 4 bits of the IRQ.
--
Jeff Garzik | Game called on account of naked chick
Building 1024 |
MandrakeSoft |
On Mon, 30 Apr 2001, Jeff Garzik wrote:
> "Richard B. Johnson" wrote:
> > Observe that the PCI DWORD (long) register at DWORD offset 15 consists
> > of 4 byte-wide registers (from the PCI specification), Max_lat, Min_Gnt,
> > Interrupt pin, and interrupt line. Nothing has to fit into 4 bits, you
> > have 8 bits. I haven't looked at the Linux code, but if it provides only 4
> > bits for the IRQ, it's broken.
>
> Non-IO-APIC Via audio hardware only decodes the lower 4 bits of the IRQ.
Woof... More GAWDAUFULL junk. You mean that if I write 0xff to the R/W
interrupt line register and read it back, it's only 0x0f? This didn't
save any money. There are only 4 interrupt 'pins', i.e., interrupt lines
that go to the PCI bus (A thru D). What these lines connect to for
actual IRQs is known only to the motherboard manufacturer hence the
BIOS has to check the pin value and write the appropriate IRQ value
into the interrupt line register. This register is used only as a
scratch-pad so that a driver "knows" what IRQ goes to the board. The
board, itself, never accesses this register. The board only gets one
interrupt connected (A thru D), and to the board, all interrupts are
the same.
So, if the driver can find by some other means, the interrupt that is
connected to the board, it can use that interrupt rather than something
that was written to the scratch register by the BIOS.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
Richard B. Johnson wrote:
> Woof... More GAWDAUFULL junk. You mean that if I write 0xff to the R/W
> interrupt line register and read it back, it's only 0x0f?
Yes, and that disables generation of audio interrupts.
> This didn't
> save any money. There are only 4 interrupt 'pins', i.e., interrupt lines
> that go to the PCI bus (A thru D). What these lines connect to for
> actual IRQs is known only to the motherboard manufacturer hence the
> BIOS has to check the pin value and write the appropriate IRQ value
> into the interrupt line register. This register is used only as a
> scratch-pad so that a driver "knows" what IRQ goes to the board. The
> board, itself, never accesses this register. The board only gets one
> interrupt connected (A thru D), and to the board, all interrupts are
> the same.
I'm currently writing the BIOS for a PowerPC embedded system using the
686B southbridge. On the 686 the 8259 interrupt controller and the
audio system are inside the same physical device. The value you write to
offset 0x3c actually makes the internal connection between the audio
interrupt and the PIC. There is a trick to route that interrupt to an
external APIC involving config register 0x58 in function 0, but I've not
used it.
Most southbridge functions work this way. The USB on the 686B is like
this, and the the IDE controller always generates the legacy IRQ 14/15.
- Adrian Cox