I am still poking around this area too.
This points to the "edge" meaning the type of irq is an "edge falling" irq: https://www.raspberrypi.org/forums/viewtopic.php?t=20931
Looking at mine, I have "18 edge" and that ties in with the GPIO-18 I expect the interrupt to come in on in my case :
CPU0 CPU1 CPU2 CPU3
172: 1387 0 0 0 pinctrl-bcm2835 18 Edge lirc_rpi
I am still poking around this area too.
This points to the "edge" meaning the type of irq is an "edge falling" irq: https://www.raspberrypi.org/forums/viewtopic.php?t=20931
Looking at mine, I have "18 edge" and that ties in with the GPIO-18 I expect the interrupt to come in on in my case :
CPU0 CPU1 CPU2 CPU3
172: 1387 0 0 0 pinctrl-bcm2835 18 Edge lirc_rpi
\/ ... linux global irq number
\/ ... number of occured irqs on CPU 0
\/ ... number of occured irqs on CPU 1
\/ ... irq chip receiving the irq
\/ ... hw irq number and type of irq
\/ ... assigned action of irq
(-> irq handler inside a driver, can also be assigned to more then just one handler / driver)
cat /proc/interrupts
CPU0 CPU1
0: 22 0 IR-IO-APIC 2-edge timer
1: 2 0 IR-IO-APIC 1-edge i8042
8: 1 0 IR-IO-APIC 8-edge rtc0
9: 0 0 IR-IO-APIC 9-fasteoi acpi
12: 4 0 IR-IO-APIC 12-edge i8042
120: 0 0 DMAR-MSI 0-edge dmar0
122: 0 0 IR-PCI-MSI 327680-edge xhci_hcd
123: 25164 5760490 IR-PCI-MSI 1048576-edge enp2s0
124: 17 5424414 IR-PCI-MSI 524288-edge amdgpu
Same information is also in /sys/kernel/irq/<number of each irq>/<info files>, but more machine readable.
More irq infos can be retrieved, if kernel is compiled with e.g. CONFIG_IRQ_DOMAIN_DEBUG=y
A good introduction to linux IRQs is here: https://www.youtube.com/watch?v=LOCsN3V1ECE
As you can see in the source of the kernel, it displays all possible irqs of the system.
In source/fs/proc/interrupts.c:39 a sequence operation is initialized to return as many elements as interrupts exist in the system for /proc/interrupts.
In source/kernel/irq/proc.c:479 we can see that the counters of every interrupt gets extracted from global counters via kstat_irqs_cpu(irq, cpu).
This means the interrupt count information gets updated in different counters, one for each cpu. The counters get summed upon reading the proc file.
This is a common pattern in the kernel. It prevents contention on a global counter.
More onfo about per-cpu variables you can read here. More about interrupts in linux you can get here.
All files under /proc are pseudo files , which means there is no actual data present in them.
When you access any file under proc fs , proc methods linked with that particular proc file is invoked , and the proc methods , access certain related kernel data structures and generate data dynamically , which can be read and displayed. Data from proc file is generally used to display status information of the system , or the state of a device driver.
The proc fs is generally implemented as part of the driver , by adding the proc and the seq fs layer to the driver code , however proc is also used by the kernel , to display status information of the system in general.Since there is no general hierarchy or classification among the proc files , they are used rarely in comparison with the newer sysfs file system.
To know how the information is generated , you must study the proc layer implemented in fs/proc/interrupts.c
This website briefly explains some of those methods.