request_irq fails because there is no irq descriptor - linux-device-driver

Question

I have a Linux system which I'm connecting to custom hardware. (To be specific, this is an SoC with an FPGA).
I am trying to write a kernel module that will respond to interrupts from my device. It contains a call to request_irq, but this is done via a call to uio_register_device. When I run insmod, it fails with "Invalid parameters".
After poking around the code for a while, I eventually added these lines in my module init function:
struct irq_desc *p;
p = irq_to_desc(89);
if (!p) {
printk(KERN_ALERT "No descriptor allocated for IRQ number 89!!\n");
}
p = irq_to_desc(121);
if (!p) {
printk(KERN_ALERT "No descriptor allocated for IRQ number 121!!\n");
}
Sure enough, I see these messages in dmesg.
What am I supposed to do in this case?

Answer 1

I managed to figure it out. For interrupts to work properly, you need to map a virtual IRQ number (i.e. the number you would use in request_interrupt) to a hardware IRQ number. Of course, hardware IRQ numbers are not unique; for example, two interrupt controllers could have a hardware IRQ number of 0. So what I really mean is that you have to associate the virtual IRQ number with the combination of an irq_domain and a hardware IRQ number.
There's a little more to it than that: irq_domains do not correspond 1-to-1 with interrupt controllers. A single controller could have more than one domain.
So, let's precisely define what we mean by "mapping" IRQs:
Each virtual IRQ has a struct irq_desc. Some of this struct's fields are mapped to point to the functions implemented by the interrupt controller driver. (I'm not sure what Linux does when it receives an interrupt before you do any mapping)
Each interrupt controller can provide some number of struct irq_domains. These essentially encode the mapping between hardware IRQ numbers to virtual IRQ numbers, and have an API for drivers to look up numbers.
The irq_domain struct also contains pointers to callbacks which are implemented by the interrupt controller driver. One of these callbacks is triggered when you create a new mapping; I think this is how the hardware is configured to generate particular virtual IRQs.
When you request an interrupt, your ISR will be added to the actions list in the irq_desc, provided the irq_desc has been properly initialized.
Anyway the method I found for getting the virtual IRQ number given a hardware IRQ number (and creating a new mapping if necessary) is as follows:
#include <linux/irqdomain.h> //For irq_domain struct
#include <linux/of.h> //For device tree struct types
#include <linux/irq.h> //Needed by other interrupt-related code
struct device_node *dn;
struct irq_domain *dom;
struct irq_fwspec dummy_fwspec = {
.param_count = 3,
.param = {0, 89, 4}
};
int virq;
//Find the Linux irq number
dn = of_find_node_by_name(NULL, "interrupt-controller");
if (!dn) {
printk(KERN_ERR "Could not find device node for \"interrupt-controller\"\n");
goto /*error_handler*/;
}
dom = irq_find_host(dn);
if (!dom) {
printk(KERN_ERR "Could not find irq domain\n");
goto /*error_handler*/;
}
dummy_fwspec.fwnode = dom->fwnode;
virq = irq_create_fwspec_mapping(&dummy_fwspec);
The irq_create_fwspec_mapping will either return an existing (mapped) virtual IRQ number, or map a new one. The struct irq_fwspec contains all the information that would be needed to perform the mapping. The fwnode field must point to the interrupt controller you are using; in my case, I found the correct value using the device tree API (there might be a better way, but I don't know what it is!)
This example is specifically for an MPSoC, and I happen to know it uses this driver (drivers/irqchip/irq-gic.c). I looked at the driver's source code to figure out what it wanted in the other parts of the irq_fwspec struct. Specifically, each controller driver will fill a struct irq_domain_ops, so CTRL-F for that to find the callback functions you need to satisfy.
In my specific example, I knew the gic_irq_domain_alloc would be called, and that it would also call gic_irq_domain_translate. This told me that the 2nd number was the hardware IRQ number, but that for some reason 32 would be added to it. Since I wanted hardware IRQ number 121, I plugged in 89 for the 2nd number. The first and third numbers are kind of a guess based on what I've seen other people doing.
If someone knows a simpler way to do this, let me know