New Contributor
New ContributorThank you!
Unfortunately none of them work.
1. It is UIO irq only device, no memory region assigned to it.
2. Yes, I have done it before, it works, but I need the more stricter timing with IRQ.
3. It is an edge-triggered irq.
4. I've already tried everything (except the solution :D), nothing worked. I've made it clear/not to clear, tried with poll/select , swapped the orders etc.
New Contributor2. Yes, I have done it before, it works, but I need the more stricter timing with IRQ.
>The only clue I have is that, it seems the interrupt handling may be the culprit. Even though it is edge triggered, apparently the interrupt did not get cleared properly and results in an interrupt storm. Can you check if the Linux UIO kernel driver is receiving the interrupt storm and hence causing the CPU spike? Probably using "cat /proc/interrupts" to see the interrupt statistics.
You mentioned the FPGA "The installed FPGA image is doing nothing more than making interrupts to an UIO device, 50 times a sec." Is this part of the Arria10 GHRD? Can you share us more information on the design?
DT you shared:
tx_trig_irq {
/* /dev/uio4 */
compatible = "test_irq", "generic-uio";
interrupts = < 0 0x16 IRQ_TYPE_EDGE_RISING >;
interrupt-parent = <&intc>;
}; You are using 0x16 = 22 , so, the IRQ = 22 + 32 = 55 (F2S_FPGA_IRQ4). This seems right.
The FPGQ IRQs for Arria10 begins 51 with https://www.intel.com/content/www/us/en/docs/programmable/683711/21-2/gic-interrupt-map-for-the-arria-10-soc-hps.html
51 | FPGA | F2S_FPGA_IRQ0 | - | Level or Edge |
52 | FPGA | F2S_FPGA_IRQ1 | - | Level or Edge |
53 | FPGA | F2S_FPGA_IRQ2 | - | Level or Edge |
54 | FPGA | F2S_FPGA_IRQ3 | - | Level or Edge |
55 | FPGA | F2S_FPGA_IRQ4 | - | Level or Edge |
56 | FPGA | F2S_FPGA_IRQ5 | - | Level or Edge |
57 | FPGA | F2S_FPGA_IRQ6 | - | Level or Edge |
New ContributorThe FPGA design is very simple: it generates a single pulse every 20ms. this pulse signal is directly connected to the f2h_irq line 3. (22 + 32 = 54 (F2S_FPGA_IRQ3) ) . This is only IRQ line which is connected.
I've already checked a few times for a storm:
- the cat /proc/interrupts shows no increment when the irq-s are not handled by the sw. (or the re-enable bit is not written back)
- I've double checked the kernel (compiled it with lots of debug messages), there is no storm for sure.
