* Ladislav Michl <ladis@xxxxxxxxxxxxxx> [171115 22:30]:
> 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
> > like that.
>
> So, looked at above mentioned commit and tried patch bellow without any
> noticeable change. Also PM QoS seems to handle DMA and network latency only.
> I need to handle IRQ latency. Any other options?
Hmm well did you check what idle states your system hits after doing it?
# cat /sys/kernel/debug/pm_debug/count
The value needs to be lower than max cpuidle limit for the state you need
as you probably figured.
Hmm maybe request hardware debounce for the GPIOs you're using? That should
block deeper idle states as the optional GPIO clocks will stay enabled.
Regards,
Tony
--
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
