On 13.12.17 13:12, Roger Oberholtzer wrote: > On Tue, Dec 12, 2017 at 7:32 PM, Andreas Färber <[email protected]> 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: [email protected] To contact the owner, e-mail: [email protected]
