On 12/13/2017 03:42 PM, Roger Oberholtzer wrote: > On Wed, Dec 13, 2017 at 2:28 PM, Alexander Graf <ag...@suse.de> wrote: >> >> >> On 13.12.17 14:00, Roger Oberholtzer wrote: >>> On Wed, Dec 13, 2017 at 1:35 PM, Alexander Graf <ag...@suse.de> 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
