Re: dmtimer: ack pending interrupt during suspend on am335x/am437x?

[Tony Lindgren <tony@atomide.com>]

* Drew Fustini <dfustini@baylibre.com> [220509 05:07]:
> Hello Daniel, Tony suggested I mail you along with the list to get
> feedback. I'm attempting to upstream these two patches [1][2] from
> ti-linux-5.4.y for arch/arm/mach-omap2/timer.c:
> 96f4c6e2ba8a ("ARM: OMAP2+: timer: Ack pending interrupt during suspend")
> 7ae7dd5f8272 ("ARM: OMAP2+: timer: Extend pending interrupt ACK for gic")
> 
> On the TI AM335x and AM437x SoCs, it is possible for a late interrupt to
> be generated which will cause a suspend failure. The first patch makes
> omap_clkevt_idle() ack the irq both in the timer peripheral register
> and in the interrupt controller to avoid the issue.
> 
> On AM437x only, the GIC cannot be directly acked using only the irqchip
> calls. To workaround that, the second patch maps the GIC_CPU_BASE and
> reads the GIC_CPU_INTACK register before calling irq_eoi to properly ack
> the late timer interrupts that show up during suspend.
> 
> However, Tony removed most of arch/arm/mach-omap2/timer.c with:
> 2ee04b88547a ("ARM: OMAP2+: Drop old timer code for dmtimer and 32k counter")
> 
> The timers are now implemented in drivers/clocksource/timer-ti-dm.c and
> drivers/clocksource/timer-ti-dm-systimer.c. The function
> dmtimer_clocksource_suspend() disables the dmtimer and clock but does
> not ack any interrupts.
> 
> Tony suggested the right place to ack the interrupt during suspend is
> in CPU_CLUSTER_PM_ENTER inside omap_timer_context_notifier().
> 
> Do you think that would be an acceptable approach?

Based on what we chatted on irc yesterday, I'd suggest try resetting the
clockevent on suspend first for am3/4 at omap_clockevent_idle() and see if
that takes care of the issue. If it's the timer hardware blocking the
deeper idle states, this should work, and GIC will lose it's context
on system suspend anyways.

If there's still a pending interrupt status blocking deeper idle
states for system suspend after clockevent reset, then maybe the related
interrupt controller(s) should clear/reset the state for context lossy
suspend for CPU_CLUSTER_PM_ENTER for system suspend.

Looks like for GIC we have gic_dist_save() being called but it does not
seem to clear anything for system suspend.

For runtime PM, we don't want to clear any pending interrupts on
CPU_CLUSTER_PM_ENTER :)

Seems like a system suspend/resume test loop should be first run to
trigger the issue and see what is still missing.

Regards,

Tony


> [1] https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-linux-5.4.y&id=96f4c6e2ba8a
> [2] https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-linux-5.4.y&id=7ae7dd5f8272