EmbeddedRelated.com
Forums
Memfault Beyond the Launch

enable/disable PCI interrupts

Started by Mark November 13, 2015
As a course of learning linux device drivers, 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:

a) OS specific interrupts handling framework

b) Interrupts can be disabled or enabled in the PCI/PCIe configuration space 
registers, e.g. COMMAND register

c) 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 really -- 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?


--
Mark



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Hi,

In Linux drivers I need to do enable the PCI device in the 
probe (example:
  http://lxr.free-electrons.com/source/drivers/input/serio/pcips2.c#L135
)
Then, when i want to be able to receive interrupts, I have to register the interrupt handler (request_irq, devm_request_irq or request_threaded_irq).
(example:
 http://lxr.free-electrons.com/source/drivers/input/serio/pcips2.c#L110
)
After that, I can control interrupts using the device resources:
(example:
  http://lxr.free-electrons.com/source/drivers/input/serio/pcips2.c#L113
  http://lxr.free-electrons.com/source/drivers/input/serio/pcips2.c#L124
)
Of course at the end I need to deregister the interrupt handler
(example: http://lxr.free-electrons.com/source/drivers/input/serio/pcips2.c#L126 
)
and disable the device
(example:
 http://lxr.free-electrons.com/source/drivers/input/serio/pcips2.c#L185
)

The above was one of the simplest PCI drivers. You can also analyse more complex examples.

In case of PCIe devices you may need to switch on and off the MSI modes:
(examples:
 http://lxr.free-electrons.com/source/drivers/misc/mic/host/mic_intr.c#L310
 http://lxr.free-electrons.com/source/drivers/misc/mic/host/mic_intr.c#L201
 http://lxr.free-electrons.com/source/drivers/misc/mic/host/mic_intr.c#L598
)

Of course the above is very simplified description.
You can find more information in:
http://lxr.free-electrons.com/source/Documentation/PCI/

particularly in:
http://lxr.free-electrons.com/source/Documentation/PCI/pci.txt
and
http://lxr.free-electrons.com/source/Documentation/PCI/MSI-HOWTO.txt

HTH & Regards,
Wojtek

W dniu piątek, 13 listopada 2015 14:55:55 UTC+1 użytkownik Mark napisał:
> As a course of learning linux device drivers, 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: > > a) OS specific interrupts handling framework > > b) Interrupts can be disabled or enabled in the PCI/PCIe configuration space > registers, e.g. COMMAND register > > c) 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 really -- 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? > > > -- > Mark > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus

Memfault Beyond the Launch