[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4de411aa2fc8a6f185afb8bfd5da63d4@kernel.org>
Date: Tue, 10 May 2022 09:19:51 +0100
From: Marc Zyngier <maz@...nel.org>
To: Tony Lindgren <tony@...mide.com>
Cc: Drew Fustini <dfustini@...libre.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Dave Gerlach <d-gerlach@...com>, linux-omap@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: dmtimer: ack pending interrupt during suspend on am335x/am437x?
On 2022-05-10 07:49, Tony Lindgren wrote:
> * Drew Fustini <dfustini@...libre.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.
Maybe, but the core tracking code will still know it is in the
middle of an interrupt. I´d expect things like lockdep to shout
at you...
M.
Powered by blists - more mailing lists