Linux UIO IRQ related periodic CPU usage

Item 4: Still some question on the user application design:

Just to double confirm, WRITE() must always be after READ() and only after you are done with any data processing/event handling.

In the interrupt handler, any interrupt trigger will automatically disable the IRQ. The READ() will get a wakeup and at this point, the IRQ is disabled. The call to write() will re-enable the IRQ.

If you don't do a WRITE at all, do you see the CPU spikes? In this scenario, the IRQ should be disabled and not entertaining edge interrupt triggers. Check "cat /proc/interrupts" to see if the counts stopped.

And if you do a WRITE() from your test,

Check "cat /proc/interrupts" to see if the counts increment as expected or it storms with a huge number.

bool wait_for_irq (TX_IRQ_HANDLE_S* pHandle) {
    if (!pHandle || pHandle->txTrigIrqFd < 0) {
        std::cout << "ERROR: handle";
        return false;
    }
    
    uint32_t info = 1;
    ssize_t nb = write(pHandle->txTrigIrqFd, &info, sizeof(info));   <- this re-enables IRQ, should always be only when you are ready to for the next event.
    if (nb != (ssize_t)sizeof(info)) {
        std::cout << "ERROR: writing";
        return false;
    }

    nb = read(pHandle->txTrigIrqFd, &info, sizeof(info));
    if (nb == (ssize_t)sizeof(info)) {
        return true;
    }

    return false;
}