* Tony Lindgren <tony@xxxxxxxxxxx> [170324 10:44]:
> * Grygorii Strashko <grygorii.strashko@xxxxxx> [170324 10:35]:
> >
> >
> > On 03/23/2017 09:49 AM, Tony Lindgren wrote:
> > > * Ladislav Michl <ladis@xxxxxxxxxxxxxx> [170323 05:46]:
> > > > Edge triggered interrupts are lost no matter how fast is its source.
> > > > It happens even at 10Hz and patch bellow fixes issue. Of course,
> > > > it is just a hack showing where problem is and it will need a bit
> > > > more debugging.
> > >
> > > OK disabling pm_runtime fixes it.. Care to describe which GPIO bank
> > > you're testing with?
> > >
> > > For GPIO bank1, context is never lost so wake-ups work without
> > > the wakeirqs handled by pinctrl-single.c. But you should not hit
> > > this unless you've configured the system to hit off mode during
> > > idle by setting /sys/kernel/debug/pm_debug/enable_off_mode and
> > > configuring UART autosuspend.
> > >
> > > So it seems the runtime_suspend/resume edge configuration for
> > > wake-up events causes it?
> > >
> > > If nothing else helps, I guess one option would be to implement
> > > pm_runtime_use_autosuspend() with the timeout configured to
> > > 100ms or something similar. But that seems like a workaround and
> > > won't fix the real issue.
> >
> > This is really strange as PM runtime will be executed only when
> > first gpio is requested - all other time gpio bank should stay active.
> >
> > Only one possibility is deep CPUIdle or Suspend states, but in this case
> > some QoS setup may require to block these states while IR/App is
> > running.
>
> I think this is triggered when omap3 PM in omap_sram_idle() calls
> omap2_gpio_prepare_for_idle(). If that's the case, we could fix
> it with a PM QoS configuration similar to how the audio glitches
> were fixed in commit 9834ffd1ecc3 ("ASoC: omap-mcbsp: Add PM QoS
> support for McBSP to prevent glitches").
>
> No idea what should set the latency requirement though. Probably
> the IR driver when active?
>
> That probably still won't help with fact that we can lose events
> though. Ideally things would just work even without the PM QoS.
If something like the untested patch below helps, then we might be
able to optimize thing a bit. We need to check if something has to
be configured in the PER retention case though.
Regards,
Tony
8< ---------------
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -229,7 +229,8 @@ void omap_sram_idle(void)
/* PER */
if (per_next_state < PWRDM_POWER_ON) {
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
- omap2_gpio_prepare_for_idle(per_going_off);
+ if (per_going_off)
+ omap2_gpio_prepare_for_idle(per_going_off);
}
/* CORE */
--
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
