Re: [opensuse-arm] Raspberry Pi 3 interrupt handling

On 12/13/2017 03:42 PM, Roger Oberholtzer wrote:

On Wed, Dec 13, 2017 at 2:28 PM, Alexander Graf wrote:

...

On 13.12.17 14:00, Roger Oberholtzer wrote:

...

On Wed, Dec 13, 2017 at 1:35 PM, Alexander Graf wrote:

...

Would it make sense to resort to polling at those speeds instead? Maybe poll using a constant reoccuring hrtimer?

Granted polling does not have the interrupt overhead. But I wonder how it keeps up with respect to scheduling. Might one miss activity when the kernel thread is not running?

Depends on how bad your jitter is, but I would hope that you'll get better granularity than 23khz ;).

If jitter is too big, then perhaps if more than one interrupt is pending when already in an interrupt, only the first one is seen. I do not think interrupts are stacked.

...

Worst case you can always try and isolate one CPU to do nothing but poll. You have 4 of them after all :). But that gets quite complicated ...

I have also been considering that. But when we are testing, there is pretty much nothing else going on. One would expect a CPU to be ready. But if the kernel thread managing the interrupt must be set up to run, maybe that is taking time. This is getting outside my area of knowledge.

From my understanding in the minimal driver you posted, you don't use a threaded interrupt handler, but a handler in IRQ context. So there won't be any need for

the kernel to schedule the ISR. Or do I miss something? My guess is, that you are hitting the maximum frequency of possible interrupts. So I would prioritize the FIQ approach to see if that helps. Regards, Matthias -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org