On 13.12.17 13:12, Roger Oberholtzer wrote:
On Tue, Dec 12, 2017 at 7:32 PM, Andreas Färber <afaerber@suse.de> wrote:
Hi Roger,
Am 30.11.2017 um 10:59 schrieb Roger Oberholtzer:
We have written a minimal kernel interrupt handler for the Raspberry Pi 3. It is running the current 64-bit Tumbleweed kernel. I am curious about the rate of interrupts that we might be able to capture.
The ISR does little other than run when a raising edge interrupt happens. We are looking at /proc/interrupts to see how many interrupts have happened.
We see that at around 23 kHz we begin to loose interrupts. The system is not doing anything else.
Does that seem reasonable? I have not seen any good discussion of this. I think it is rather low. I am guessing that the issue is how the Linux kernel responds to interrupts. The housework in setting things up so that the interrupt can run must be the resource hog.
Opinions? Suggestions?
I don't see anything openSUSE-specific in here, so I'd suggest to ask on upstream linux-rpi-kernel list about any performance expectations.
Personally I haven't had any success using GPIO interrupts on my rpi3, but that may be a matter of the device/driver (SX1276) I tried it with.
Can you share any more details on DT overlay or driver init you're using to set up the interrupt? What's your interrupt source?
GPIO pin 17. In our driver, we get interrupts on this line at up to 23 kHz. Then we start to miss some. We look at /proc/interrupts to see how many have occurred.
The driver is absolute minimum while we test the interrupt speed we might obtain:
Would it make sense to resort to polling at those speeds instead? Maybe poll using a constant reoccuring hrtimer? I also remember some talk about FIQ interrupts being faster than normal ones, but I never used them. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org