Linux 设备驱动程序处理多个中断源/向量
我正在编写一个设备驱动程序来处理 PCIe 卡的中断，该驱动程序目前适用于 IRQ 线上引发的任何中断向量。
但它有一些可以引发的类型，由向量寄存器标记。所以现在我需要读取矢量信息并变得更聪明......
那么，我是否：-
1/ 对于每种中断类型都有单独的开发节点 /dev/int1、/dev/int2 等，并且只记录 int1 适用于向量类型 A 等？
1.1/ 由于每个文件/字符设备都有自己的次要编号，因此打开时我会知道哪个是哪个。 我认为。
1.2/ ldd3 似乎演示了这种方法。
2/ 有一个节点 /dev/int （就像我现在一样） 并且有多个进程挂在同一个 read 方法上？ 听起来更好？！
2.1/ 然后只唤醒正确的进程...？
2.2/ 我是否使用单独的wait_queue_head_t wait_queue？或者不同的flag/测试条件？
在 read 方法中：-
wait_event_interruptible(wait_queue, flag);
在处理程序中不是真正的代码！：-
int vector = read_vector();
if vector = A then
wake_up_interruptible(wait_queue, flag)
return IRQ_HANDLED;
else
return IRQ_NONE/IRQ_RETVAL?
编辑：来自人们评论的注释：-
1) 我的用户空间代码 mmap 是所有 PCIe 固件寄存器
2) 用户空间代码有几个线程，每个线程在设备驱动程序设备节点上执行阻塞读取，然后在发生中断时从固件返回数据。我需要根据中断类型唤醒正确的线程。
I am writing a device driver to handle interrupts for a PCIe card, which currently works for any interrupt vector raised on the IRQ line.
But it has a few types that can be raised, flagged by the Vector register. So now I need to read the vector information and be a bit cleverer...
So, do I :-
1/ Have separate dev nodes /dev/int1, /dev/int2, etc for each interrupt type, and just doc that int1 is for vector type A etc?
1.1/ As each file/char-devices will have its own minor number, when opened I'll know which is which. i think.
1.2/ ldd3 seems to demo this method.
2/ Have one node /dev/int (as I do now) and have multiple processes hanging off the same read method? sounds better?!
2.1/ Then only wake the correct process up...?
2.2/ Do I use separate wait_queue_head_t wait_queues? Or different flag/test conditions?
In the read method:-
wait_event_interruptible(wait_queue, flag);
In the handler not real code! :-
int vector = read_vector();
if vector = A then
wake_up_interruptible(wait_queue, flag)
return IRQ_HANDLED;
else
return IRQ_NONE/IRQ_RETVAL?
EDIT: notes from peoples comments :-
1) my user-space code mmap's all of the PCIe firmware registers
2) User-space code has a few threads, each perform a blocking read on the device driver device nodes, which then returns data from the firmware when an interrupt occurs. I need the correct thread woken up depending on the interrupt type.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不确定我是否正确理解了矢量寄存器的含义（指向某些文档的指针将帮助我准确地了解您的情况）。
无论如何，任何 PCI 设备都会获得一个唯一的中断号（由 BIOS 或除 x86 以外的其他架构上的某些固件提供）。您只需在驱动程序中注册此中断即可。
我不太明白的另一件事是为什么要将中断导出为开发节点：中断肯定需要保留在驱动程序/内核代码中。但我想在这里您想要导出一个设备，然后在用户空间中访问该设备。我只是发现 /dev/int no 是一个很好的命名。
对于您关于多个开发节点的问题：如果您的不同中断源提供对不同硬件资源的访问（即使在同一 PCI 板上），我会选择选项 1），每个设备都有一个 wait_queue。否则，我会选择选项 2)
因为您的中断来自同一个物理设备，如果您选择选项 1) 或选项 2)，则必须共享中断线，并且您必须读取 向量在中断处理程序中定义哪个硬件资源引发了中断。
对于选项 1)，它会是这样的：
对于选项 2，它会类似，但在为每个节点请求的每个不同中断处理程序中只有一个 if 子句（针对相应的向量值）。
I am not sure I understand correctly what you mean with the Vector register (a pointer to some documentation would help me precise for your case).
Anyway, any PCI device gets a unique interrupt number (given by the BIOS or some firmware on other architectures than x86). You just need to register this interrupt in your driver.
One other thing that I do not really understand is why you would export your interrupts as a dev node: interrupts are certainly something that need to remain in your driver/kernel code. But I guess here you want to export a device that is then accessed in userspace. I just find /dev/int no to be a good naming.
For your question about multiple dev nodes: if your different interrupt sources then provide access to different hardware resources (even if on the same PCI board) I would go for option 1), with a wait_queue for each device. Otherwise, I would go for option 2)
Since your interrupts are coming from the same physical device, if you chose option 1) or option 2), the interrupt line will have to be shared and you will have to read the vector in your interrupt handler to define which hardware resource raised the interrupt.
For option 1), it would be something like this:
For option 2, it would be similar, but you would have only one if clause (for the respective vector value) in every different interrupt handler that you would request for every node.
如果您有不同的频道可以
read()，那么您一定应该使用不同的次要号码。想象一下，您有一张带有四个串行端口的卡，您肯定需要四个/dev/ttySx。但您的设备适合这个型号吗？
If you have different chanel you can
read()from, then you should definitely use different minor number. Imagine you have a card whith four serial port, you would definitely want four/dev/ttySx.But does your device fit whith this model ?
首先，我假设您并没有尝试将代码放入主线内核中。如果是的话，期待一场关于最佳方法的激烈讨论。如果您正在为一张主要由用户空间的
mmap驱动的卡编写一个简单的中断处理驱动程序，那么有很多方法可以解决这个问题。如果您使用多个设备节点（选项1），您还可以实现
poll，以便单个应用程序可以打开多个设备节点并等待中断的选择。次要编号足以区分它们。如果每个向量都有一个唤醒队列，则只能唤醒相关的侦听器。您需要在成功轮询后锁定向量，以确保读取成功。如果您使用单个设备节点（选项 2），则需要添加一些额外的魔法，以便线程可以注册它们对特定中断向量的兴趣。您可以使用 ioctl 来完成此操作，或者让线程将中断向量
写入到设备。每个线程都应该打开设备节点来获取自己的文件描述符。然后，您可以将请求的向量列表与每个打开的文件描述符相关联。作为奖励，您可以让应用程序从设备读取中断向量，以便它知道发生了哪一个中断。您需要考虑如何清除中断。中断处理程序需要删除中断，然后存储结果，以便将其传递到用户空间。您可能会发现
kfifo对此有用，而不是等待队列。如果每个打开的文件描述符都有一个 fifo，则可以将中断通知分发到每个侦听应用程序。First, I assume you're not trying to get your code into the mainline kernel. If you are, expect a vigorous discussion about the best way to do this. If you're writing a simple interrupt handling driver for a card which is mostly driven by
mmapfrom user-space, there are a lot of ways to solve this problem.If you use multiple device nodes (option 1), you can also implement
pollso that a single application can open multiple device nodes and wait for a selection of interrupts. The minor number will be sufficient to tell them apart. If you have a wake queue for each vector, you can wake only the relevant listeners. You'll need to latch the vector after a successfulpollto be sure that thereadsucceeds.If you use a single device node (option 2), you'll need to add some extra magic so that the threads can register their interest in particular interrupt vectors. You could do this with an ioctl, or have the threads
writethe interrupt vectors to the device. Each thread should open the device node to get its own file descriptor. You can then associate the list of requested vectors with each open file descriptor. As a bonus, you can let the applicationreadthe interrupt vector from the device, so it knows which one happened.You'll need to think about how the interrupt gets cleared. The interrupt handler will need to remove the interrupt, then store the result so it can be passed to user-space. You might find a
kfifouseful for this rather than a wait queue. If you have a fifo for each open file descriptor, you can distribute the interrupt notifications to each listening application.