Am 13.12.2017 um 15:42 schrieb Roger Oberholtzer:
On Wed, Dec 13, 2017 at 2:28 PM, Alexander Graf <agraf@suse.de> wrote:
On 13.12.17 14:00, Roger Oberholtzer wrote:
On Wed, Dec 13, 2017 at 1:35 PM, Alexander Graf <agraf@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.
I might be wrong, but isn't that the point of "chained" interrupts? In my example code you can also see me playing with "threaded" interrupts. This is the only official documentation I could find: https://www.kernel.org/doc/html/latest/core-api/genericirq.html Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org