Hi,
Maybe someone has seen this before, but I could not find it in any post. As far as I can see there is a bug in prussdrv.c in the git repository: https://github.com/beagleboard/am335x_pru_package.git
The problem is that when an interrupt is sent from a PRU to the ARM processor (using a beaglebone -> AM3359), the interrupt is first disabled in kernel-space, in uio_pruss.c/pruss_handler(). After the interrupts is delivered as an event to the user-space lib (prussdrv.c) the interrupt is enabled again, _before_ it is cleared. I have in the attached patch moved the re-enabling of the interrupt from prussdrv_pru_wait_event() to prussdrv_pru_clear_event() right after the interrupt is cleared. This prevents duplicate interrupts. The implemetation in the patch is such that there is a linear search in the struct used to configure interrupts, to find the host number from the system event number. Maybe this is not good from a performance perspective ? Comments on the patch are appreciated from someone more familiar with the pruss driver/lib.
Attached is also a demo application that reproduceses the fault. When running strace on the PRU_demo application, one can clearly see that there are two returns from the read() call in prussdrv_pru_wait_event() for each interrupt sent from the PRU, if the patch is not applied.
As said before, any comments appreciated.
br Håkan
