Hi, On 05/04/18 20:48, Martin Kelly wrote: > On 04/05/2018 06:07 AM, Maxime Ripard wrote: >> On Wed, Apr 04, 2018 at 02:50:25PM -0700, Martin Kelly wrote: >>> Hi, >>> >>> I've noticed strange behavior on my H3 (nanopi neo air) and am >>> wondering if >>> anyone has suggestions for further debugging it, as I'm getting stumped. >>> >>> Specifically, I have configured a device (Invensense MPU9250) to deliver >>> interrupts at 10Hz to PG_EINT11. For some reason, though, the interrupt >>> handler is being called at only about 6 Hz. >>> >>> Looking at a logic analyzer, I see the hardware is interrupting at 10 >>> Hz as >>> it should, but sometimes the interrupts are just missed from the kernel >>> side. So you might see a 200 ms gap between calls to the IRQ handler, >>> but >>> 100 ms between hardware IRQ events. >> >> This really looks like you're just missing the edge. Interrupts >> handlers in Linux run with the interrupts disabled, so if you happen >> to have another interrupt running at the time where your device is >> emmiting its own, you'll miss it.
But the software/kernel shouldn't matter in that case, should it? It is actually the port controller hardware registering the interrupt cause, and then forwarding this to the GIC, and that to the CPU. So once the Allwinner port controller has sampled the IRQ, it sets the pending bit in the PG_EINT_STATUS_REG, from then on the interrupt cannot be lost anymore. Unless it's configured as a line level IRQ on the pin controller side, where a lowered line (the end of the pulse) would mean the pending state is cleared again. So it should really be edge on the pinctrl side. Or am I missing something? >> If it can use level interrupts, you probably should use that instead. Well, it's always level between the pinctrl and the GIC, and even if it would be edge, the GIC would store this state until the CPU acknowledges it. PSTATE.I=0 shouldn't have an effect. I would actually expect it to be the other way around: configuring as *level* on the pinctrl side allows for IRQ *pulses* to be lost. Could it be that the pinctrl is clocked too slowly, so it can't sample the pins quickly enough and misses the rather short pulse? Cheers, Andre. > Yes, I have to agree with your theory. I switched to level interrupts > and nothing is missed now. > > One thing I'm confused about: I had expected that if a single > edge-triggered interrupt is missed because interrupts were disabled, it > would still be resumed later. From my testing, it appears when > interrupts are missed, the entire period is skipped, and we we act on > the next interrupt instead. > > For example, I'm seeing: > 0 ms: interrupt, handler fires > 100 ms: interrupt, no handler > 200 ms: interrupt, handler fires > > I never see a slightly-delayed handler, as I would expect if interrupts > are being processed after they are re-enabled. > > I also noticed that, depending on what's going on in the system and the > interrupt frequencies (my tests ranged from 10 to 500 Hz), the pattern > of which interrupts are missed changes. Sometimes at 10 Hz, I see almost > an entire second of missed interrupts, and then a few seconds of every > interrupt being hit, and then another long batch of missed interrupts. > At higher frequencies, the misses are about the same frequency (about > 40% misses), but more fine-grained instead of batched up. I'm not sure > what to make of these patterns, but 40% miss rate on a 10 Hz signal (at > near 0% CPU load) really surprises me. > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
