From: Kevin Hilman <khilman@baylibre.com>
To: Andreas Kemnade <andreas@kemnade.info>,
aaro.koskinen@iki.fi, andreas@kemnade.info, rogerq@kernel.org,
tony@atomide.com, linux@armlinux.org.uk, andi.shyti@kernel.org,
thomas.richard@bootlin.com, wsa+renesas@sang-engineering.com,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] ARM: OMAP2+: fix omap_device with noirq_suspend
Date: Tue, 10 Nov 2026 16:22:39 -0800 [thread overview]
Message-ID: <7hwlqktdww.fsf@baylibre.com> (raw)
In-Reply-To: <20261110211531.679943-1-andreas@kemnade.info>
Andreas Kemnade <andreas@kemnade.info> writes:
> Fixes cases where device runtime gets resumed in _suspend but then
> pm_runtime_force_suspend is used. So the device is disabled, but runtime
> active in _noirq_suspend leading to duplicate runtime_suspend calls. So
> rather check for the device state directly to indicate if changes are
> needed.
> This relies on pm_runtime_force_resume being used in a balanced way.
>
> Fixes: 7da7fd7e66ac9 ("i2c: omap: wakeup the controller during suspend() callback")
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
> This really needs intensive scrutiny but might be a less invasive patch
> solution better suited for stable and paves the way to get out of the
> omap_device theatre without too much hurry.
This looks & feels correct to me.
I also tested this (along with my WIP patch for that NEON count
mismatch) and I have a very stable suspend/resume on OMAP3.
I tested on omap3-beagle (retention) and omap3-beagle-xm (off-mode) and
both are now reliable across multiple suspend/resume sequences with
these two patches.
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Kevin
> arch/arm/mach-omap2/omap_device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 77a75b0b9ae69..52afc9089a5a0 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -393,7 +393,7 @@ static int _od_suspend_noirq(struct device *dev)
>
> ret = pm_generic_suspend_noirq(dev);
>
> - if (!ret && !pm_runtime_status_suspended(dev)) {
> + if (!ret && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
> if (pm_generic_runtime_suspend(dev) == 0) {
> omap_device_idle(pdev);
> od->flags |= OMAP_DEVICE_SUSPENDED;
> --
> 2.47.3
next prev parent reply other threads:[~2026-11-11 0:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 21:15 [RFC PATCH] ARM: OMAP2+: fix omap_device with noirq_suspend Andreas Kemnade
2026-11-11 0:22 ` Kevin Hilman [this message]
2026-11-11 7:35 ` Andreas Kemnade
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7hwlqktdww.fsf@baylibre.com \
--to=khilman@baylibre.com \
--cc=aaro.koskinen@iki.fi \
--cc=andi.shyti@kernel.org \
--cc=andreas@kemnade.info \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=rogerq@kernel.org \
--cc=thomas.richard@bootlin.com \
--cc=tony@atomide.com \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.