[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Question about Interrupt Pin PCI Config. Register.
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: Question about Interrupt Pin PCI Config. Register.
- From: enstone@phx.sectel.mot.com (Mark Enstone)
- Date: Fri, 11 Oct 96 10:29:10 MST
- Resent-Date: Fri, 11 Oct 96 10:29:10 MST
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-Id: <"KjWis.0.qd4.CHeNo"@dart>
- Resent-Sender: pci-sig-request@znyx.com
A question on Interrupt Pin PCI Configuration Register:
I have a PCI-to-PCMCIA bridge chip PCI device.
The Read-only PCI Configuration Register "Interrupt Pin" register
always reads back all 0's (as documented by the devices data sheet).
The PCI Spec. says:
"Devices (or device functions) that do not use an interrupt
pin must put a 0 in this register".
I interpret this to mean that this PCI-to-PCMCIA bridge device is
claiming never to generate/raise an interrupt on the PCI bus.
However, my confusion arises because the PCI bridge chip _does_
generate interrupts (and is supposed to) on my Windows NT Compaq
platforms but NOT on my Windows NT Dell platforms.
Why? What am I missing?
The problems on the Dell platform, made me read more closely the
bridge chips configuration registers description. And now I'm
confused why it even works on the Compaq because I think the
PCI bridge device is telling the BIOS that it does not want an
interrupt (Interrupt Pin register reads back all 0's) and so
the configuration software (BIOS? Other utility) will not
program the controller handler to expect this device to
interrupt or assign it an IRQ.
I've rambled enough. Does anyone have some experience on this
Interrupt Pin register (and related Interrupt Line register)
and what it might mean to various BIOS' if it reads 0's back.
Is my PCI-to-PCMCIA device in error setting the Interrupt Pin to
0's if it does eventually intend to generate interrupts? Should
I raise this with the vendor of that pci device? Or is (my more
likely) my understanding at fault rather than the pci device? :-)
Any information appreciated,
Thanks,
- Mark
+--------------------------------------+--------------------------------------+
| Mark Enstone | e-mail : enstone@phx.sectel.mot.com |
| Motorola, Inc | phone : +1 602 441-3708 |
| Secure Products | fax : +1 602 441-8377 |
| Space and Systems Technology Group | |
| 8220 E.Roosevelt Rd., M.D. R1215 | Mark_Enstone-P27438@email.mot.com |
| Scottsdale, AZ, 85257, USA |** This e-mail Motorola Proprietary **|
+--------------------------------------+--------------------------------------+
r î