8
\$\begingroup\$

I'm implementing a PCIe driver, and I'd like to understand at what level the interrupts can be or should be enabled/disabled. I intentionally do not specify OS, as I'm assuming it should be relevant for any platform. By levels I mean the following:

  • OS specific interrupts handling framework
  • Interrupts can be disabled or enabled in the PCI/PCIe configuration space registers, e.g. COMMAND register
  • Interrupts also can be masked at device level, for instance we can configure device not trigger certain interrupts to the host

I understand that whatever interrupt type is being used on PCIe (INTx emulation, MSI or MSI-X), it has to be delivered to the host OS.

So my question is -- do we actually have to enable or disable interrupts on every layer, or it's sufficient only at the closest to hardware, e.g. in relevant PCI registers?

\$\endgroup\$
4
  • 1
    \$\begingroup\$ In Windows KMDF drivers you specify in the driver .inf file what type of interrupts to use (MSI vs INTx vs MSI-x) and the driver framework will correctly configure the PCIe config space itself when it loads. I don't know about other OSes, but as .inf's are Windows specific I think it probably is OS dependent. \$\endgroup\$
    – Tom Carpenter
    Commented Nov 13, 2015 at 16:38
  • 2
    \$\begingroup\$ You generally have to enable them all the way up by providing configuration for what should be done with the interrupt. Once that's done disabling is on the CPU only for brief periods of noninterruptible computing, until you deconfigure the device (eg for power saving) \$\endgroup\$
    – pjc50
    Commented Nov 13, 2015 at 16:39
  • 1
    \$\begingroup\$ IF you are using linux, could you use the DMA framework for your application? It is very nice, you create the transaction, and it returns with an optional timeout when transaction is complete - you don't have to fool with the actual interrupt \$\endgroup\$
    – johnnymopo
    Commented Nov 13, 2015 at 18:21
  • \$\begingroup\$ @pjc50, if a driver selects to use a certain type of interrupts, e.g. INTx, does it have to disable MSI/MSI-X interrupts delivery via MSI_CAP pci registers? (And the other way around -- disable INTx when using MSI) \$\endgroup\$
    – Mark
    Commented Nov 15, 2015 at 6:02

1 Answer 1

Reset to default
2
\$\begingroup\$

Operating systems generally complain loudly about unexpected interrupts, because these are easily detectable programming errors in drivers.

Typically, your hardware would start in some fairly inert state after reset where it waits to be configured. In this state, there is no meaningful way to generate an interrupt, because there is no mapping established yet and you do not know which interrupt.

During configuration, the interrupt mapping comes into existence, and the card is told which interrupt line to use (INTA..INTD as legacy PCI, or MSI/MSI-X), but there is still no driver to handle interrupts yet. Linux has a default handler here that complains to the system log and then disables the interrupt source, as the hardware appears to be faulty (i.e. by default, all interrupts are enabled, but only those where a handler is registered are expected to actually occur).

The driver finally registers interrupt handlers and enables the interrupts it is interested in. If the driver is no longer interested in a specific condition, it needs to disable the interrupt in the device, because that is where the device specific interrupt causes are masked -- the lower layers only know that "something happened".

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.