There's more...

If you wish to check how this works, we can do so by testing our example. We have to compile it and then reinstall the kernel with our code compiled as built-in, so let's use the usual make menuconfig command and enable our testing code, or just use make oldconfig, answering y when the system asks for a choice, as follows:

Simple IRQ test (IRQTEST_CODE) [N/m/y/?] (NEW)

After that, we've just to recompile and reinstall the kernel and then reboot the ESPRESSObin. If everything works well during the boot sequence, we should see kernel messages as follows:

irqtest irqtest: got GPIO 466 from DTS
irqtest irqtest: GPIO 466 correspond to IRQ 40
irqtest irqtest: interrupt handler for IRQ 40 is now ready!

Now, the MPP2_20 line has been taken by the kernel and converted into the number 40 interrupt line. To verify it, we can take a look at the /proc/interrupts file, which holds all registered interrupt lines within the kernel. Earlier, we used the irqtest label in the request_irq() function during an interrupt handler registration, so we have to search for it within the file with grep as follows:

# grep irqtest /proc/interrupts 
 40:     0     0     GPIO2   20   Edge   irqtest

OK. The interrupt line 40 has been assigned to our module, and we notice that this IRQ line corresponds to the GPIO line 20 of the GPIO2 group (that is, the MPP2_20 line). If we take a look at the beginning of the /proc/interrupts file, we should get an output as follows:

# head -4 /proc/interrupts 
           CPU0   CPU1 
  1:          0      0   GICv3   25   Level   vgic
  3:       5944  20941   GICv3   30   Level   arch_timer
  4:          0      0   GICv3   27   Level   kvm guest timer
...

The first number is the interrupt line; the second and third ones show how many interrupts have been served by the CPU0 and CPU1, respectively, so we can use this information to verify which CPU served our interrupt.

OK. Now we're ready to go. Just connect pin 12 to pin 1 of the P8 extension connector; at least one interrupt should be generated and a message, such as the following, should appear in the kernel messages:

irqtest irqtest: interrupt occurred on IRQ 40

Note that you may get several messages due to the fact that, during the short circuit operation, the electrical signal may generate several oscillations, which in turn will generate several interrupts.

As a final note, let's take a look at what happens if we try to export the number 466 GPIO line, as we did earlier, using the sysfs interface:

# echo 466 > /sys/class/gpio/export 
-bash: echo: write error: Device or resource busy

Now, we correctly get a busy error due to the fact such a GPIO has been requested by the kernel when we used the devm_gpio_request() function.