On Thu, Nov 09, 2017 at 02:37:40PM -0800, Tony Lindgren wrote: > * Ladislav Michl <ladis@xxxxxxxxxxxxxx> [171109 22:33]: > > On Thu, Nov 09, 2017 at 01:57:07PM -0800, Tony Lindgren wrote: > > > 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. > > Hmm to me it seems that PM QoS would be totally justified for a driver I will give it a try... > like that. But actually, why don't you use drivers/pwm/pwm-omap-dmtimer.c > like drivers/media/rc/ir-rx51.c is doing? Then you have the dmtimer > driving things.. That would be excelent choice, of course, but IGEPv2 board does not route any pwm capable pin on its pin header. Also note I need another direction, while ir-rx51 is transmitter driver, gpio-ir-recv is a receiver. I didn't check whenever dm timer is input capture ready. Btw, ir-rx51 could be probably replaced with generic driver, one day https://git.linuxtv.org/media_tree.git/tree/drivers/media/rc/pwm-ir-tx.c Best regards, 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