On Thu, Nov 09, 2017 at 01:57:07PM -0800, Tony Lindgren wrote: > * Ladislav Michl <ladis@xxxxxxxxxxxxxx> [171109 21:49]: > > gpio_in (yellow) is fed with signal generator while scope inputs are > > connected to both gpio_in and gpio_out (blue). Output signal is inverted > > to make waveform compare easier by naked eye. > > > > Expected result is clean waveform with small offset and reasonable jitter. > > To make this clearly visible, waveform persistence was enabled on scope. > > Resulting waveform on idle system looks like this: > > http://ladislav.michl.sweb.cz/omap3_edge_irq_1.png > > As you can see, latency (jitter) is up to half of pulse width, which seems > > pretty bad as frequency is 610Hz. > > Nice test set up :) > > > However, loaded system (*) shows much better results: > > http://ladislav.michl.sweb.cz/omap3_edge_irq_2.png > > > > Any idea how to get good enough (second measurement) results regardless of > > the system load? > > Maybe you can block idle states from your driver with PM QoS? > > Just add some latency requirement. See for example what was done > earlier for omap3 audio in commit 9834ffd1ecc3 ("ASoC: omap-mcbsp: Add PM > QoS support for McBSP to prevent glitches"). > > Not sure if we can do this in a generic way.. But maybe it's doable for > things like PWM drivers. That seems to be rather problematic as I need this for generic driver: drivers/media/rc/gpio-ir-recv.c I need to be able to detect key presses of various remotes, so protocol is unknown in advance. Having such a big jitter leads to false positives when guessing protocol or decoding errors. I was also considering using FIQ handler, but it probably won't help in this case. ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
